Android build variants how to set variant versions for projects

preface

This situation is often encountered during project development:

1. The same API of the same project has several different interfaces, such as the server for internal testing and the server exposed to users in the current version;

2. The same project has free version and paid version

3. The same project has different constants in different environments

Of course, we can simply handle APIs in different situations in this way:

Or in this case:

In different environments, we switch the use of corresponding APIs through comments. For example, during development, we use the "test / subject" interface of intranet server, and switch the officially released version to the "production / subject" interface;

Similarly:

In different environments, we open 1000 and comment out 10000 through annotation; When the version is released, comment out 1000 and open 10000

However, this operation is too cumbersome and cumbersome. We can use a higher way of big, such as a function configured by Android studio for developers: build variables.

1. Build.gradle configuration in module:

OK, after the basic configuration is completed, click sync to synchronize the project and open the build variants menu in the lower left corner of Android Studio:

Without considering the code on the right, we see the "productiondebug" button of our module, which means that our current environment is the officially released version of the debug mode. What models do we have?

We can see that the number of the four variants we have is just the result of "buildtypes" * "productflavors" in the "build. Gradle" file, so we can develop different variants accordingly.

2. Build variant trial:

Now we can add some small "seasonings" to the build.gradle file:

Add to your string resource file:

Then add the placeholder ${app_name} to your manifest file manifest.xml:

Then we switch to the productiondebug version and click Run:

In the simulator, the app we obtained:

Then we switch to the devdebug version and click Run:

In the simulator, the app we obtained:

Isn't it convenient! In fact, we can also observe that when we switch different variants, gradle is also compiling. We are not switching variants, but more accurately, we are switching two different versions of code!

3. Build variant in-depth learning:

If it's no use just changing the name of an app, we create two different folders in the corresponding directory of the project:

As shown in the figure, we have created two folders, "production" and "dev". What are these two folders used for? When we switch different variants, the code used by our app will be found from the corresponding folder!

For example:

If we create two constantsapi files, obviously we want to put the second "constantsapi" file into the dev version corresponding to the "development environment". We can do this:

Create a folder with the same directory as Src / main (this is best and not easy to mess)

At this time, we switch to our dev variant version and open our Android view. We can see:

Similarly, we create the same folder in the production directory in the same way, put another 10s constantsapi file in this directory, and switch to the productiondebug variant. We will see again:

We can see that folders of different variants will be displayed only when we switch to this variant. For example, dev variant only displays dev folder and does not display production folder. When we switch to production variant, dev also disappears.

What's more amazing is that we use these variables to run the code, and the results are different because of different versions. We use the dev variant version. We only need to wait for 1s and switch to the production version, and we can package and publish directly.

4. Summary

The benefits are obvious. First of all, no matter how many different environment configurations we have, we only need to configure them once. In the future, if we want to switch to which environment, we only need to switch to the variant; Secondly, such a structure is very clear, which means that we have N sets of different versions of code. If there are more versions of code, people will be confused.