Tag Archives: apk

App Bundles for Google TV and Android TV

Posted by Josh Wentz, Product Management, Google TV

TLDR: Google TV and Android TV will be requiring Android App Bundles that are archivable starting in May 2023 to save storage for users.

Over the past few decades, TV has transformed from linear channel surfing to on-demand content with multi-app experiences. Today, over 10,000 apps are available on Android TV OS. While software has grown exponentially, TV hardware has remained limited in capacity compared to its phone counterparts. In 2022, smartphones often have a minimum storage size of 64GB, but smart TVs have an average of just 8GB. Less storage results in users having to uninstall apps, hindering their overall TV experience. To help with this problem and others, Android introduced App Bundles in Nov 2020.


What are Android App Bundles?

“Android App Bundles” (AABs) are the standard publishing format on Google Play (phones, tablets, TVs, etc) that have replaced “Android Package Kits” (APKs). App Bundles are smaller, faster, fresher, and better than its precursor. Key benefits include:

  1. Smaller Download/Storage Size - App Bundles create an average of 20% total size savings compared to its equivalent APK counterpart by optimizing for each device.
  2. Less Likely to Uninstall - Since App Bundles enables users with the option to archive (which reclaims ~60% of app storage), users can keep these and more apps on their TV despite limited storage. A quick archive/unarchive user interface is built-in to the TV. Developers can also maintain state for a frictionless later return.
  3. Applicable to All Android Surfaces - App Bundles are helpful for all Android surfaces using the Google Play store including TV, phone, tablet, watch, auto, & more.
  4. Streamlined Delivery & Security - For easier delivery, a single artifact with all of your app's code & resources allows Play store to dynamically serve an optimized app for each device configuration. For greater security, developers can also reset the upload key if it’s lost or compromised.

What is new for TV?

With TV storage confined and users having an increasing appetite for more apps, Google TV and Android TV will be requiring App Bundles starting in May 2023. While this provides about 6-months to transition, we estimate that in most cases it will take one engineer about 3-days to migrate an existing TV app from Android Package Kit (APK) to Android App Bundle (AAB). While developers can configure archiving for their mobile apps, TV apps are required to be archivable so that all users and developers can benefit on storage-constrained TVs.

For TV apps not transitioned in time, Google may hide such apps from the TV surface. If you’re working on a brand new TV app, be sure to use Android App Bundles from the start!


How can TV apps transition?

Visit our Developer Guide to learn more about how to migrate to an Android App Bundle (AAB).

All told, App Bundles bring a delightful experience to both you as developers and your users, especially in the living room. Thank you for your partnership in creating immersive content and entertainment experiences for the future of TV.

Getting Santa Tracker Into Shape


Posted by Sam Stern, Developer Programs Engineer

Santa Tracker is a holiday tradition at Google.  In addition to bringing seasonal joy to millions of users around the world, it's a yearly testing ground for the latest APIs and techniques in app development.  That's why the full source of the app is released on Github every year.
In 2016, the Santa team challenged itself to introduce new content to the app while also making it smaller and more efficient than ever before.  In this post, you can read about the road to a more slimmer, faster Santa Tracker.

APK Bloat

Santa Tracker has grown over the years to include the visual and audio assets for over a dozen games and interactive scenes.  In 2015, the Santa Tracker APK size was 66.1 MB.
The Android Studio APK analyzer is a great tool to investigate what made the 2015 app so large.

Screenshot from 2017-02-01 11:59:09.png
First, while the APK size is 66.1 MB, we see that the download size is 59.5MB! The majority of that size is in the resources folder, but assets and native libraries contribute a sizable piece.
The 2016 app contains everything that was in the 2015 app while adding four completely new games.  At first, we assumed that making the app smaller while adding all of that would be impossible, but (spoiler alert!) here are the final results for 2016:

Screenshot from 2017-02-01 12:06:23.png
The download size for the app is now nearly 10MB smaller despite the addition of four new games and a visual refresh. The rest of this section will explore how we got there.

Multiple APK Support on Google Play with APK Splits

The 2015 app added the "Snowdown" game by Google's Fun Propulsion Labs team.  This game is written in C++, so it's included in Santa Tracker as a native library.  The team gave us compiled libraries for armv5, armv7, and x86 architectures.  Each version was about 3.5MB, which adds up to the 10.5MB you see in the lib entry for the 2015 APK.
Since each device is only using one of these architectures, two thirds of the native libraries could be removed to save space - the tradeoff here is that we’ll publish multiple APKs.  The Android gradle build system has native support for building an APK for each architecture (ABI) with only a few lines of configuration in the app's build.gradle file:

ext.abiList = ['armeabi', 'armeabi-v7a', 'x86']
android {
   
   // ...
   splits {
       abi {
           // Enable ABI splits
           enable true
           // Include the three architectures that we support for snowdown
           reset()
           include(*abiList)
           // Also build a "universal" APK that will run on any device
           universalApk true
       }
   }
}
Once splits are enabled, each split needs to be given a unique version code so that they can co-exist in the Play Store:

// Generate unique versionCodes for each APK variant: ZXYYSSSSS
//   Z is the Major version number
//   X is the Minor version number
//   YY is the Patch version number
//   SSSS is information about the split (default to 0000)
// Any new variations get added to the front
import com.android.build.OutputFile;
android.applicationVariants.all { variant ->
   variant.outputs.each { output ->
       // Shift abi over by 8 digits
       def abiFilter = output.getFilter(OutputFile.ABI)
       int abiVersionCode = (abiList.indexOf(abiFilter) + 1)
       // Merge all version codes
       output.versionCodeOverride = variant.mergedFlavor.versionCode + abiVersionCode
   }
}
In the most recent version of Santa Tracker, we published versions for armv5, armv7, and x86 respectively.  With this change in place, 10.5MB of native libraries was reduced to about 4MB per variant without losing any functionality.

Optimize Images

The majority of the Santa Tracker APK is image resources. Each game has hundreds of images, and each image comes in multiple sizes for different screen densities. Almost all of these images are PNGs, so in past years we ran PNGCrush on all of the files and figured our job was done.  We learned in 2016 that there have been advancements in lossless PNG compression, and Google's zopfli tool is currently the state of the art.


By running zopflipng on all PNG assets we losslessly reduced the size of most images by 10% and some by as much as 30%. This resulted in almost a 5MB size reduction across the app without sacrificing any quality. For instance this image of Santa was losslessly reduced from 10KB to only 7KB.  Don't bother trying to spot the differences, there are none!


Before (10.2KB)
After (7.4KB)
santa-before.png
santa-before-zopfli.png

Unused Resources

When working on Santa Tracker engineers are constantly refactoring the app, adding and removing pieces of logic and UI from previous years. While code review and linting help to find unused code, unused resources are much more likely to slip by unnoticed.  Plus there is no ProGuard for resources, so we can't be saved by our toolchain and unused images and other resources often sneak into the app.
Android Studio can help to find resources that are not being used and are therefore bloating the APK.  By clicking Analyze > Run Inspection by Name > Unused Resources Android Studio will identify resources that are not used by any known codepaths.  It's important to first eliminate all unused code, as resources that are "used" by dead code will not be detected as unused.
After a few cycles of analysis with Android Studio's helpful tools, we were able to find dozens of unused files and eliminate a few more MB of resources from the app.

Memory Usage

Santa Tracker is popular all around the world and has users on thousands of unique Android devices.  Many of these devices are a few years old and have 512MB RAM or less, so we have historically run into OutOfMemoryErrors in our games.
While the optimizations above made our PNGs smaller on disk, when loaded into a Bitmap their memory footprint is unchanged.  Since each game in Santa Tracker loads dozens of images, we quickly get into dangerous memory territory.
In 2015 six of our top ten crashes were memory related. Due to the optimizations below (and others) we moved memory crashes out of the top ten altogether.

Image Loading Backoff

When initializing a game in Santa Tracker we often load all of the Bitmaps needed for the first scene into memory so that the game can run smoothly.  The naive approach looks like this:
private LruCache<Integer, Drawable> mMemoryCache;
private BitmapFactory.Options mOptions;
public void init() {
 // Initialize the cache
 mMemoryCache = new LruCache<Integer, Drawable>(240);
 // Start with no Bitmap sampling
 mOptions = new BitmapFactory.Options();
 mOptions.inSampleSize = 1;
}
public void loadBitmap(@DrawableRes int id) {
   // Load bitmap
   Bitmap bmp = BitmapFactory.decodeResource(getResources(), id, mOptions);
   BitmapDrawable bitmapDrawable = new BitmapDrawable(getResources(), bmp);
   
   // Add to cache
   mMemoryCache.put(id, bitmapDrawable);
}
However the decodeResource function will throw an OutOfMemoryError if we don't have enough RAM to load the Bitmap into memory.  To combat this, we catch these errors and then try to reload all of the images with a higher sampling ratio (scaling by a factor of 2 each time):

private static final int MAX_DOWNSAMPLING_ATTEMPTS = 3;
private int mDownsamplingAttempts = 0;
private Bitmap tryLoadBitmap(@DrawableRes int id) throws Exception {
   try {
       return BitmapFactory.decodeResource(getResources(), id, mOptions);
   } catch (OutOfMemoryError oom) {
       if (mDownSamplingAttempts < MAX_DOWNSAMPLING_ATTEMPTS) {
           // Increase our sampling by a factor of 2
           mOptions.inSampleSize *= 2;
           mDownSamplingAttempts++;
       }
   }
   throw new Exception("Failed to load resource ID: " + resourceId);
}
With this technique low-memory devices will now see more pixelated graphics, but by making this tradeoff we almost completely eliminated memory errors from Bitmap loading.

Transparent Pixels

As mentioned above, an image's size on disk is not a good indicator of how much memory it will use. One glaring example is images with large transparent regions.  PNG can compress these regions to near-zero disk size but each transparent pixel still demands the same RAM.
For example in the "Dasher Dancer" game, animations were represented by a series of 1280x720 PNG frames.  Many of these frames were dominated by transparency as the animated object left the screen.  We wrote a script to trim all of the transparent space away and record an "offset" for displaying each frame so that it would still appear to be 1280x720 overall. In one test this reduced runtime RAM usage of the game by 60MB! And now that we were not wasting memory on transparent pixels, we needed less downscaling and could use higher-resolution images on low-memory devices.

Additional Explorations

In addition to the major optimizations described above, we explored a few other avenues for making the app smaller and faster with varying degrees of success.

Splash Screens

The 2015 app moved to a Material Design aesthetic where games were launched from a central list of 'cards'. We noticed that half of the games would cause the card 'ripple' effect to be janky on launch, but we couldn't find the root cause and were unable to fix the issue.
When work on the 2016 version of the app we were determined to fix the game jank launch. After hours of investigation, we realized it was only the games fixed to the landscape orientation that caused jank when launched.  The dropped frames were due to the forced orientation change. To create a smooth user experience, we introduced splash screens in between the launcher Activity and game Activities.  The splash screen would detect the current device orientation and the orientation needed to play the game being loaded and rotate itself at runtime to match.  This immediately removed any noticeable jank from game launches and made the whole app feel smoother.

SVG

When we originally took on the task of reducing the size of our resources, using SVG images seemed like an obvious optimization.  Vector images are dramatically smaller and only need to be included once to support multiple densities.  Due to the 'flat' aesthetic in Santa Tracker, we were even able to convert many of our PNGs to tiny SVGs without much quality loss. However loading these SVGs was completely impractical on slower devices, where they would be tens or hundreds of times slower than a PNG depending on the path complexity.
In the end we decided to follow the recommendation limiting vector image sizes at 200x200 dp and only used SVG for small icons in the app rather than large graphics or game assets.

Conclusions

When we started building Santa Tracker 2016 we were faced with a daunting problem: how can we make the app smaller and faster while adding exciting new content? The optimizations above were discovered by constantly challenging each other to do more with less and considering resource constraints with every change we made. In the end we were able to incrementally make the Santa Tracker app as healthy as it has ever been ... our next job will be helping Mr. Claus work off all that extra cookie weight.

Understanding APK packaging in Android Studio 2.2

Posted by Wojtek Kaliciński, Android Developer Advocate

Android Studio 2.2 launched recently with many new and improved features. Some of the changes are easy to miss because they happened under the hood in the Android Gradle plugin, such as the newly rewritten integrated APK packaging and signing step.

APK Signature Scheme v2

With the introduction of the new APK Signature Scheme v2 in Android 7.0 Nougat, we decided to rewrite how assembling APKs works in the Android Gradle plugin. You can read all about the low-level technical details of v2 signatures in the documentation, but here's a quick tl;dr summary of the info you need as an Android app developer:

  • The cryptographic signature of the APK that is used to verify its integrity is now located immediately before the ZIP Central Directory.
  • The signature is computed and verified over the binary contents of the whole APK file, as opposed to decompressed file contents of each file in the archive in v1.
  • An APK can be signed by both v1 and v2 signatures at the same time, so it remains backwards compatible with previous Android releases.

Why introduce this change to how Android verifies APKs? Firstly, for enhanced security and extensibility of this new signing format, and secondly for performance - the new signatures take significantly less time to verify on the device (no need for costly decompression), resulting in faster app installation times.

The consequence of this new signing scheme, however, is that there are new constraints on the APK creation process. Since only uncompressed file contents were verified in v1, that allowed for quite a lot of modifications to be made after APK signing - files could be moved around or even recompressed. In fact, the zipalign tool which was part of the build process did exactly that - it was used to align ZIP entries on correct byte boundaries for improved runtime performance.

Because v2 signatures verify all bytes in the archive and not individual ZIP entries, running zipalign is no longer possible after signing. That's why compression, aligning and signing now happens in a single, integrated step of the build process.

If you have any custom tasks in your build process that involve tampering with or post-processing the APK file in any way, please make sure you disable them or you risk invalidating the v2 signature and thus making your APKs incompatible with Android 7.0 and above.

Should you choose to do signing and aligning manually (such as from the command line), we offer a new tool in the Android SDK, called apksigner, that provides both v1 and v2 APK signing and verification. Note that you need to run zipalign before running apksigner if you are using v2 signatures. Also remember the jarsigner tool from the JDK is not compatible with Android v2 signatures, so you can't use it to re-sign your APKs if you want to retain the v2 signature.

In case you want to disable adding v1 or v2 signatures when building with the Android Gradle plugin, you can add these lines to your signingConfig section in build.gradle: 

v1SigningEnabled false
v2SigningEnabled false

Note: both signing schemes are enabled by default in Android Gradle plugin 2.2.

Release builds for smaller APKs

We took this opportunity when rewriting the packager to make some optimizations to the size of release APKs, resulting in faster downloads, smaller delta updates on the Play Store, and less wasted space on the device. Here are some of the changes we made:

  • Files in the archive are now sorted to minimize differences between APK builds.
  • All file timestamps and metadata are zeroed out.
  • Level 6 and level 9 compression is checked for all files in parallel and the optimal one is used, i.e. if L9 provides little benefit in terms of size, then L6 may be chosen for better performance
  • Native libraries are stored uncompressed and page aligned in the APK. This brings support for the android:extractNativeLibs="false" option from Android 6.0 Marshmallow and lets applications use less space on the device as well as generate smaller updates on the Play Store
  • Zopfli compression is not used to better support Play Store update algorithms. It is not recommended to recompress your APKs with Zopfli. Pre-optimizing individual resources such as PNG files in your projects is still fine and recommended.

These changes help make your releases as small as possible so that users can download and update your app even on a slower connection or on less capable devices. But what about debug builds?

Debug builds for installation speed

When developing apps you want to keep the iteration cycle fast - change code, build, and deploy on a connected device or emulator. Since Android Studio 2.0 we've been working to make all the steps as fast as possible. With Instant Run we're now able to update only the changed code and resources during runtime, while the new Emulator brings multi-processor support and faster ADB speeds for quicker APK transfer and installation. Build improvements can cut that time even further and in Android Studio 2.2 we're introducing incremental packaging and parallel compression for debug builds. Together with other features like selectively packaging resources for the target device density and ABI this will make your development even faster.

A word of caution: the APK files created for Instant Run or by invoking a debug build are not meant for distribution on the Play Store! They contain additional instrumentation code for Instant Run and are missing resources for device configurations other than the one that was connected when you started the build. Make sure you only distribute release versions of the APK which you can create using the Android Studio Generate Signed APK command or the assembleRelease Gradle task.

Support for 100MB APKs on Google Play

Posted by Kobi Glick, Google Play team

Smartphones are powerful devices that can support diverse tasks from graphically intensive games to helping people get work done from anywhere. We understand that developers are challenged with delivering a delightful user experience that maximizes the hardware of the device, while also ensuring that their users can download, install, and open the app as quickly as possible. It’s a tough balance to strike, especially when you’re targeting diverse global audiences.

To support the growing number of developers who are building richer apps and games on Google Play, we are increasing the APK file size limit to 100MB from 50MB. This means developers can publish APKs up to 100MB in size, and users will see a warning only when the app exceeds the 100MB quota and makes use of Expansion Files. The default update setting for users will continue to be to auto-updating apps over Wi-Fi only, enabling users to access higher quality apps and games while conserving their data usage.

Even though you can make your app bigger, it doesn’t always mean you should. Remember to keep in mind the following factors:

  • Mobile data connectivity: Users around the world have varying mobile data connectivity speeds. Particularly in developing countries, many people are coming online with connections slower than those of users in countries like the U.S. and Japan. Users on a slow connection are less likely to install an app or game that is going to take a long time to download.
  • Mobile data caps: Many mobile networks around the world give users a limited number of MB that they can download each month without incurring additional charges. Users are often wary of downloading large files for fear of exceeding their limits.
  • App performance: Mobile devices have limited RAM and storage space. The larger your app or game, the slower it may run, particularly on older devices.
  • Install time: People want to start using your app or game as quickly as possible after tapping the install button. Longer wait times increase the risk they’ll give up.

We hope that, in certain circumstances, this file size increase is useful and enables you to build higher quality apps and games that users love.

Efficient Game Textures with Hardware Compression

Posted by Shanee Nishry, Developer Advocate

As you may know, high resolution textures contribute to better graphics and a more impressive game experience. Adaptive Scalable Texture Compression (ASTC) helps solve many of the challenges involved including reducing memory footprint and loading time and even increase performance and battery life.

If you have a lot of textures, you are probably already compressing them. Unfortunately, not all compression algorithms are made equal. PNG, JPG and other common formats are not GPU friendly. Some of the highest-quality algorithms today are proprietary and limited to certain GPUs. Until recently, the only broadly supported GPU accelerated formats were relatively primitive and produced poor results.

With the introduction of ASTC, a new compression technique invented by ARM and standardized by the Khronos group, we expect to see dramatic changes for the better. ASTC promises to be both high quality and broadly supported by future Android devices. But until devices with ASTC support become widely available, it’s important to understand the variety of legacy formats that exist today.

We will examine preferable compression formats which are supported on the GPU to help you reduce .apk size and loading times of your game.

Texture Compression

Popular compressed formats include PNG and JPG, which can’t be decoded directly by the GPU. As a consequence, they need to be decompressed before copying them to the GPU memory. Decompressing the textures takes time and leads to increased loading times.

A better option is to use hardware accelerated formats. These formats are lossy but have the advantage of being designed for the GPU.

This means they do not need to be decompressed before being copied and result in decreased loading times for the player and may even lead to increased performance due to hardware optimizations.

Hardware Accelerated Formats

Hardware accelerated formats have many benefits. As mentioned before, they help improve loading times and the runtime memory footprint.

Additionally, these formats help improve performance, battery life and reduce heating of the device, requiring less bandwidth while also consuming less energy.

There are two categories of hardware accelerated formats, standard and proprietary. This table shows the standard formats:

ETC1 Supported on all Android devices with OpenGL ES 2.0 and above. Does not support alpha channel.
ETC2 Requires OpenGL ES 3.0 and above.
ASTC Higher quality than ETC1 and ETC2. Supported with the Android Extension Pack.

As you can see, with higher OpenGL support you gain access to better formats. There are proprietary formats to replace ETC1, delivering higher quality and alpha channel support. These are shown in the following table:

ATC Available with Adreno GPU.
PVRTC Available with a PowerVR GPU.
DXT1 S3 DXT1 texture compression. Supported on devices running Nvidia Tegra platform.
S3TC S3 texture compression, nonspecific to DXT variant. Supported on devices running Nvidia Tegra platform.

That’s a lot of formats, revealing a different problem. How do you choose which format to use?

To best support all devices you need to create multiple apks using different texture formats. The Google Play developer console allows you to add multiple apks and will deliver the right one to the user based on their device. For more information check this page.

When a device only supports OpenGL ES 2.0 it is recommended to use a proprietary format to get the best results possible, this means making an apk for each hardware.

On devices with access to OpenGL ES 3.0 you can use ETC2. The GL_COMPRESSED_RGBA8_ETC2_EAC format is an improved version of ETC1 with added alpha support.

The best case is when the device supports the Android Extension Pack. Then you should use the ASTC format which has better quality and is more efficient than the other formats.

Adaptive Scalable Texture Compression (ASTC)

The Android Extension Pack has ASTC as a standard format, removing the need to have different formats for different devices.

In addition to being supported on modern hardware, ASTC also offers improved quality over other GPU formats by having full alpha support and better quality preservation.

ASTC is a block based texture compression algorithm developed by ARM. It offers multiple block footprints and bitrate options to lower the size of the final texture. The higher the block footprint, the smaller the final file but possibly more quality loss.

Note that some images compress better than others. Images with similar neighboring pixels tend to have better quality compared to images with vastly different neighboring pixels.

Let’s examine a texture to better understand ASTC:

This bitmap is 1.1MB uncompressed and 299KB when compressed as PNG.

Compressing the Android jellybean jar texture into ASTC through the Mali GPU Texture Compression Tool yields the following results.

Block Footprint 4x4 6x6 8x8
Memory 262KB 119KB 70KB
Image Output
Difference Map
5x Enhanced Difference Map

As you can see, the highest quality (4x4) bitrate for ASTC already gains over PNG in memory size. Unlike PNG, this gain stays even after copying the image to the GPU.

The tradeoff comes in the detail, so it is important to carefully examine textures when compressing them to see how much compression is acceptable.

Conclusion

Using hardware accelerated textures in your games will help you reduce the size of your .apk, runtime memory use as well as loading times.

Improve performance on a wider range of devices by uploading multiple apks with different GPU texture formats and declaring the texture type in the AndroidManifest.xml.

If you are aiming for high end devices, make sure to use ASTC which is included in the Android Extension Pack.