Summary of Android channel packaging technology

Introduction

This article compares 4 channel packaging methods:

Unlike iOS's single channel (AppStore), Android platforms have a plethora of channels in China. For example, our app has 27 general channels (such as App Store, Baidu, and 360) and many more promotion-specific channels. Our packaging technology has also been improved several times.

1. Packaging with Gradle Product Favor

 android {
 productFlavors {
 base {
            manifestPlaceholders = [CHANNEL:"0"]
 }
 yingyongbao
            manifestPlaceholders = [ CHANNEL: "1" ]
 }
 baidu
            manifestPlaceholders = [ CHANNEL: "2" ]
 }
 }
 }

AndroidManifest.xml

 <! -- Self-use channel number settings -->  
 <meta-data
     android: name = "CHANNEL"  
     android:value="${CHANNEL}"/>

The principle is very simple. When gradle is compiled, it will replace the corresponding metadata placeholder in the manifest with the specified value according to this configuration. Then Android will retrieve it at runtime:

 public   static String getChannel(Context context) {
 String channel = "" ;
    PackageManager pm = sContext.getPackageManager();
 try {
        ApplicationInfo ai = pm.getApplicationInfo(
            context.getPackageName(),
            PackageManager.GET_META_DATA); 
 
        String value = ai.metaData.getString( "CHANNEL" );
 if (value != null ) {
 channel = value;
 }
 } catch (Exception e) {
 // Ignore the exception of not finding package information
 }
 return channel;
 }

This method has obvious disadvantages. Every time a channel package is installed, the apk compilation and packaging process will be fully executed, which is very slow. It takes more than an hour to install nearly 30 packages... The advantage is that it does not rely on other tools, and gradle can handle it by itself.

2. Replace Assets resource packaging

Assets is used to store some resources. Different from res, the resources in assets are kept as they are during compilation, and there is no need to generate any resource IDs. Therefore, we can generate different channel packages by replacing the files in assets without recompiling every time.

We know that apk is essentially a zip file, so we can do it by decompressing -> replacing the file -> compressing:

Here is a Python3 implementation

 # Decompress
 src_file_path = 'Original apk file path'  
 extract_dir = 'The target directory path for decompression'  
 os.makedirs(extract_dir, exist_ok= True ) 
 
 os.system(UNZIP_PATH + ' -o -d %s %s' % (extract_dir, src_file_path)) 
 
 # Delete signature information
 shutil.rmtree(os.path.join (extract_dir, ' META-INF' )) 
 
 # Write channel file assets/channel.conf
 channel_file_path = os.path.join (extract_dir, 'assets' , 'channel.conf' ) with   open (channel_file_path, mode= 'w' ) as f:
 f.write(channel) # Write the channel number into it
 os.chdir(extract_dir) 
 
 output_file_name = 'Output file name'  
 output_file_path = 'Output file path'  
 output_file_path_tmp = os.path.join (output_dir, output_file_name + '_tmp.apk' ) 
 
 # Compression
 os.system(ZIP_PATH + ' -r %s *' % output_file_path)
 os.rename(output_file_path, output_file_path_tmp) 
 
 # Re-sign
 # jarsigner -sigalg MD5withRSA -digestalg SHA1 -keystore your_keystore_path
 # -storepass your_storepass -signedjar your_signed_apk, your_unsigned_apk, your_alias
 signer_params = ' -verbose -sigalg MD5withRSA -digestalg SHA1' + \
 ' -keystore %s -storepass %s %s %s -sigFile CERT' % \
 (
 sign, #Signature file path
 store_pass, # store password
                    output_file_path_tmp,
 alias # Alias
 ) 
 
 os.system(JAR_SIGNER_PATH + signer_params) 
 
 Zip Alignment
 os.system(ZIP_ALIGN_PATH + ' -v 4 %s %s' % (output_file_path_tmp, output_file_path))
 os.remove(output_file_path_tmp)

Here, several PATHs represent the paths of the executable files zip, unzip, jarsigner, and zipalign.

Signature is an important mechanism of apk. It calculates a hash value for each file in apk (except those in META-INF directory) and records it in several files under META-INF. Zip alignment can optimize the efficiency of Android reading resources at runtime. Although this step is not necessary, it is still recommended.

With this method, we no longer need to compile Java code, and the speed is greatly improved. We can compile a package about every 10 seconds.

At the same time, the implementation code for reading the channel number is given:

 public   static String getChannel(Context context) {
 String channel = "" ;
 InputStream is = null ;
 try {
 is = context.getAssets(). open ( "channel.conf" );
        byte[] buffer = new byte[100];
 int l = is.read ( buffer) ; 
 
        channel = new String(buffer, 0, l);
 } catch (IOException e) {
 // If it cannot be read, then use the default value
 finally
 if ( is != null ) {
 try {
 is . close ();
            } catch (Exception ignored) {
 }
 }
 }
 return channel;
 }

By the way, you can also use the aapt tool to replace zip&unzip to achieve file replacement:

 # Replace assets/channel.conf
 os.chdir(base_dir)
 os.system(AAPT_PATH + ' remove %s assets/channel.conf' % output_file_path_tmp)
 os.system(AAPT_PATH + ' add %s assets/channel.conf' % output_file_path_tmp)

3. A solution provided by Meituan

As mentioned above, the META-INF directory is exempt from the signing mechanism. Putting things in it can avoid the re-signing step. This is what the Meituan technical team did.

 import zipfile
 zipped = zipfile.ZipFile(your_apk, 'a' , zipfile.ZIP_DEFLATED)
 empty_channel_file = "META-INF/mtchannel_{channel}" .format(channel=your_channel)
 zipped.write(your_empty_file, empty_channel_file)

Add an empty file named "mtchannel_channel number" to the META-INFO directory, find this file in Java, and get the file name:

 public   static String getChannel(Context context) {
    ApplicationInfo appinfo = context.getApplicationInfo();
    String sourceDir = appinfo.sourceDir;
 String ret = "" ;
 ZipFile zipfile = null ;
 try {
        zipfile = new ZipFile(sourceDir);
        Enumeration<?> entries = zipfile.entries();
        while (entries.hasMoreElements()) {
            ZipEntry entry = ((ZipEntry) entries.nextElement());
            String entryName = entry.getName();
            if (entryName.startsWith( "mtchannel" )) {
                ret = entryName;
 break;
 }
 }
 } catch (IOException e) {
 e.printStackTrace();
 finally
        if (zipfile != null ) {
 try {
                zipfile.close ();
            } catch (IOException e) {
                e.printStackTrace();
 }
 }
 } 
 
    String[] split = ret.split( "_" );
    if (split != null && split.length >= 2) {
 return ret.substring ( split[0].length() + 1); 
 
 } else {
 return   "" ;
 }
 }

This method eliminates the need for re-signing and greatly increases the speed. They describe it as "more than 900 channels can be completed in less than a minute", which means less than 0.06 seconds per packet.

4. The ultimate solution to using Zip file comments

In addition, an ultimate solution is given: we know that there is an area at the end of the Zip file that can be used to store the file's comments. Changing this area will not affect the content of the Zip file at all.

The packaged code is simple:

 shutil.copyfile(src_file_path, output_file_path) 
 
 with zipfile.ZipFile(output_file_path, mode= 'a' ) as zipFile:
     zipFile.comment = bytes(channel, encoding='utf8')

The difference between this method and the previous one is that it does not modify the content of the Apk, so there is no need to repackage it, and the speed is improved!

According to the documentation, this method can send more than 300 packets within 1 second, which means that the time for a single packet is less than 10 milliseconds!

The code for reading is a little more complicated.

Java 7's ZipFile class has a getComment method that can easily read the comment value. However, this method is only available in Android 4.4 and higher versions, so we need to spend more time porting this logic over. Fortunately, the logic here is not complicated. If we look at the source code, we can see that the main logic is in a private method readCentralDir of ZipFile, and a small part of the logic for reading binary data is in libcore.io.HeapBufferIterator. We can move all of them over and organize them to get it done:

 public   static String getChannel(Context context) {
   String packagePath = context.getPackageCodePath(); 
 
   RandomAccessFile raf = null ;
 String channel = "" ;
 try {
      raf = new RandomAccessFile(packagePath, "r" );
      channel = readChannel(raf);
 } catch (IOException e) {
 // ignore  
 finally
 if (raf != null ) {
 try {
 raf.close ();
         } catch (IOException e) {
 // ignore  
 }
 }
 } 
 
 return channel;}private static final long LOCSIG = 0x4034b50;private static final long ENDSIG = 0x6054b50;private static final int ENDHDR = 22;private static short peekShort(byte[] src, int offset) {
 return (short) ((src[offset + 1] << 8) | (src[offset] & 0xff));}private static String readChannel(RandomAccessFile raf) throws IOException {
   // Scan back, looking for the End   Of Central Directory field. If the zip file doesn't
   // have an overall comment (unrelated to   any per-entry comments), we'll hit the EOCD
 // on the first try.
   // No need to synchronize raf here -- we only do this when we first open the zip file.  
   long scanOffset = raf.length() - ENDHDR;
 if (scanOffset < 0) {
      throw new ZipException( "File too short to be a zip file: " + raf.length());
 } 
 
 raf.seek(0);
   final int headerMagic = Integer .reverseBytes(raf.readInt());
   if (headerMagic == ENDSIG) {
      throw new ZipException( "Empty zip archive not supported" );
 }
   if (headerMagic != LOCSIG) {
      throw new ZipException( "Not a zip archive" );
 } 
 
   long stopOffset = scanOffset - 65536;
 if (stopOffset < 0) {
 stopOffset = 0;
 } 
 
 while ( true ) {
 raf.seek(scanOffset);
      if ( Integer .reverseBytes(raf.readInt()) == ENDSIG) {
 break;
 } 
 
 scanOffset --;  
      if (scanOffset < stopOffset) {
         throw new ZipException( "End Of Central Directory signature not found" );
 }
 } 
 
 // Read the End   Of Central Directory. ENDHDR includes the signature bytes,
   // which we've already read .
   byte[] eocd = new byte[ENDHDR - 4];
 raf.readFully(eocd); 
 
   // Pull out the information we need.
 int position = 0;
 int diskNumber = peekShort(eocd, position) & 0xffff;
 position += 2;
 int diskWithCentralDir = peekShort(eocd, position) & 0xffff;
 position += 2;
 int numEntries = peekShort(eocd, position) & 0xffff;
 position += 2;
 int totalNumEntries = peekShort(eocd, position) & 0xffff;
 position += 2;
   position += 4; // Ignore centralDirSize.
   // long centralDirOffset = ((long) peekInt(eocd, position)) & 0xffffffffL;
 position += 4;
 int commentLength = peekShort(eocd, position) & 0xffff;
 position += 2; 
 
   if (numEntries != totalNumEntries || diskNumber != 0 || diskWithCentralDir != 0) {
      throw new ZipException( "Spanned archives not supported" );
 } 
 
 String comment = "" ;
 if (commentLength > 0) {
      byte[] commentBytes = new byte[commentLength];
      raf.readFully(commentBytes);
      comment = new String(commentBytes, 0, commentBytes.length, Charset.forName( "UTF-8" ));
 }
 return comment;
 }

It should be noted that Android 7.0 has added APK Signature Scheme v2 technology. In Android Plugin for Gradle 2.2, this technology is enabled by default, which will cause the packages generated by the third and fourth methods to fail to verify under Android 7.0. There are two solutions: one is to lower the Gradle version, and the other is to add the configuration v2SigningEnabled false under signingConfigs/release. For detailed instructions, see Google's documentation

Summarize

Speak with the form