Reduce size of PDFTron for Android

Technical Support Apryse SDK
1

Q:

Is it possible to reduce the size of the PDFTron lib as when we build it takes a lot of resources and compile time….code is used

in the emulator and on a Lenovo ThinkPad.

A:

For development I suggest you to use only one of the libs provided, eg, only arm-v7 (or arm-v6, depending on the architecture of the device). This way it will be faster to upload the code to emulator or device for testing.

For deployment, depending on your requirements, if you want to support only one architecture then you can remove the ones you don’t want (eg, libs/armeabi or libs/armeabi-v7a) in the sample project. The armeabi folder contains the .so file for devices with only arm v6 support, while armeabi-v7a folder contains the .so file for devices with arm v7 support (v6 library will run on v7 devices but may not take advantage of all optimizations). If you don’t need to support of v6 devices you can remove v7 library. If you just need to support v7 devices, you can keep v7 and remove v6 lib. If you keep both, Android will install the proper one based on the arm structure of the device.

In case you are deploying you app via Google Play, you can use “Multiple APK Support” (http://developer.android.com/guide/google/play/publishing/multiple-apks.html). The basic idea is to generate separate APKs using either the .so file for arm v6 (libs/armeabi) or the .so file for arm v7 (libs/armeabi-v7a) to have smaller APKs and then publish them as being the same app in Google Play. With this schema, Google Play will automatically identify which APK to install based on the device’s architecture.

If it still sounds too large, we can also trim down the size of .so files (as part of a custom project) to ~4-5mb for a bare viewer. A big chunk of this size (~2.5 MB) goes on base 14 fonts and CMaps which are required for accurate rendering of some PDFs. Most of the files do not require these resources so technically you could download them on demand (instead of as part of the initial app download). Of course this complicates your app logic, but is an option to consider.

2

You don’t need to rename the folders; if you do so, then PDFNet will not find the libs. Let’s say you want to include in your APK only the arm-v6 lib, then your folder structure should be like this:

\libs

\libs\PDFNet.jar

\libs\Tools.jar (if your using it)

\libs\armeabi

\libs\armeabi\libPDFNetC.so

If you want to include only the arm-v7, then you would have:

\libs

\libs\PDFNet.jar

\libs\Tools.jar (if your using it)

\libs\armeabi-v7a

\libs\armeabi-v7a\libPDFNetC-v7a.so

Note 1: The folder name “armeabi” is a convention used by Android, and due to a bug in a former version of Android we had to include the armeabi-v7a so PDFNet would load the right library.

armeabi\libPDFNetC.so → arm-v6 version

armeabi-v7a\libPDFNetC-v7a.so → arm-v7

3

We can provide even smaller custom build variants but keep in mind that just standard PDF resources take at least 3MB so there may not be much to gain with further reductions.

4

Update:

Starting with version 6.1.0 of the Android PDFNet SDK, the Tools library is now shipped as an Android Library, and its source code can be found in the samples folder. The package does not include the Tools.jar anymore, and you now have the flexibility to include the source directly into your project or create a separate library for your projects.