Android projects use Android Studio and Gradle to pack multiple versions of APK

Source: Internet
Author: User
Tags custom name

There is often a need to package different versions of the APK during project development. such as debug version, release version, dev version and so on. Sometimes the different service-side API domain names used in different versions are not the same. Like debug_api.com,release_api.com,dev_api.com and so on.

Different versions correspond to different API domain names, and may also correspond to different icons.

It's not convenient if we change it manually before we pack it up every time.

But if we use Android Studio and Gradle, this hassle can be easily omitted.

Here's how: Add the following code to the Android node in Android Studio that opens Build.gradle (module)

12345678910111213141516171819 20212223 242526 27282930 313233 34353637 383940 41424344     
Buildtypes {The name here is custom and does not require capitalizationrelease{ Here is a suffix added to the applicationid. So, "." To addApplicationidsuffix ". Release" The function here is to choose whether to confuse the codeMinifyenabled falseProguardfiles getdefaultproguardfile (' proguard-android.txt '), ' Proguard-rules.pro '}dev{Applicationidsuffix ". Dev"Minifyenabled falseProguardfiles getdefaultproguardfile (' proguard-android.txt '), ' Proguard-rules.pro '}}This is to set up some special parameters for different versions, and it is not directly associated with BuildType.For example, using the dev version in BuildType, you can also use the custom parameters set in Flavors_release. This needs to be developed on its own terms.productflavors{Custom name can not be the same as above BuildType, or Gradle compile will not pass. The "Flavors_" prefix is used here to differentiate.//The variables set here can be used directly in "Androidmanifest.xml", using the following methods: ${package_name}//Android: Label= "${package_name}"  Manifestplaceholders = [str: "Releasestr", Package_name: " Com.sunhz.mvptest.release "] Resvalue ("string", "Strkey", "Releasestrvalue") } Manifestplaceholders = [str: "Devstr", Package_name: " Com.sunhz.mvptest.dev "] Resvalue (" string "," Strkey "," Devstrvalue ")           

Where do we use it when the above settings are complete?

Use the following: In the Android Studio toolbar, find the "Build" Item and find "Generate signed APK ...", as in.

Choose Module---Create APK key, or enter the APK key password--key! Such as.

At "BuildType", select the two buildtype we set up in Build.gradle, respectively, Releas,dev,debug. Where "Debug" comes with Android Studio.

At "Flavors", select the two flavors we set up in Build.gradle to facilitate direct use of the parameters defined in Build.gradle.

So! I mentioned above that there is no direct connection between buildtype and flavors. They can be used with each other according to user requirements. For example, BuildType chose release, but Flavors chose Flavors_dev.

The basic use of this is all done.

Here is a question, the different version of the package, all can be installed on the same phone, and can be two of all the packages posted to the Google market why is it?

Here is to mention in the BuildType we set the "Applicationidsuffix" attribute, according to the literal translation of this attribute: "ApplicationID suffix", then here comes a question, "ApplicationID" is what? In fact, this "ApplicationID" attribute is actually present in Build.gradle after the project is created. In the Defaultconfig node under the Android node. and the default ApplicationID and Androidmanifest.xml package properties are the same.

Such as:

We can see that the default values for these two properties are the same.

What is the relationship between ApplicationID and PackageName?

After the project is created by default, the two are the same. If you need to build different versions of the APK according to different requirements, we can do this by setting up "Applicationidsuffix".

There is a noticeable phenomenon here.

For example, we used the dev type when we packaged it and installed the packaged APK software on the phone.

Use the following code to get the PackageName of all the programs on our phone.

123456    
PackagemanagerPackagemanager=Mcontext.Getpackagemanager();List<PackageInfo>Packageinfolist=Packagemanager.Getinstalledpackages(Packagemanager.get_permissionslist<string> packagenamelist = new arraylist <string> ();  for  (packageinfo packageinfo : span class= "n" >packageinfolist) {  Packagenamelist. (packageinfo. Packagename}             /span>                

Com.spencer_dev.test.dev will appear in the package name information that we print out. did not appear com.spencer_dev.test.

But! If through the Anti-compilation tool, the APK package to decompile the direct view of the source code, in the Java code in the SRC directory of the package name, and we set the same as Com.spencer_dev.test. The application_id in the package and Buildconfig classes in Androidmanifest.xml have become com.spencer_dev.test.dev.

ApplicationID and PackageName, what do they each represent?

As a result of the above, the package represents the packet name in the Java code. ApplicationID represents a unique identity in your app. and application signatures are used together to differentiate from other apps. I think that's why the Google market allows different applicationid to be used in the same way.

For the demo project of this article, please see here. gradlebuildmultipleversionapk

Android projects use Android Studio and Gradle to pack multiple versions of APK

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.