install-time asset packs are delivered when the app is installed. These packs are served as split APKs (part of the APK set). These packs are also known as "upfront" asset packs; you can use these packs immediately at app launch. These packs contribute to the app size listed on the Google Play Store. These packs can't be modified or deleted by the user.

fast-follow asset packs are downloaded automatically as soon as the app is installed; the user does not have to open the app for fast-follow downloads to begin. These downloads do not prevent the user from entering the app. These packs contribute to the app size listed on the Google Play Store.

on-demand asset packs are downloaded while the app is running.

Asset packs configured as fast-follow and on-demand are served as archive files by the Google Play Store (and not as split APKs). These packs are then expanded in the app’s internal storage. You can query the location of asset packs served this way using the Play Core API. The app can’t assume the existence of these files or their locations because these files may be deleted by the user or moved by the Play Core SDK across play sessions. Even though these files are writable by the app, you should treat them as read-only since asset pack patches depend on the integrity of these files.

When the app is updated, install-time asset packs are updated as part of the base app update (with no action needed from the developer).

App updates for fast-follow and on-demand asset packs follow these steps:

1. The patch for the app, including all assets, is downloaded to a secure location on the device.
2. The app binary is updated; this includes any install-time asset packs.
3. All previously-downloaded asset packs are invalidated.
4. The patch for the assets is copied and applied to assets stored in the app’s internal storage.

In most cases when the user opens the game, the entire update has already completed and the user can start playing the updated version immediately. In rare cases, when the app is opened, the app binary may have already been updated while the process of applying the patch for the assets has not yet completed and thus assets are not ready to be accessed. You need to accommodate this scenario by providing an appropriate "Update in progress" user interface element around these assets, or build in logic to deal with invalidated assets that are not ready to be accessed. Since the app binary update takes place only after all asset pack types have been downloaded, applying the patch is a local, offline action that should complete quickly.

Texture Compression is a form of lossy image compression that allows the GPU to render directly from the compressed texture with dedicated hardware, reducing the amount of texture memory and memory bandwidth required. Texture Compression Format Targeting lets you include textures compressed with multiple texture compression formats in your Android App Bundle and rely on Google Play to automatically deliver the assets with the best supported texture compression format for each device.

After a new version of an app is uploaded to Google Play, it is possible for the user to open the previous version of the app before it’s updated on the device. If required, in such cases, the app can choose to force an update or recommend an update by calling the In-App Updates API. This API allows you to trigger an update from within the app rather than the user triggering the update from the Google Play Store.

Asset packs are ideal for large games due to their increased size limits:

1. The download size limit for each fast-follow and on-demand asset pack is 512 MB.
2. The total download size limit for all install-time asset packs combined is 1 GB.
3. The total download size limit for all asset packs in an Android App Bundle is 2 GB.
4. You can use up to 50 asset packs in an Android App Bundle.

If you use Texture Compression Format Targeting, these download limits apply separately to each unique texture format.

Build Play Asset Delivery into your game or app using one of the following: