The original link
1. The background
The project I took over needs to go online recently, so I reviewed the project signature file configuration process and made a systematic summary here.
2. End goal
Configure signature files for debug packages and release packages as required to quickly meet the needs of small and medium-sized projects.
3. Create a signature file
To configure a signature file into a project, you first need to create a signature file. Android Studio provides us with a graphical approach to creation, which is briefly described here:
Under build, select Generate signed Bundle/APk, as shown below:
For domestic, select APK and click Next:
Click Create New to create a new signature file:
Next, you need to fill in some information, which is briefly explained in the screenshot below. One of the six fill-in-the-blank questions under certificate is enough. It is suggested to fill in all the blanks:
When you’re done, click OK to create, finish, etc.? Why also reported wrong! Take a look at that…
Oh, he told us to use the command line to migrate to the industry standard format, so go ahead: copy the command in the warning popup (keytool -importkeystore……) Pkcs12), open the terminal terminal, paste in, press Enter, go you ~ as prompted, input the source key library password, is just set the password, and then press Enter, go you ~ OK, here, the signature file is created.
4. Generate configuration information about the Release and DEBUG signature files
We need to generate configuration scripts for test packages and official packages under build.gradle of app to configure different properties of debug packages and release packages respectively. For example, both test packages and official packages use their own signature files, and the official packages are confused but the test packages are not opened, which is convenient for us to develop and launch. Android Studio also provides a graphical user interface. Here’s a look at it:
Navigation bar File -> Project Structure, go to the project structure interface
Choose modules -> app -> Signing Configs.
Click “+” to add configuration information, type Release to indicate that this is the signature file information for the official package, and click OK:
Similarly, the configuration information of the debug package signature file is generated for daily development and debugging. It is recommended to use the same signature file with the Release package to avoid the debug version and release version with the same package name. If the debug package and release package use different signature files, you can append the package name to the test package to avoid the name conflict between the official package and the test package. Release signature file configuration is shown as follows:
The debug signature file is configured as follows:
After clicking OK, wait for the project configuration to complete, and then open the build.gradle file under the project app directory. We can see that the signature information of the Release package and debug package have been generated, as shown in the figure:
But so far, we have only generated our own two signature file information, but have not configured it into the test package or the official package. So how do you get the test package or the official package to use their own signature file information? Take it easy. Let’s have a cup of tea.
5. Configure the signature file information to the corresponding package
Drinking tea za don’t idle, have a look at the app directory build. Gradle buildType inside information:
This bulidType records the configuration of the project’s release package, debug package, and other packages. As you can see, when creating the project, the system automatically generates the configuration of the release package explicitly for us, but only two values are configured. Here is a brief description:
- MinifyEnabled: Whether obfuscation is enabled (debug mode defaults to true, release mode defaults to false)
- ProguardFiles: obfuscating files (only valid if minifyEnabled is true) OK, let’s first configure the signature file of the Release package. The interface will still open for the project structure, but choose “Build” as shown in the figure below:
We can see that the system has generated a release, which is the configuration file of the official package. We just need to set the signature file this time, and other Settings can be learned by ourselves. Select the signingConfigs.release option for the Settings under Signing Config and click Apply to apply the Settings. After compiling, go back to build.gradle in the app directory and look at buildTypes, as shown:
At this point, the signature file for the Release package is configured. Then configure the debug package’s signature file. Once again, open the Project Structure interface to create variables (File -> Project Structure -> Build variants) and select the app package:
Click “+” and enter debug. Click OK to display the default configuration of the debug package.
We can change the configuration as needed. For example, the default value of the Debuggable is true. In this case, we can explicitly specify the default value of the Debuggable to be manually set to true. The Debuggable is shown as follows:
Debuggable, as the name implies, is whether adjustable, refers to the application in the running process, can be debugged through the compiler, the most direct performance is the system log output. By default, the release package is in off mode and the Debug package is in on mode. During development, you can change this value if necessary to debug the debug package or release package.
Configuring the Debug package signature file is basically the same as configuring the Release package signature file, go to signing Config, select the signature file, then click Apply to apply the configuration, and finally OK, as shown below:
After the synchronization is complete, we can see that the compiler has automatically generated the debug package configuration information for us, and applies our custom signature file:
The basic configuration process of signature files has been described. However, such configuration may cause security problems of signature file information. Before we talk about security, let’s fill in the hole 1: the debug package appends the package name. If you’re interested, let’s see, if you’re not, you can jump to the next section. As mentioned above, in order to avoid the conflict between the test package and the formal package installation, we can use two methods: one is to use the same signature file above, the other is to append the package name to the test package, so that they have different package names, so as to avoid the package name conflict. Android Studio also gives us a way to graphically append package names, which we’ve even just seen.
[Black question mark face.jpg]
Take a look at the screenshot:
Yes, here is an additional package name, such as the default package name is my demo com. Dylan. Signaturetest, I want to make the test package the package name is com. Dylan. Signaturetest. Debug, So I just need to add “. Debug “to the application ID suffix, as shown in the figure below:
After clicking Apply and OK, wait for the synchronization to complete and check build.gradle configuration as follows:
As you can see, the applicationIdSuffix attribute has been added successfully. At this time, we run the official package and test package respectively, as shown in the following figure:
The running results are shown as follows:
As you can see, both packages can exist at the same time. Check the package name as shown in the figure below:
As expected, the formal package and the test package exist together. OK, the pit buried above is filled, and the bottom is about the information security of signature documents mentioned above.
6. Move the signature file to the local configuration file of the project
We found that in front of the signature file of extremely sensitive information such as file name, password, are under the project app package build. Gradle, with the contract of the project, application to each big market together, this installation package is up to no good players after decompiling, easy to get to our signature file information. In addition, the file path is written in Gradle. When developing the same project, everyone’s signature file is placed in various places. This also causes the problem that the signature file path of gradle file is frequently changed by many people. In order to avoid this situation, we often put the signature file configuration information in the local configuration file local.properties, which is created by Android Studio when we create a new project, in the root directory of the project. By default, it is not added to Git to commit to the remote repository. When someone pulls the remote repository code for the first time, you just need to create your own local.properties file. The following is a screenshot:
As you can see, our Android SDK path is configured here. Next we will write the code to read the signature file information from the local.properties file.
First, specify the signature file path, password, alias, alias password and other information in the local.properties file, as shown in the figure below:
Then write code in android under build.gradle file in app directory, read local.properties file, and read the specified information, as shown in the figure:
Finally, configure the read signature file information to debug and release in signingConfigs, as shown in the following figure:
At this point, the signature file from generation to configuration of the complete process, is finished.
7. To summarize
This article explains the complete process of configuring an Android project signature file from scratch. By reading this article, we can have an overall grasp of the signature file configuration, and the subsequent configuration of the signature file can also be done in one article. Due to the author’s limited ability, the article is inevitable mistakes, welcome correction!
Appendix: relevant source code
There are two core configuration files: local.properties in the root directory of the project and Build. gradle in the app directory.
local.properties
## This file is automatically generated by Android Studio. # Do not modify this file -- YOUR CHANGES WILL BE ERASED! # # This file should *NOT* be checked into Version Control Systems, # as it contains information specific to your local configuration. # # Location of the SDK. This is only used by Gradle. # For customization when using a Version Control System, Please read the # header note.sdk. dir=C\:\ Users\ Dylan\ AppData\ Local\ Android\ SDK # # Signature file configuration information keyStoreFile=C\:\\Users\\Dylan\\Desktop\\signatureTest.jks keyStorePassword=123456 keyAlias=key0 keyAliasPassword=123456Copy the codeChange the information about the signature file to your own.
app//build.gradle
Properties = new Properties() InputStream InputStream = Project.rootproject.file ('local.properties').newDatainputStream () properties.load(inputStream) // Read the signature file def KeyKeyStoreFile = file(properties.getProperty('keyStoreFile')) // Read the alias and password of the signature file def keyKeyStorePassword = properties.getProperty('keyStorePassword') def keyKeyAlias = properties.getProperty('keyAlias') def keyKeyAliasPassword = properties.getProperty('keyAliasPassword') signingConfigs { release { storeFile keyKeyStoreFile storePassword keyKeyStorePassword keyAlias keyKeyAlias keyPassword keyKeyAliasPassword } debug { storeFile keyKeyStoreFile storePassword keyKeyStorePassword keyAlias keyKeyAlias keyPassword keyKeyAliasPassword } } compileSdkVersion 30 BuildToolsVersion "30.0.3" defaultConfig {applicationId "com.dylan. Signaturetest "minSdkVersion 21 targetSdkVersion 30 VersionCode versionName 1 "1.0" testInstrumentationRunner "androidx. Test. Runner. AndroidJUnitRunner"} buildTypes { release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' signingConfig signingConfigs.release } debug { signingConfig signingConfigs.debug debuggable true applicationIdSuffix '.debug' } } compileOptions { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility Javon_1_8} kotlinOptions {jvmTarget = '1.8'}}Copy the codeReferences:
BuildTypes — Android Gradle BuildType