Multi-Version Management for Android Projects

Multi-Version Management for Android Projects

 

Based on git's powerful branch capabilities, the android project can generate multiple versions of different UIS from one basic version, and synchronize the main logic code to achieve different appearances, same heart. The basic principle is to use <orinial-package/> to specify the base package name. The following are the implementation steps:

0. Prerequisites: Git remote branch management

1. Prepare the basic version.

Multiple version management features the same logic and different UI. For the Future merge main logic, we need to ensure that the package names of the main logic code between different branches are consistent, at the same time, in order to release different UI versions, the package names of the program need to be differentiated. It seems that these two points are in conflict. At this time, the important attributes are displayed: <orinial-package/>! This attribute is used to specify the package name of the main logic code, and <package/> is used to specify the package name of the program. Here, a word is used to hold the space, for example. base_version, so that you can add a new UI branch and replace it with the new package name. Use the following code:

 

<manifest xmlns:android="http://schemas.android.com/apk/res/android"    package="com.pkgname.base_version"    android:versionCode="1"    android:versionName="0.00.00" >    <original-package android:name="com.pkgname" />

 

Another preparation: To avoid database conflicts, change the authority of all databases to "com. pkgname. base_version"

 

 

2. generate a new version Branch

2.1 generate a new branch from base_version, for example, my_ui_branch_0. Assume that the branch of the current base version is develop:

 $git checkout develop -b my_ui_branch_0

2.2 globally Replace "com. pkgname. base_version" with "com. pkgname. my_ui_branch_0 ″.

2.3 change ". yourcomponent" in androidmanifest. XML to "com. pkgname. yourcomponent ".

2.4 git commit generates a commit.

3. Save the new version to the remote branch.

$git push origin my_ui_branch_0

4. How to operate branches.

Two principles:

Principle 1: The merge direction is from base_version => my_ui_branch_n, and the reverse direction is serious.

Principle 2: Make sure to modify the public logic or UI on base_version.

So far, we can happily generate a branch with the new package name. When there is a bug, there is no need to worry about the synchronization of multiple versions, you only need to modify it on base_version and merge it to other branches.