APK Size Breakdown
Size estimates of the Calling SDK Components
Total Size for each package + Platform Range.
Supported Platforms are x86/x86_64/armeabi-v7a/arm64-v8a
| Module | UI Library Size | Total Size | Platform Range |
|---|---|---|---|
| Calling UI Library | 1.5mb | 56.2mb | 16.4mb -> 19.3mb |
| Chat UI Library | 1.1mb | 14.6mb | 6.3mb -> 7.5mb |
| Calling UI + Chat UI | 2.6mb | 58.5mb | 17.6mb -> 20.5mb |
Understanding the Size
- UI Calling/UI Chat provides Java and Android system resources. In both cases this is less than a 2mb impact on the client application.
- Calling/Chat SDK provide native components. These components represent a majority of the size.
- Using AAB is encouraged, as it'll keep the per-platform size to < 20mb for Calling, and < 9mb for Chat.
How to Reduce Application Size
There are 2 approaches to reducing application size. The first is the Split APK approach, which essentially means you need to build an APK targeted for one specific CPU architecture and/or screen density combination in order to achieve size reduction.
There is another approach, which is to build for the new Android App Bundle (AAB) format. With the AAB approach, you are building all the components at build time and then afterwards, bundling (ie. Combining) a specific configuration (ie. Screen density, and CPU architecture, etc) for the specific device at load time in order to achieve your size reduction. The diagram below (taken from the Android developer website) visually explains the AAB approach nicely.
The AAB approach lays the foundation to support many other features (such as Android’s equivalent to iOS App Clips called Instant Apps) but for now, we will focus only on the size optimization aspect of AAB files.
So, when you build an AAB file, you are actually building all the same components that an APK file uses. The main difference between the split APK approach and the AAB approach is that with the split APK approach, you will be building multiple APK’s, so the developer will incur some overhead to manage the different APK’s targeted to different CPU architectures. However, with the AAB approach, that will all be managed by Google Play store.
The AAB approach is better than the Split APK approach because the burden of version management is eliminated.
There are 3 steps to reducing the app size of the Calling Composite Demo App.
The first step was to adopt the AAB approach as the recommended format to all customers. Most developers will be more accustomed to building an APK and for debug builds, that is still the preferred approach. However, for Production releases and certainly for Google Play store releases, building AAB is the preferred artifact. For pre-existing apps already on the Play store, this is not mandatory, so there will need to be a bit of education and training to switch to publishing as AAB.
| Format/Approach | Original APK | Split APK | AAB |
|---|---|---|---|
| App Size (Samsung GS10) API30 |
 |
 |
 |
Starting from the original size of 99.72 Mb APK size, we can shrink the app size down to around 60 Mb by using the AAB format. Further reductions in code size will involve using the code shrinking and obfuscation tool R8, and also investigations in the Calling SDK side.
If the customer is using Android Studio, then building an AAB is straightforward:
To build and install from AAB in a CI environment, or from command line, use the script named “installAab.sh” located in the public preview GitHub repository.
To achieve additional size reductions, the second step that is recommended is that the developer customer enable Android R8. For debug or internal builds, R8 in general does not need to be enabled outside of any troubleshooting purposes. For any release builds, R8 should be enabled to achieve size reductions. Because R8 is applied after all source code has been compiled into Java bytecode, the R8 code shrinking process is applicable across all artifacts (Fluent UI, ACS UI Library, java parts of ACSCallingSDK) and 3rd party dependencies. It is not necessary to apply R8 code shrinking to each library module separately. This means that the R8 shrinking can be enabled in the build.gradle for the application module. When enabling R8, it is also recommended that developer customers also use the R8 configuration file named “acs-mobile-ui.pro” provided in the public preview repository. This configuration file contains the R8 settings needed to run with R8 enabled. This configuration file has been tested and verified to be working with the public Preview project; however, it has not been tested in a Production environment yet. This configuration file has also been tested with Proguard, a popular 3rd party code shrinking/obfuscation tool for Android. Proguard and R8 are different tools, but inter-operable, so this same R8 configuration file should also work when enabling Proguard instead of R8. The difference between Proguard and R8 is illustrated by the following diagram:
Proguard process:
R8 process:
Enabling Proguard/R8 is straightforward, just set minify and shrinkResources to true in the buildType block for app module’s build.gradle and be sure to include the proguard/R8 config file “acs-mobile-ui.pro:
buildTypes {
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'acs-mobile-ui.pro'
signingConfig signingConfigs.release
}
}
A full example demonstrating R8 support can be found in the Public preview GitHub repo.
Application Size Reduction Results
The size reductions that can be achieved using Proguard/R8 is illustrated in the following table:
| Format/Approach | Original APK | APK with Proguard |
AAB | AAB with Proguard |
|---|---|---|---|---|
| App Size (Google P4a) API31 |
 |
 |
 |
 |
In the case of the Calling Composite Demo app, the size reductions using Proguard is slightly better than using Android R8. However, the difference is small, and therefore, either approach (Proguard / R8) is recommended.
The size reduction can be visualized from another perspective:
Based on the above 2 diagrams, we can see that the Calling Composite Library beta.3 version can be reduced in size from 1.1 Mb to 868.2 Kb, or by around 21% using the approach of applying Proguard/R8 to the AAB approach.