Recently, I often saw some articles shared by my colleagues in the company. I came across an article about operation, which said that operation and technology are inseparable balabala.

Put a few pictures, see the effect, intuitive and convenient.

These three apps, installed on the same machine is the same set of code, can you believe? General sub-channel packaging, is the same set of code, but the APP is also the same, but the channel is not the same. I have an app that looks and looks different inside. Do not believe you:

ASO technology, a thing that can make a product quickly popular, typical company, a Malayan listens to (no evaluation, no quarrel, just technology). Without further ado, let’s go to the technology sharing stage.

#### first talk about the difference between “multi-channel packaging” and “multi-package name” packaging.

1. Multi-channel packaging, generally used in app distribution statistics in major application markets. For example, 360 application platform, Application Treasure, Wandoujia, etc. 2. Multi-name package, which I came up with by myself, is actually a part of ASO. To be sure, it should be multi-ID package, which means a set of app code is packaged into many apps. This is mostly used for ASO technology, because there is no online tutorial, so I write a copy for your reference.

Because there is a lot of information on the technical web, so I will not repeat it.

ApplicationId is the same as applicationId. ApplicationId is the same as applicationId.

#### “productFlavors” is an option that you can use to change your options.

The code is as follows:

ProductFlavors {yunweikang {// Each environment package name is different applicationId"com.bill.first.yunweikang"// Add string. XML field dynamically; // Note that this is an add. in string. XML, this field cannot have the same name!! resValue"string"."app_name"."Cloud Weikang"// // dynamically modifies the constant field buildConfigField"String"."ENVIRONMENT"."My name is Weikang Yun."Manifestplaceholder = [CHANNEL_VALUE:"yunweikang",
                                    JPUSH_CHANNEL: "yunweikang",
                                    app_icon     : "@mipmap/ic_yunweikang",
                                    appkey       : "4e3a7bbd9f3da0f9064e6580"]
        }
        liulvguangyin {
            applicationId "com.bill.second.liulvguangyin"// Note that this is an add. in string. XML, this field cannot have the same name!! resValue"string"."app_name"."Six notes of light."

            buildConfigField "String"."ENVIRONMENT"."My name is Six notes of light."
            manifestPlaceholders = [CHANNEL_VALUE: "liulvguangyin",
                                    JPUSH_CHANNEL: "liulvguangyin",
                                    app_icon     : "@mipmap/ic_liulvguangyin",
                                    appkey       : "91022ae3a6df48ea523c70f8"]
        }
        jin {
            applicationId "com.bill.third.jin"// Note that this is an add. in string. XML, this field cannot have the same name!! resValue"string"."app_name"."Gold"

            buildConfigField "String"."ENVIRONMENT"."My name is Kim."

            manifestPlaceholders = [CHANNEL_VALUE: "jinmaike",
                                    JPUSH_CHANNEL: "jinmaike"
                                    , app_icon   : "@mipmap/ic_jin",
                                    appkey       : "1c0c49844d4d2900cb7fd30b"]}Copy the code

A quick explanation of the above code: “Yunweikang” defines a product (in the case of “multi-package-name packaging” that is the focus of this article).

An applicationId corresponds to a product in the application market. Even if it is the same set of code, as long as the applicationId is different, there are several Applicationids are several products.

ResValue “string”, “app_name”, “yunweikangthis is a file that dynamically generates strings. XML

BuildConfigField “String”, “ENVIRONMENT”, “My name is Yunweikang “, this is a variable that will be dynamically generated in BuildConfig. For example BuildConfig. DEBUG.

Manifestplaceholder Defines the contents of the manifestplaceholder, which is conveniently referenced in androidManifest.xml, in the following code:

 <application
        android:name=".app.PackApplication"
        android:allowBackup="true"
        android:icon="${app_icon}"
        android:label="@string/app_name"
        android:roundIcon="${app_icon}"
        android:supportsRtl="true"
        android:theme="@style/AppTheme">Copy the code

${}

Note: Don’t forget to quote the following sentence in the root node

xmlns:tools="http://schemas.android.com/tools"Copy the code

#### let’s talk more about * Some potholes in the document when multiple package names are introduced in aurora push

1. Tell me why the package name is “applicationId”

]

2. When registering, some are real package names and some are Applicationids, which the Aurora Push team calls “package names.”

! [Uploading QQ screenshot 20171028105410_986493.png..]

#### to summarize: Although the aurora team’s documentation is flawed, it is understandable, partly because of Google. After all, in the beginning Eclipse has no difference between applicationId and packageName. However, I hope the Aurora team can revise the document and make it as perfect as possible. This should be aite “Aurora Push Team”

ApplicationId Android applicationId 2. Gradle application. 3. Some errors in documentation when multiple package names are packaged

In fact, the discovery is not what black technology, but as a development, always want to understand some of the things hot operation, in case later transfer to the management, life should have a dream, in case it is realized!

Finally attached I wrote the demo address, like you can pay attention to a wave. Github.com/billllll1ll…