AAB support : does that mean we don't need to use PAD ?

Hello,

The release note on the blog says:

In 2021.2, Unity provides direct support for Android’s new expansion file format, Android App Bundle (AAB) for asset building. Using AAB, developers can meet the Google Asset Delivery requirements to publish any new apps to Google Play.

So far, when my application is above 150 Mo I have to use Google Play Asset Delivery feature in order to be able to upload my app. What this new feature will change exactly ?

Thanks

 

Hum ... so not sure what is the benefit here ? As of now our OBB files are created from AssetBundles and the very reason we use OBB files is because our app size is greater than the 150 Mo limits. With AAB file do we still have to pack assets using AssetBundle and then retrieve those using PAD ? If so, what is the benefit ?

Thanks.

 

Presumably this works even if you don't use AssetBundles.

It's to create a bridge for those that were relying on APK + OBB, or people that simply don't want to use asset bundles, and don't want to restructure their games to be able to publish on Google Play with aab.

I appreciate it.

 

@AcidArrow how will that prevent to use AssetBundle ? Genuinely question here, because when your app is over 150Mo you have one way or another create OBB file or assets packs which I think (but I might be wrong) are created from AssetBundles and then retrieved using the PAD API. I'm not quite sure for asset packs, so maybe I'm missing something here.

 

My understanding for the Unity feature is that the asset packs are auto generated (if final build is less than 1gb) and you don’t have to create or use asset bundles.

 

In that case it would be a really great news !

 

Please note that current ios ODR implementation dont support install time tags we need to go into xcode and setup them manually

When you will create api for PAD dont forget to realise install time tags (install, follow up, on demand)

And will be very nice if you add them to ODR implementation along with ability to check for downloaded packs

 

I have a question , is these PAD API already availbale in the new unity 2021.2b?

I've just compiled my app successfully with this unity version, but i receive the warning that my aab is bigger then 150mb, and Play Console dosesnt accept it .. once i remove everything on the StreamingAssets folder and recompile the app, i get an aab with 113Mb only.

Generating an app bundle, in 2021.2 has the same result as generating in 2021.1, at least for now. I was wondering how could i user Google PAD in Unity without AssetBundles.

What am i missing?

 

@JuliusM

In Google's implementation, it is possible to get the name, offset, and length of the file being stored as AssetLocation, but is there a way to get the equivalent information as Unity's API?
This is a very important aspect of implementing AssetBundle encryption in Streams.

 

Hi @JuliusM,
as @zeprocha already asked, are the Unity APIs for wrapping PAD already available?
And if not, was is the ETA for this?

According to Google APK support for Play Console will be ceased August 2021!
Would be nice to hear about Unitys roadmap concerning AAB/PAD.

 

New apps as in we already published it? We hav several apps that in Early Access ( Open Testing ), is that still consider new app and need to use .aab when we hit the publish button?

 

Thanks for the reply, I will check with Google console help desk directly

 

"In 2021.2, Unity provides direct support for Android’s new expansion file format, Android App Bundle (AAB) for asset building. Using AAB, developers can meet the Google Asset Delivery requirements to publish any new apps to Google Play."

Does that mean it's "integrated"?
Now I'm using 2021.1.15f1 and I installed a plugin/extension for the google asset delivery and it doesn't work at all.
We're trying to figure it out since nearly two weeks and the only thing it does when you want it to separate your base apk asset is that it creates a totally messed up aab-file that installs an app that doesn't start (black screen then crash -nice)
apk and obb work(ed) like a charm. This whole aab/google asset delivery destroyed our whole project planning.
Maybe if its integrated in unity itself it will work...

 

I just tried it out and it works fine in the beta (not like that google asset delivery plugin....)
Thanks for the information!

 

I have a several questions and feedback after reading through the documentation:

1. FEEDBACK: It seems to me that the current workflow of defining a custom asset pack is going to impact how the assets is organized in a cross-platform project, as one has to put the assets itself in specific directories which only benefits for one platform. Like, if I want to use the Unity's built-in asset pack generation, instead of putting assets in directories I defined for arbitrary reasons, I'll have to either adapt my asset organization habits just for Android, or I have to find workarounds, like duplicating assets just for the androidpack directory. It would make more sense to implement a definition file solution for asset packs, similar to asmdef files or sprite atlases that holds references to directories or asset. This will also allow us to change the properties of the asset packs right in the Inspector without having to add our own build.gradle files.
2. FEEDBACK: The documentation currently says that for custom asset packs marked with "install-time", we need to use the Android API (AssetManager) to fetch the contents, which requires writing interop code to call those Java APIs. I think Unity should instead offer a way to get those contents without us having to reinvent the wheels. Google's official plugin would returns the path to the install-time asset packs (in form of APK), offset and length to read the content with a stream.
3. QUESTION: Since the requirement is putting the "androidpack" directories in the Assets folder, does this have any implication on the asset types that will be include in a custom pack? Would it have the same limitation as AssetBundles that can only include assets importable by Unity? Or are the files in "androidpack" directories not imported by Unity like files in "StreamingAssets"? (The official plugin from Google allows making asset packs arbitrary files and directories with their Editor APIs, even outside of the Unity project directory).
4. QUESTION: Should the final solution Unity offers ended up not fitting my use case, do I still have the choice to use Google's official plugin, i.e. will Unity's integration conflict with Google's?

 

This is Google’s Unity plugin for Play Asset Delivery as a part of their Google Play plugins.
https://github.com/google/play-unity-plugins

The documentation is here:
https://developer.android.com/guide/playcore/asset-delivery/integrate-unity

 

Relatedly, how does this handle dependencies? Will the custom asset pack include only assets that are in the .androidpack directory or will it pull in dependencies? In the latter case, could I just put a ScriptableObject with the references I need to define which assets go into the custom asset pack? And if so, how will it handle overlap of dependencies between the packs?

 

Hi @JuliusM. Will next version of Entities package support this PAD feature for dots project out of the box by default?

 

Thank you for the reply. I understand now that there were more considerations than I could foresee.

If my understanding is correct, the current way is meant to be used with Asset Bundles, that people would put built asset bundles for Android in an androidpack directory. If that is the case, it makes sense.

For my project, I use CriWare audio middleware instead of the built-in audio system. Their audio file format is proprietary, and because the format relies on file streaming, the file cannot be imported into any kind of Unity asset and, because of this, cannot be bundled into an AssetBundle(unless I remembered it wrong).

My project is a rhythm game, so the majority of the assets are audio files. Previously, I put all CriWare audio files in the StreamingAssets folder, and copy them out of the OBB into cache on first install. As copying those files would waste extra disk space, I ended up moving my CriWare audio files outside of Assets directory (no .meta file), and build a patch OBB using jobb tool from Android SDK. OBB built using jobb is a FAT disk image and thus the content can be accessed using a file path and thus satisfying the middleware requirement.

Now with Play Asset Delivery, I would want to embed only a part of the audio audio files at install time and while players going through tutorials, download the audio files for the add-on contents. Because of this, and the fact that file streaming is required, I would need the offset and length of the audio files in the APK (as part of the install-time asset packs) so the middleware can read it, hence I wish a Unity API that can get those info. PlayCore has this information and their Unity plugin mirrors it:
https://developer.android.com/reference/com/google/android/play/core/assetpacks/AssetLocation
https://developer.android.com/reference/unity/class/Google/Play/AssetDelivery/AssetLocation

As for the workflow of defining a package, I do appreciate of having it code-less, comparing to the current integration of iOS On-Demand Resources in Unity, as those asset packs can only be defined using Editor scripts. I think at this point what I want to see is either Android PAD support adding APIs that allows defining asset packs programmatically, or iOS ODR support adding a code-less option that does not requiring putting files in specific directories, so we can have a more or less unified workflow. Because Google's PAD plugin has those APIs, I am more inclined to writing my own asset pack definition files for iOS and Android and build them in an editor script which allows me to prevent making copies of assets and also define different layouts that best utilize the different capabilities of either platforms (iOS ODR: more, smaller packs, Android PAD: larger, fewer packs).

 

@JuliusM I would like to verify something with u. If I understand correctly, it's still use same API to load if I use asset bundle and also if I use current version of addressable it's still work just like before as long as I dun use custom asset packs. The only thing that PAD feature changed is just the final android build will pack into new asset pack format as install-time, fast-follow and on-demand delivery modes. Am I correct?

Do u have ETA when it will backport to 2020.3.x LTS? 2020.3.16 LTS?

 

2020.3.15f1 looks like totally about backport this feature and already released

 

Will it be available for unity2018 LTS?

 

That was a surprise move. Thanks Unity.

Tried it yesterday and it able to make an aab build fine and well, but I've encounter exception, something along the line of things are not loaded. This is not happening in OBB version, is there anything else that we need to do?

I using 2020.3.15f1

 

@JuliusM I see. One more question. Does AsyncReadManager api supported PAD in 2020.3.15f2?

 

Hi @JuliusM. PAD feature doesn't seems working properly in 2020.3.15f2. I get "An error occurred while running bundletool build-apks on your uploaded app bundle. Ensure that your app bundle is valid by running bundletool build-apks locally and try again. Learn more. Error: Usage of 64-bit native libraries is disabled, but App Bundle contains only 64-bit native libraries." when upload my build to google store. Any idea why? I enabled both Export for App Bundle and Split Application Binary according to PAD documentation.

 

@JuliusM Can u make it support only ARM64 target architecture since one of dots developer tells me only ARM64 target architecture is supported at Android platform? And also if I disable 'split application binary technically it's not using PAD feature anymore and the AAB android build can't exceed 150MB right?

 

@JuliusM Do u mean just set min API level to 21 alone can fix only ARM64 target architecture issue? Anyway can u submit this issue to Google so they are aware of it? Or maybe other way round make dots project officially support android ARMv7 architecture too.

 

@JuliusM Actually even I didn't do any adaptation for Addressables also should be no problem right? It's just I can't customize asset pack delivery mode. Unity by default will build maximum 2GB AAB build that inside has maximum 1GB install-time asset pack then follow by maximum 2 count of 512MB fast-follow asset packs. Something like that? At least for me I dun see any use case that I need to change it.

 

@JuliusM Looks like 2020.3.15f2 is missing Unity.Android.Types. Can u make sure it's available in next 2020.3.16?

 

@JuliusM Alright. Case 1355569.