Android realizes app environment separation (using gradle)

1、 Introduction to environmental separation

Each app project will have at least two environments: test environment and production environment. There are even four environments: development environment, test environment, pre production environment and production environment. Developers often need to switch between environments, as do testers. It often happens that testers need the latest version of the test environment today, and ask app developers to package one for her. Tomorrow, they need to switch to the production version, and then ask app developers to package one for her. We know that an app on a mobile phone can only be in the test environment or in the production environment. If testers want to test two environments, they can only constantly replace the same app in different environments, which is too troublesome. In order to solve this problem, the best solution is to separate the environment. Different environments have different apps.

However, for android app, only one APK with the same package name can exist on the same device. Therefore, we can not install the installation package of production environment and test environment on the same equipment at the same time, which is very inconvenient for daily development work and testing work of testers. You can't copy the whole project and package another APK by modifying the package name. Therefore, in this case, a common practice in the past is to provide an invisible entry in the app for insiders to switch the server address, and then restart the app through the following code:

Obviously, this approach is only a delaying measure, which is still somewhat unsatisfactory. Fortunately, however, after entering the era of Android studio, Google began to use gradle to build the system. The emergence of applicationid solved the problem of environment separation.

2、 Package and applicationid

In the APK or old gradle build system developed with eclipse, the package name of the application is determined by androidmanifest Determined by the package attribute in the XML file. At the same time, this package is also used to define and name the referenced resource class R file.

However, in the new Android gradle building system, the two functions of the package attribute are understood: applicationid is used as the unique identifier (package name) of the application to distinguish different applications; The package attribute defines the resource class R file for reference.

Applicationid exists in APP / build Under the defaultconfig configuration in the gradle file, the package attribute value is used for initialization by default when creating a new project. Therefore, if there are no special requirements, we generally won't care about and modify this value:

Therefore, to realize APK environment separation, that is, to install different versions of the same application on the same device, essentially, we need to modify the value of applicationid and build APK installation files packaged with different package names. Gradle build system provides two ways for developers to modify the value of applicationid, productflavors and buildtypes. Through these two ways, we can easily realize the packaging customization of APK, or build variants.

3、 Build variants

The productflavors and buildtypes configurations of the project can be found in APP / build The function of modifying gradle code file or project structure is the same.

4、 Productflavors

Different customized versions of the application can be realized by defining multiple different productflavors. Each flavor works with buildtypes to produce an APK file of the corresponding output type. The initialization of the new project has only one default flavor: defaultconfig

Note: the default defaultconfig provides the basic configuration for the newly created productflavors, that is, the configuration of productflavors will override the same attributes in the defaultconfig, so as to realize the output of different customized versions of products. For environment separation, this can be achieved by defining a new applicationid attribute.

5、 Buildtypes

By default, the buildtypes of the project includes two build versions: debug and release. The signature file needs to be manually set for the implementation of the release version. For environment separation, different from productflavors, buildtypes is realized by defining applicationidsuffix, that is, adding suffix:

In addition to these configurable properties, productflavors and buildtypes provide code and resources through their respective sourcesets. The default paths are Src / flavorname and Src / typename. Using this feature, we can implement different customized versions of APK to display different application names and desktop icons, so as to distinguish from devices.

Productflavors and buildtypes cooperate to produce build variants in the format of "flavor name + typename" to package different versions of APK. When you do not have custom flavors, the default defaultconfig will also form build variants corresponding to buildtypes, but there is no name, so it is displayed as debug and release. For example, this configuration:

We have configured two types of product flavors, beta and production, and two types of buildtypes, release and debug. Therefore, there are four corresponding build variants: betadebug, betarelease, productiondebug and productrelease. You can view and select the corresponding build type to run the application in the build variants window:

Note: as mentioned earlier, buildtypes modifies the applicationid (package name) by adding a suffix. In other words, it modifies the package name based on productflavors. Therefore, in the above example, the package name of the APK file packaged by the beta release build type is: com yifeng. mdstudysamples. beta. debug。

5、 Implementation mode

Through the above introduction, you can basically know how to separate the app environment on Android. We can choose to use productflavors and buildtypes to install different versions of the same application on the same device. They are the same in principle, but it is more convenient to use buildtypes without creating new productflavors. Here, I will take buildtypes as an example to briefly describe the implementation of environment separation.

1. For a project configured with default productflavors and buildtypes, we modify the applicationidsuffix attribute of the debug configuration to ". Debug" (the name can be set at will), and the release version does not need to be changed.

With this step, you can install the debug version and the release APK on the same device. You can also do better, such as modifying the desktop icon and application name of the debug version to facilitate differentiation.

2. We create a new debug directory in the SRC directory, copy a copy of the res directory in the main directory to the debug directory, and modify the desktop icon and strings in each resolution The application name in the XML file, plus a debug ID. The directory structure is shown in the figure:

During the construction and packaging, the res resources in the debug directory are merged into main by superposition and replaced with the same content. In this example, only the desktop icon and application name need to be modified, so I only copied the relevant files in the res directory, and other files were not copied.

3. Modify the server interface address in the code, select the corresponding build variants type, and run it. In fact, you can also use string. In the debug and main directories The server address is defined in the XML resource file, and then assigned to the global static variable in the code at the entrance of the program.

summary

The above is the whole content of this article. I hope it can bring some help to your study or work. If you have any questions, you can leave a message.