Unity android split application binary

Поддержка разделения приложения (.OBB)

In the Android Publishing Settings you’ll find the option to split the application binary (.apk) into expansion files (.apk + .obb). To find it, go to Edit -> Project Settings -> Player. Then select the Android button, and expand the Publishing Settings section. The setting is a checkbox marked “Split Application Binary”.

The Split Application Binary publish option for Android

Этот механизм необходим только при публикации в магазин Google Play, если приложение больше 50 МБ. См. http://developer.android.com/guide/google/play/expansion-files.html для дополнительной информации о файлах расширения APK (APK Expansion Files).

Когда включена опция Split Application Binary (разбивать приложение), исполняемый файл проигрывателя и данные будут отделены друг от друга, в результате чего сгенерируется .apk (основной исполняемый файл), в котором будет содержаться только исполняемый (Java и нативный) код (около 10 МБ), все без исключения скрипты / плагины и данные для первой сцены. Всё остальное (все дополнительные сцены, ресурсы, поточные ассеты …) будет сериализовано отдельно в файл расширения APK (.obb).

• При запуске .apk, построенного с включенной опцией Split Application Binary, приложение будет проверять, есть ли у него доступ к .obb файлу из текущего расположения на sd карте. Расположение объяснено в документации по расширению APK (Apk Expansion) от Google.
• Если не удаётся найти файл расширения (.obb), тогда будет возможен доступ только к первому уровню (т.к. остальные данные находятся в .obb).
• Первый уровень в приложении требуется, чтобы получить доступ к .obb файлу с sd карты, до того как приложение сможет обрабатывать и загружать последующие сцены/данные.
• После того как найдётся .obb, Application.dataPath переключится с текущего пути до .apk на новый путь до .obb. В таком случае нет необходимости в скачивании .obb.
• Содержимое .obb никогда не используется вручную. Всегда относитесь к связке .apk+.obb как к уникальному бандлу, так же как вы относитесь к одному большому .apk.

Опция Split Application Binary – не единственный способ разделения .apk на .apk/.obb (другие способы это сделать включают в себя сторонние плагины, ассет бандлы и т.д.), но это единственный официально поддерживаемый автоматический механизм разделения.

Источник

Support for Split Application Binary (.OBB)

In the Android Publishing Settings you’ll find the option to split the application binary (.apk) into expansion files (.apk + .obb). To find it, go to Edit -> Project Settings -> Player. Then select the Android button, and expand the Publishing Settings section. The setting is a checkbox marked “Split Application Binary”.

The Split Application Binary publish option for Android

This mechanism is only necessary when publishing to the Google Play Store, if the application is larger than 50 MB. See http://developer.android.com/guide/google/play/expansion-files.html for further information on APK Expansion Files.

When the Split Application Binary option is enabled the player executable and data will be split up, with a generated .apk (main application binary) consisting only of the executable (Java, Native) code (around 10MB), any and all script / plugin code, and the data for the first scene. Everything else (all additional scenes, resources, streaming assets …) will be serialized separately to a APK Expansion File (.obb).

• When starting an .apk built with Split Application Binary enabled the application will check to see if it can access the .obb file from it’s position on the sdcard (location explained in the Apk Expansion docs from Google).
• If the expansion file (.obb) cannot be found, only the first level can accessed (since the rest of the data is in the .obb).
• The first level is then required to make the .obb file available on sdcard, before the application can proceed to load subsequent scenes/data.
• If the .obb is found the Application.dataPath will switch from .apk path, to instead point to .obb. Downloading the .obb is then not necessary.
• The contents of the .obb are never used manually. Always treat the .apk+.obb as a unique bundle, the same way you would treat a single big .apk.

The Split Application Binary option is not the only way to split an .apk into .apk/.obb (other options include 3rd party plugins/asset bundles/etc), but it’s the only automatic splitting mechanism officially supported.

Источник

Support for Split Application Binary (.OBB)

In the Android Publishing Settings you’ll find the option to split the application binary (.apk) into expansion files (.apk + .obb). To find it, go to Edit -> Project Settings -> Player. Then select the Android button, and expand the Publishing Settings section. The setting is a checkbox marked “Split Application Binary”.

The Split Application Binary publish option for Android

This mechanism is only necessary when publishing to the Google Play Store, if the application is larger than 100 MB. See http://developer.android.com/guide/google/play/expansion-files.html for further information on APK Expansion Files.

When the Split Application Binary option is enabled the player executable and data will be split up, with a generated .apk (main application binary) consisting only of the executable (Java, Native) code (around 10MB), any and all script / plugin code, and the data for the first scene. Everything else (all additional scenes, resources, streaming assets …) will be serialized separately to a APK Expansion File (.obb).

• When starting an .apk built with Split Application Binary enabled the application will check to see if it can access the .obb file from it’s position on the sdcard (location explained in the Apk Expansion docs from Google).
• If the expansion file (.obb) cannot be found, only the first level can accessed (since the rest of the data is in the .obb).
• The first level is then required to make the .obb file available on sdcard, before the application can proceed to load subsequent scenes/data.
• If the .obb is found the Application.dataPath will switch from .apk path, to instead point to .obb. Downloading the .obb is then not necessary.
• The contents of the .obb are never used manually. Always treat the .apk+.obb as a unique bundle, the same way you would treat a single big .apk.

The Split Application Binary option is not the only way to split an .apk into .apk/.obb (other options include 3rd party plugins/asset bundles/etc), but it’s the only automatic splitting mechanism officially supported.

Источник

Support for Split Application Binary (.OBB)

Success!

Thank you for helping us improve the quality of Unity Documentation. Although we cannot accept all submissions, we do read each suggested change from our users and will make updates where applicable.

Sumbission failed

For some reason your suggested change could not be submitted. Please try again in a few minutes. And thank you for taking the time to help us improve the quality of Unity Documentation.

Under Player Settings | Publishing Settings you’ll find the option to split the application binary (.apk) into expansion files (.apk + .obb).

This mechanism is only necessary when publishing to the Google Play Store, if the application is larger than 50 MB. See http://developer.android.com/guide/google/play/expansion-files.html for further information on APK Expansion Files.

When the Split Application Binary option is enabled the player executable and data will be split up, with a generated .apk (main application binary) consisting only of the executable (Java, Native) code (around 10MB), any and all script / plugin code, and the data for the first scene. Everything else (all additional scenes, resources, streaming assets …) will be serialized separately to a APK Expansion File (.obb).

• When starting an .apk built with Split Application Binary enabled the application will check to see if it can access the .obb file from it’s position on the sdcard (location explained in the Apk Expansion docs from Google).
• If the expansion file (.obb) cannot be found, only the first level can accessed (since the rest of the data is in the .obb).
• The first level is then required to make the .obb file available on sdcard, before the application can proceed to load subsequent scenes/data.
• If the .obb is found the Application.dataPath will switch from .apk path, to instead point to .obb. Downloading the .obb is then not necessary.
• The contents of the .obb are never used manually. Always treat the .apk+.obb as a unique bundle, the same way you would treat a single big .apk.

The Split Application Binary option is not the only way to split an .apk into .apk/.obb (other options include 3rd party plugins/asset bundles/etc), but it’s the only automatic splitting mechanism officially supported.

Источник

Play Asset Delivery

Play Asset Delivery (PAD) is a Google Play Store feature you can use to deliver applications that are larger than 150MB. Instead of using APK expansion files (OBB) to store additional assets (such as textures, sounds, and meshes), PAD uses asset packs. Google hosts and serves asset packs on Google Play, which means you don’t need to create a content delivery network to send application resources to users. For more information about PAD, see Android’s Play Asset Delivery.

Important: PAD is only available for the Google Play Store. If you have a large application and want to support other digital distribution services, use APK expansion files (OBB).

Using Play Asset Delivery

To use Play Asset Delivery, you need to set up your project to build Android App Bundles and split the application binary.

To configure Unity to build Android App Bundles:

1. Open Build Settings (menu: File >Build Settings).
2. In Platform, select Android.
3. If Export Project is enabled, enable Export for App Bundle. Otherwise, enable Build App Bundle (Google Play).

To configure Unity to split the application binary:

1. Open Player Settings (menu: Edit >Project Settings then select Player).
2. Select the Android settings tab and open the Publishing Settings section.
3. Enable Split Application Binary.

Now when you build your application, Unity generates an Android App Bundle that includes your application split into a base module and asset packs.

• Base module: Contains the executables (Java and native), plug-ins A set of code created outside of Unity that creates functionality in Unity. There are two kinds of plug-ins you can use in Unity: Managed plug-ins (managed .NET assemblies created with tools like Visual Studio) and Native plug-ins (platform-specific native code libraries). More info
  See in Glossary , scripts A piece of code that allows you to create your own Components, trigger game events, modify Component properties over time and respond to user input in any way you like. More info
  See in Glossary , and assets in the first scene A Scene contains the environments and menus of your game. Think of each unique Scene file as a unique level. In each Scene, you place your environments, obstacles, and decorations, essentially designing and building your game in pieces. More info
  See in Glossary . The first scene is the scene that has a build index of 0.
• Asset packs: Contains everything else, including the remaining scenes, resources, and streaming assets. For more information about the asset packs that Unity generates at build time, see Generated asset packs.

Alongside the asset packs that Unity generates automatically, you can also create your own custom asset packs. This is useful when you need to control what an asset pack contains. Unity adds your custom asset packs to the final Android App Bundle. For more information about custom asset packs and how to set them up, see Custom asset packs.

Generated asset packs

Asset packs have download size limits. To account for this, Unity changes how it generates asset packs depending on the size of your additional assets:

• If the additional assets take less than 1GB of storage, Unity packs everything into a single asset pack with the install-time delivery mode. If you do not create any custom asset packs, this means that the device downloads the asset pack as part of the application installation and, when the user first launches the application, all assets are available.
• If the additional assets take more than 1GB of storage, Unity packs streaming assets into one asset pack and packs all other additional assets into another asset pack. Unity assigns the install-time delivery mode to the larger asset pack and assigns the fast-follow delivery mode to the smaller one.

Note: If either of these asset packs is larger than the upload limit the Google Play Store allows, Unity displays a warning but doesn’t fail the build. Also, Unity checks the sizes of asset packs individually and doesn’t perform size verification for custom asset packs. This means that, if a combination of custom asset packs and asset packs that Unity generates is too large for the Google Play Store, Unity doesn’t display a warning or error.

For asset packs that Unity automatically generates, Unity does not support changing the delivery mode. If you want to change the delivery mode of an asset pack, create custom asset packs with your assets.

Managing asset packs at runtime

Unity provides APIs to manage asset packs at runtime. They use Google’s PlayCore API, which means they have the same limitations as PlayCore, and can’t manage install-time asset packs. Using the PlayCore API also means your application requires the PlayCore plugin. If your project has asset packs, either custom asset packs or Unity-generated asset packs, Unity automatically adds the PlayCore dependency
See in Glossary to the application’s manifest.

The way you download asset packs and access their assets depends on the asset pack delivery mode. There are three asset pack delivery modes:

• install-time : Google Play automatically downloads install-time asset packs when the device installs the application. Google Play considers these asset packs to be part of the base application, and an end user can’t uninstall them without uninstalling the entire application. The PlayCore API doesn’t handle install-time asset packs, which means that you can’t check the status, request to download, or remove install-time asset packs. You also can’t directly access assets inside of these asset packs, except streaming assets in Unity-generated install-time asset packs. To access streaming assets, use Application-streamingAssetsPath to get the path to streaming assets location, then use UnityWebRequest to access assets in that path. If you create a custom asset pack, you can’t access assets inside it using standard file APIs. Instead, use Android’s AssetManager APIs.
• fast-follow : Google Play automatically starts to download fast-follow asset packs after it installs the application. However, it is possible that not all fast-follow asset packs are available on the first time the application launches. To check the status and download fast-follow asset packs, see below.
• on-demand : Google Play doesn’t automatically download on-demand asset packs. You have to manually start the download. For information on how to do this, see below.

For more information about delivery modes, see Delivery modes.

If your application uses fast-follow or on-demand asset packs, the device must download these asset packs before the application can access assets inside of them. To check the status of asset packs and download them if they are not on the device, you must first know the name of each asset pack. To get the names of Unity-generated asset packs, call AndroidAssetPacks.GetCoreUnityAssetPackNames. There is no runtime API to get the names of custom asset packs so you must keep track of them yourself. You set the name of custom asset packs at build time; it’s the name of the directory.

After you have the names of your asset packs, to check the status of each asset pack, call AndroidAssetPacks.GetAssetPackStateAsync, passing in the asset pack name. This returns the status of the asset pack you query, and you can use the result to determine whether you need to download the asset pack. If you want to quickly query the status of every Unity-generated asset pack, you can use AndroidAssetPacks.coreUnityAssetPacksDownloaded. This is useful because you must ensure that every Unity-generated asset pack is available before you load any scene other than the first one or try to access other resources that Unity handles.

For every asset pack you need to download, call AndroidAssetPacks.DownloadAssetPackAsync, passing in the asset pack name. While the asset pack downloads, monitor the download status, because downloads can pause or fail. There are two ways to do this:

• Periodically check the DownloadAssetPackAsyncOperation instance that AndroidAssetPacks.DownloadAssetPackAsync returns.
• Use the version of AndroidAssetPacks.DownloadAssetPackAsync that takes a callback as its second parameter. The callback you pass in must take an AndroidAssetPackInfo as a parameter which you can use to determine the state of the download.

Custom asset packs

If you want to control which non-code resources are in a particular asset pack, you can create a custom asset pack. Unlike Unity-generated asset packs, you can set the delivery mode for custom asset packs. If you create a custom asset pack, be aware that the Google Play Store has size and quantity limits for asset packs. For information on the limits, see Download size limits.

To create a custom asset pack, create a directory with a name that ends with .androidpack. You can place this directory anywhere in your project’s Assets directory, or any subdirectory. For example, to create a custom asset pack named MyAssets1:

1. Go to the directory you want to create the asset pack in. This could be directly in Assets or a subdirectory like Assets/CustomAssetPacks.
2. Create a new directory and call it MyAssets1.androidpack. To add any assets to the asset pack, place them inside this folder. Note: Unity doesn’t include empty asset packs in builds. Also, asset pack names must begin with a letter and consist of English alphanumeric characters or an underscore.
3. By default, the delivery mode is on-demand , which means that if you don’t change the delivery mode, you need to manually download the asset pack at runtime. For information on how to do this, see Managing asset packs at runtime.
4. To use a different delivery mode, create a file called build. gradle An Android build system that automates several build processes. This automation means that many common build errors are less likely to occur. More info
   See in Glossary inside the custom asset pack directory. Paste the following into the file:

This sets the delivery mode to fast-follow , which means Google Play automatically downloads the asset pack after it installs the application. For information on the format of this file, see Integrate asset delivery.

Источник