| |
In the project development process, there is often a need to package different versions of APK needs. For example, debug version, release version, dev version and so on. Sometimes different versions to use a different domain name server api is not the same. For example debug_api.com, release_api.com, dev_api.com like.
Different versions corresponding to different api domain may also correspond to different icon and the like.
If every time we have to modify the package before manually modified so that it is not convenient enough.
But if we use Android Studio and Gradle, this trouble can easily be omitted.
Here's how: add the following code to open build.gradle (Module in) the android next node in Android Studio
buildTypes {
// The name of the custom here, the case is not required
release {
// Here is the addition of a suffix applicationId in. So "." To add
applicationIdSuffix ".release"
// Here is to select whether obfuscated code
minifyEnabled false
proguardFiles getDefaultProguardFile ( 'proguard-android.txt'), 'proguard-rules.pro'
}
dev {
applicationIdSuffix ".dev"
minifyEnabled false
proguardFiles getDefaultProguardFile ( 'proguard-android.txt'), 'proguard-rules.pro'
}
}
// Here for different versions had set some special parameters, and buildType not directly related.
// For example: Use buildType the dev version, you can also use custom parameters flavors_release set up inside. This requires the development in accordance with their own needs.
productFlavors {
// Custom name but not the same as above buildType, or Gradle compilation fails. As used herein, a "flavors_" prefix to distinguish.
flavors_release {
// ManifestPlaceholders wrote of "str", "package_name" does not support the use of capital letters, otherwise Gradle compiler will not pass.
// Set variable here can be used directly in the "AndroidManifest.xml", the use of: $ {package_name}
// Android: label = "$ {package_name}"
manifestPlaceholders = [str: "releaseStr", package_name: "com.sunhz.mvptest.release"]
// Parameter here is to use java code, the specific use is:. Context.getResources () getString (R.string.strKey);
resValue ( "string", "strKey", "releaseStrValue")
}
flavors_dev {
manifestPlaceholders = [str: "devStr", package_name: "com.sunhz.mvptest.dev"]
resValue ( "string", "strKey", "devStrValue")
}
}
After completion of the above settings, where we want to use it?
Use the following manner: In Android Studio toolbar, find the "Build" items, find the "Generate Signed APK ..."
Select Module -> Create APK key, or enter the password APK key -> The key here!
In the "BuildType" field, you select two BuildType we set in build.gradle in, respectively, releas, dev, debug. Wherein the "debug" comes to Android Studio.
In the "Flavors" at select two Flavors we set in build.gradle in order to facilitate direct use parameters defined in the build.gradle customized.
and so! Above I have mentioned that, buildType and Flavors no direct contact. They can be used in conjunction with each other according to user needs. As shown above, BuildType selected release, but Flavors choice is flavors_dev.
This basic use on all finished.
There is a problem, playing out different versions of the package, all can be installed on the same phone, all the two packets and can be published to Google's market upswing Why is this?
Here we must mention "applicationIdSuffix" attribute in BuildType we set up, according to the literal translation of this attribute is: "applicationId suffix", then there comes a question, "What is applicationId" is the? In fact, this "applicationId" attribute, in fact, after the completion of the project to create a presence in the build.gradle. In defaultConfig node node under the android. And the same default applicationId and in AndroidManifest.xml package properties.
We can see, the default value of these two properties are the same.
applicationId and they packageName What is the relationship?
After the project is created by default, both the same. If you need to build different versions of APK according to different needs, then we set up "applicationIdSuffix" can do it.
There is a noteworthy phenomenon.
For example, we use a dev type when packaged, packaged software is installed out of the APK to your phone.
Use the following code to get packageName all the programs on our phone.
PackageManager packageManager = mContext.getPackageManager ();
List packageInfoList = packageManager.getInstalledPackages (PackageManager.GET_PERMISSIONS);
List packageNameList = new ArrayList ();
for (PackageInfo packageInfo: packageInfoList) {
packageNameList.add (packageInfo.packageName);
}
We print out the information in the package name will appear com.spencer_dev.test.dev. Com.spencer_dev.test did not appear.
but! If decompile tool, APK package decompile directly view the source code, java code where the src directory of the package name, and also, as we have set for com.spencer_dev.test. The package can AndroidManifest.xml and BuildConfig class APPLICATION_ID has become com.spencer_dev.test.dev.
applicationId packageName and what they each represent?
According to the above results, it, package represents the java code package. applicationId represents a unique identification applications. And signed application and other applications together to distinguish different. I think this is why Google market reason to allow the same application of different applicationId. |
|
|
|