Support Multiple Texture Compression options for Android.

[dellis1972]

The current system we have allows users to specify the TextureCompression directly for android. So if the user wants to ship GPU specific apis [1] they need to build the .apk 3 times.

This is because they

1. Need to change the AndroidManifest.xml to specify the GPU they want (as per [1])
2. Rebuild the content with the correct TextureCompression for that GPU (ATI, PVRTC, DXT).

Because the texture compression method would need to be specified manually the user would need to maintain 3 Content.mgcb files. This is not ideal.

We need to come up with a way of just using "Compressed" for texture and being able to change the default texture compression for Android. It will default to ETC1 for Opaque textures and 16bit RGBA for those with Alpha.

[1] https://developer.android.com/google/play/publishing/multiple-apks.html

[dellis1972]

this issue was a result of the chat on #5013

[tomspilman]

To me we start with what people expect for packaging.

IMO the user should only build Android content once to get everything they need to ship their game. So it shouldn't be a matter of compiling content 3 times with different compression settings.

Should the pipeline be generating 3 different Content folders... one for each texture format? Likely lots of duplicate data in those as not everything is textures.

Also what about content formats that embed texture data? Like sprite fonts... it isn't a texture itself, but contains texture data? Can we identify these content items to know to process it multiple times?

The other approach is to output only one Content folder yet export content with textures 3 different times into that folder with different names on those files? So instead of just .xnb.... maybe .atixnb/.pvrxnb/.dxtxnb? But that sounds like a mess for someone generating the output .apks?

I guess I don't know enough about Android packaging to suggest a direction.

[dellis1972]

I might try to write some extensions for the Android build process (seeing as I wrote most of it :P ) to allow the generation of x apk during one packaging step.

Xamarin already do that for each eabi that is supported, so if you support x86 and x86_64 you get two apks for each. We can probably do the same thing. Via a simple

true

flag or something similar.

[KonajuGames]

Also need to keep in mind that the AndroidManifest.xml needs to be modified for each APK. The <supports-gl-texture> entry for the GL extension string and the Version Code so the Play Store can select the preferred APK for the user's device.
https://developer.android.com/training/multiple-apks/texture.html

We could add an /AndroidTextureCompression global option to MGCB where we can set the desired compression mode for Android where /TextureCompression property is set to Compressed. The /AndroidTextureCompression option would default to ETC1, but could be overridden on the MGCB command-line, similar to how we override the /Platform property now when building content through Visual Studio. This property would only affect Android builds, and would allow some specialization of the texture compression mode for Android builds without touching the .mgcb file.

As to how to detect only those files that need to rebuilt when the compression mode is changed, I don't have an answer for that at this stage.

[tomspilman]

Also need to keep in mind that the AndroidManifest.xml needs to be modified for each APK. The entry for the GL extension string and the Version Code so the Play Store can select the preferred APK for the user's device.

So how is this normally done? Do people keep 3 copies of the AndroidManifest.xml and just change project configs? Or do people always hand edit the AndroidManifest.xml between builds?

Sounds like the Android build process is just as shitty as everything else on that platform.

[tomspilman]

We could add an /AndroidTextureCompression global option to MGCB where we can set the desired compression mode for Android where /TextureCompression property is set to Compressed.

A global option makes sense. And as you say.... this can be passed on the command line to change texture processing on all textures and not saved in the .mgcb file.

[tomspilman]

So on Android can you build add-on packages that can be downloaded along with the main APK?

Thinking maybe we would just recommend to people to use a separate .mgcb file with just their texture content. This way just that content project is rebuilt and packaged separately?

Not that I have any clue of how Android packaging works.

[dellis1972]

@KonajuGames I had the same idea. Sounds like a good option to me. I can write some target extensions to make that easier. I like the idea of '/AndroidTextureCompression' We can work with that.

The AndroidManifest.xml is either edited or has multiple copies. The other option is to use the AssemblyAttributes we provide with Xamarin. The downside of the latter is you have to build you project 3 times. I can probably write some targets that can auto update the <supports-gl-texture> element during the build process.

You only need the add-on package if you go over the Play store limit (50mb I think). And its a PITA to use. I had to use it for Skulls so I have some code, but it does mean pulling in a ton of code, not something we want to do in the main repo I don't think..

[KonajuGames]

So on Android can you build add-on packages that can be downloaded along with the main APK?

They are called expansion APKs, and is how Google gets around the 30-50MB limit on APK size. Download an app from the Play Store and the expansion APK is usually downloaded with it. But the kicker here is that the expansion APK could be removed at any time, so your app has to check the expansion APK exists, and if not it has to go to the Play Store to request it again. This requires the Android Licensing library and all that garbage to get the temporary URL to download the expansion APK through the background downloader service so the APK continues to download even if the app is backgrounded.

They are their own world of pain.

[KonajuGames]

The expansion APK also has to be named specifically, and that name includes the Version Code from the Android Manifest.

[tomspilman]

They are their own world of pain.

Yeah sounds worse.

Another thought.... if for Android builds we automatically built 3 different .xnbs for texture content, could we modify the packaging process to only pull the right one by file extension?

This means we build content once... build all the texture variants... then package it 3 times.