Android enables app-environment separation (using Gradle) _android

Introduction of environmental separation

There are at least two environments for each app project: test environment and production environment. There are even four environments: the development environment, the test environment, the pre production environment, and the production environment. Developers often need to switch between environments, as do testers. Often, testers today need to test the latest version of the environment, ask the app developer to pack one to her, tomorrow need to switch to the production version, and then ask the app developer to pack a production environment for her. We know that an app, on a mobile phone, can only be a test environment or a production environment. It's too much trouble for testers to test two environments and just keep replacing the same app in different environments. In order to solve this problem, the best solution is the environment separation, different environments have different app.

But for Android apps, apk with the same package name can only exist on the same device. So we are not able to install both the production environment and the test environment installation package on the same device, which is very inconvenient for the daily development work and the tester's test work. The whole project can not be copied, and then by modifying the package name of the way to pack out another apk bar. So in this case, the usual practice is to provide an invisible entry in the app for the internal staff to switch the server address, and then restart the app with the following code:

private void Restartapp () {
 Intent Intent = GetContext (). Getpackagemanager (). Getlaunchintentforpackage ( GetContext (). Getpackagename ());
 Intent.addflags (intent.flag_activity_clear_top);
 StartActivity (intent);
}

Clearly, this approach is only a tactic, somewhat unsatisfactory. Fortunately, however, after entering the Android studio era, Google began to use the introduction of Gradle to build the system, the emergence of ApplicationID makes the problem of environmental separation solved.

Ii. Package and ApplicationID

In a Gradle build system using Eclipse development apk or an older version, the package name that is applied is determined by the package attribute in the Androidmanifest.xml file. At the same time, this package is also used to define the named referenced resource class R file.

But in the new Android Gradle build system, the two roles of the package attribute are understood: ApplicationID as the unique identifier (package name) for the application to differentiate between different applications; Package attribute defines the resource class R file for reference.

ApplicationID exists under the Defaultconfig configuration in the App/build.gradle file, the Package property value is initialized by default when a new project is created, so if there are no special requirements, we generally do not care and modify this value:

Apply plugin: ' Com.android.application '

android {
 compilesdkversion
 buildtoolsversion "19.1"

 defaultconfig {
 ApplicationID "Com.example.my.app"
 minsdkversion
 targetsdkversion
 Versioncode 1
 versionname "1.0"
 }
 ...

Therefore, to achieve APK environment separation, that is, to install the same application on the same device different versions, from the nature we want to modify the value of ApplicationID, build a package of different package name APK installation files. The Gradle build system provides two ways for developers to modify the value of ApplicationID, Productflavors and Buildtypes, by which we can easily implement APK packaging customization, or building Variants (build variant).

Third, build variants

The productflavors and Buildtypes configurations of the project can be modified on the App/build.gradle code file or project structure, and the effect is the same.

Four, productflavors

The project can implement different customized versions of the application by defining several different productflavors, each apk file of an output type corresponding to the output of each flavor and buildtypes. The new project initialization has only one default Flavor:defaultconfig

Note: The default Defaultconfig provides a basic configuration for the new productflavors, which means that productflavors configuration overrides the same properties in Defaultconfig. So as to achieve different customized version of the product output. For environment separation, this can be done by defining a new ApplicationID property.

Five, Buildtypes

By default, the project's Buildtypes contains debug and release two builds, where the release version of the execution needs to manually set the signature file. For environment separation, unlike Productflavors, Buildtypes is implemented by defining Applicationidsuffix, which adds a suffix name:

In addition to these configurable properties, Productflavors and Buildtypes provide code and resources through their respective sourceset, with the default path: Src/flavorname and Src/typename. With this feature, we can implement different custom versions of the APK display different application names and desktop icons to differentiate from the device.

Productflavors and Buildtypes together with the output of a variety of formats for "Flavorname + typeName" build variants to package different versions of the APK. When you do not have a custom flavors, the default defaultconfig will also form a corresponding build variants with buildtypes, just without a name, so it appears as debug and release. For example, this configuration:

Android {

 ...

 productflavors{
 beta{
  applicationid ' Com.yifeng.mdstudysamples.beta '
 }
 production{
  ApplicationID ' Com.yifeng.mdstudysamples '
 }
 }

 buildtypes {release
 {
  minifyenabled false
  proguardfiles getdefaultproguardfile (' proguard-android.txt '), ' Proguard-rules.pro '
 }
 Debug {
  applicationidsuffix '. Debug '
 }
 }
}

We have configured beta and production two kinds of productflavors,release and debug two kinds of buildtypes. Therefore, the corresponding build variants there are four kinds, respectively: Betadebug, Betarelease, Productiondebug and Productrelease. You can view and select the corresponding build type to run the application in the Variants window:

Note: As mentioned earlier, Buildtypes modifies the ApplicationID (package name) by adding a suffix, in other words, by modifying the package name on a productflavors basis. So, in the example above, the package name of the APK file packaged by the Betarelease build type is: Com.yifeng.mdstudysamples.beta.debug.

V. Ways of implementation

With these introductions, you can basically see how the app's environment is decoupled on Android. We can choose to install different versions of the same application on the same device using both Productflavors and buildtypes. They are the same reason, but in contrast, the use of buildtypes without new productflavors, more convenient. Here I will buildtypes for an example to describe the implementation of environmental separation briefly.

1. For a project with a default productflavors and Buildtypes configuration, we modify the Applicationidsuffix property of the Debug configuration, set to ". Debug" (the name can be set at will), release version does not change.

Android {

 ...

 Buildtypes {release
 {
  minifyenabled false
  proguardfiles getdefaultproguardfile (' Proguard-android.txt ' ), ' Proguard-rules.pro '
 }
 debug {
  applicationidsuffix '. Debug '
 }
 }
}

With this step, you have been able to install the debug version and release apk on the same device. can also do better, such as modifying the debug version of the desktop icon, application name, etc., easy to distinguish.

2. We create a new debug directory under the SRC directory, copy the Res directory in the main directory to the debug directory, modify the application name in the desktop icon and Strings.xml file under each resolution, and add a debug logo. The directory structure is as shown in the figure:

When you build a package, the RES resource in the Debug directory is merged into main and replaces the same content, and this example only needs to modify the desktop icon and the application name, so I only copy the related files in the Res directory, and the other files are not replicated.

3. Modify the server interface address in the code, select the corresponding build variants type, run it. You can also define the server address in the String.xml resource file in the Debug and main directories, and then assign a value to the global static variable in your code at the entrance to the program.

Summarize

The above is the entire content of this article, I hope to be able to learn or work to bring certain help, if you have questions you can message exchange.