Sharing is Caring!

Share on facebook
Share on twitter
Share on pinterest
Share on linkedin
Share on vk
Share on email

Android apps are usually written in Java* due to its elegant object-oriented design and the truth that the Android Software program Growth Package (Android SDK) offers cross-platform options in Java. At instances, nevertheless, builders want to make use of Android’s native interface, particularly if reminiscence administration and efficiency are crucial points. Android’s native interface is supplied by way of the Native Growth Package (NDK), which helps native improvement in C/C++.

There are a lot of NDK apps on the Google software program market. To cut back package deal measurement, some ISVs launch a single APK however not a FAT APK (a single APK comprises both an ARM* or an x86 library, whereas a FAT APK has each). FAT APKs have benefits over single APKs. They’re simpler for finish customers to entry and the libraries aren’t overlapped throughout utility updating. Builders are, subsequently, inspired to make FAT APKs for the x86 Android software program ecosystem. However how can builders mitigate giant FAT APK file sizes?

Zip* vs. LZMA

To resolve the FAT APK measurement drawback, the writer has developed a local library compression SDK. The fundamental thought makes use of the Lempel–Ziv–Markov chain algorithm (LZMA) (LZMA SDK (Software program Growth Package)) to compress native libraries. Google makes use of Zip to compress the entire content material, and whereas Zip is quick, its compression charge is decrease than LZMA. LZMA is particularly good for compressing the big dictionary information present in native libraries. The next graph exhibits the distinction in file sizes after performing compressions with Zip and LZMA.

 

Determine 1: Dimension comparability of a file after being compressed with Zip* and LZMA1

 

Determine 2: Dimension comparability of a number of information (similar CPU structure) after being compressed with Zip* and LZMA1

 

Determine 3: Dimension comparability of a number of information (completely different CPU structure) after being compressed with Zip* and LZMA1

 

Determine 4: Dimension comparability of three similar information after being compressed with Zip* and LZMA1

From the 4 charts above, we might conclude that LZMA can scale back the redundancy between the information. Within the excessive (three similar information), LZMA can get the next compression charge than Zip. This function is especially appropriate for compressing native libraries. Typically, a local library will use the identical code to get “armeabi”,”armeabi-v7a”,”x86” and even “mips” libraries, and for “armeabi-v7a” there may be ARM NEON* and non-NEON code as nicely. These libraries have redundancies as a result of similar supply code. Even with completely different structure, for instance,libffmpeg_armv7_vfpv3.so and libffmpeg_x86.so, when one is ARMEABI and the opposite is x86, the compression charge is 40%, whereas for a single file, the speed is barely 20%.

Native Library Compression SDK

The native library compression SDK, the writer developed, may help app developer to combine the LZMA native library compression to acquire smaller information. The core thought of this SDK is to compress all the native library into theasserts folder as follows.

The API on this SDK could be very easy. On the primary run of this utility, the code extracts all the native library from the asserts folder.

static boolean NewInstance(Context cont,Handler hdl,boolean showProgress)

static DecRawso GetInstance()

String GetPath(String libname)

It is suggested that app builders ought to modify the supply code and add solely NewInstance when the appliance begins, then change system.loadlibrary

Card image cap

Android Q becomes Android 10 as Google abandons sugary treat names

 to system.load(DecRawso . GetInstance ().GetPath

Card image cap

Android Q becomes Android 10 as Google abandons sugary treat names

). After these minor modifications, the APK can be smaller but run the identical as earlier than.

If builders can guarantee sufficient delay from the calling of NewInstance to the primary loading of native library, they need to name (NewInstance (cont,null,false)) with out the Handler. In any other case, a Handler ought to be handed to obtain the “decode finish” asynchronous message.

The writer built-in this SDK into MoboPlayer* on an Intel® Atom™ Z2760 processor-based pill (codenamed Clover Path). The code calls NewInstance within the synchronization methodology when customers begin the app and the splash display screen is displayed. Calling NewInsance  is clear to the tip person because the decoding is completed within the background. The next chart exhibits the compression outcome.

 

Desk 5: MoboPlayer* FAT APK measurement compression1

Enhanced Features of Native Library Compression SDK

Moreover the LZMA compression, this SDK offers extra features to encourage builders to incorporate an x86 native library with the next: 

  1. Cloud Storage: ISVs can retailer the x86 libraries on the cloud server, and these libraries may be downloaded from the server after set up. This motion is mechanically finished on x86 gadgets and is barely enabled when Wi-Fi* is related.
  2. Lacking Library Detection: If x86 libraries are lacking, the SDK will mechanically re-extract ARM libraries. An ISV can copy the ARM library to the x86 folder to keep away from this challenge, but it surely should be sure that there isn’t a cross-reference between ARM and x86 libraries.
  3. Java Instrument for Packaging: A Java Package deal Instrument is supplied to transform regular APKs to LZMA-compressed APKs. This instrument helps Home windows*, Linux*, and Mac* programs. You should utilize it as:  ComPressApk.jar -a C:/my/take a look at.APK -k c:/key *** ### alias, if “-k” is lacking (that’s to say, you possibly can simply name ComPressApk.jar -a C:/my/take a look at.APK), the Eclipse* default take a look at key can be used to signal this APK. This instrument may be built-in into an ants construct script to help mechanically compiling and publishing.
  4. Filter: The ConfigureFilter perform permits you to solely extract the mandatory libraries. For instance, coming intoConfigureFilter(“libffmpeg”, “libffmpeg_armv7_neon.so”) means solely extract libffmpeg_armv7_neon.soamongst the entire libraries that begin with “libffmpeg”. That is helpful to lower the post-install measurement.

For extra such Android sources and instruments from Intel, please go to the Intel® Developer Zone

Leave a Reply

Login.

To Comment.

Login to follow creators & categories, to create posts, to comment on posts.

Log In

Forgot password?

Don't have an account? Register

Forgot password?

Enter your account data and we will send you a link to reset your password.

Your password reset link appears to be invalid or expired.

Log in

Privacy Policy

To use social login you have to agree with the storage and handling of your data by this website. %privacy_policy%

Add to Collection

No Collections

Here you'll find all collections you've created before.

Share on facebook
Share on google
Share on twitter
Share on linkedin
Share on whatsapp
Share on email