Inspiring

Question

Android APK Expansion Files for Apps over 50MB

Forum|Forum|12 years ago
June 25, 2013
3 replies
43983 views

Hello Support,

We are building a new version of an app pubished on PlayStore (built with Adobe AIR) and need to embed higher resolution images. This results in my app apk file size which is over 100 MB.

Google allows to upload apks that are <= 50 MB. For apps which require more storage capacity than this limit, expansion files are needed.

Can you please inform us about how to incorporate these expansion files with an AIR app?

Is there a native extension or a built-in feature to prepare the expansion files and surpass the limit?

I've looked in the forums & there is no definite answer or solution.

If this is not possible at present, can you please add it to the wishlist for the next version of Adobe AIR SDK? Or perhaps, release a free/paid native-extension which enables this.

Thanks!

This topic has been closed for replies.

N

NicolasTony

Known Participant

Hello,

I ran in the same size issue but made my own solution : create a obb (you can put anything you want in it) which in my case is pretty much a zip.

At start, I have some version checking blablabla but in the end what it does is unzip the part needed of the obb on the external storage (yes its easily accessible but there is no code or sensitive data in here).

It works fine.

BUT most of the content are swf files I need to load/unload at runtime for performance reason (Memory, ...), problem is now that they are on external storage I get a

*** Security Sandbox Violation ***

which tells me I try to access an incompatible context.

So I set the context in the loader, I then get :

Security sandbox violation: local SWF files cannot use the LoaderContext.securityDomain property.

Seems logical but how can you not be local on a phone (except if you redownload every swf every time : unacceptable).

I tried to write in the app directory but it seems it is forbidden on Android, whatever permission you use (which makes sense maybe).

I know I could use Loader.loadBytes to avoid Security violation, maybe that's my next step, although I don't know if it will allow unloading nicely (freeing memory) and loading as fast and swf access working the same (getting subclip properties in them, using ApplicationDomain to create new symbol etc).

So my best solution would be to be able to load a swf on Android "normally" (loader.load) even if it's external storage (ie different directory than application), I just couldn't get around the security issue so far.

Any help welcome.

Btw isn't it ironic that I can do whatever I want in the external storage of my application (read/create/writte/delete files and folders) but NOT be able to load them as normal swf afterwards...

Edit : just in case you ask : I unzip on "disk" and not just in memory because

1) keeping all the needed swf for the game in memory all along would be too large (150Mo of swf), same with keeping the full obb in memory.

2) unzipping every time I need to load one of them would be too slow, so having a direct access is required.

Also since I can delete the obb file and put a tag version after I unzipped it, this solution has no drawbacks except accessibility to the files for end-user but like I said : not so much of a problem for what I chosed to put there.

P

pol2095

Inspiring

the obb can be a sqlite file too (blob type), is not necessary to unzip.

you can use Loader.loadBytes

N

NicolasTony

Known Participant

Thats what I did.. which seems silly, one having AIR and rights to read/write/whatever in a folder, should be able to load swf from that folder with no Security issue..

So when I load a file I load it twice

- I load the file with a File

- then I load the byteArray resulting with a Loader loadBytes

What a waste..

Works on Android, verified.

Now I am going to check how memory is freed well or not when unloading those file at runtimes on Android (can't have the whole kept in memory all along as said), used to work great when it was Loader.load...

PS :

about the obb :

- I just cannot open the full obb to memory every time I need a file in it (way too large).

- loading files in it by stream specifing start pos and end pos in obb seems too much maintenance to me

- parsing for markers in it seems also a bit too slow (although I didn't try)

All in all I prefer to have the file output to "disk" on first launch/patch to get a faster access with no mem issue afterwards, only issue is this "SecurityDomain" which really shouldn't apply in air, in a read/write directory if u ask me (since you can do it anyway, just dirtier/slower).

Wolfgang Klopf

Inspiring

I have already written the native extension.

The extension informs you if the obb files (main, patch) are present on the device and if not they get downloaded (progress-, complete-, ... events are dispatched).

If they are available one can read the files in the expansion file and the extension returns an AS File object with which one can load the requested asset.

The app for which I've written the extension will be released at the beginning of Sepetember and I wanted to wait until then bevore I make the extension available to the comunity.

To use this extension properly, it might need some guidance and currently I'm very busy but if it is urgent for someone of you feel free to contact me: me@wolfknock.com

Wolfgang Klopf

Inspiring

In case you're interested.... The app in which I've used the extension just went online:

https://play.google.com/store/apps/details?id=com.redbull.android.RedBullIllume2013

P

pop-can

Participating Frequently

in this case, the obb can be a second swf ?

your swf can be the obb file

the swf in the apk is just a Loader

in my ane you can access at the obb file

public function onComplete(e:APKCompleteEvent):void{
var mainVersion:String="1000023";
var appXml:XML = NativeApplication.nativeApplication.applicationDescriptor; 
var ns:Namespace = appXml.namespace(); 
var packageName:String = "air."+appXml.ns::filename[0]; 
var mainObbFile:File = new File(e.params.getExternalStorageDirectory+"/Android/obb/"+packageName+"/main."+mainVersion+"."+packageName+".obb");
var loader:Loader = new Loader();
var request:URLRequest = new URLRequest(mainObbFile.url);
loader.load(request);
this.addChild(loader);
}

and

var mainUnzip:Boolean=false; // unzip the file

Pol, Im using your ANE, I have a beta apk and an expansion zip uploaded to Google. But it seems to freeze after the download screen.

On a faded screen with a box that just contains the name of my app.

It never seems to fire the onComplete function.

I am testing this through building to my device - thought it still seems to find the uploaded zip alright.

.

I have been trying to get a beta version up to test properly - unfortunately, though it says I have published a Beta APK - it says item not found when I follow the links.

Any ideas why it might be freezing?

p-c

D

dmonkeyjazz

Participant

hi Kirit,

did you find a solution ? I'm currently experiencing the same issue, my app is around 75Mb, can't upload it to the play store...

K

kirit_tannaAuthor

Inspiring

@dmonkeyjazz, Unfortunately not yet.

We're working on a Native Extension which will allow to use Android expansion files.

We will make it opensource & post about it here once its ready.

One solution to this problem at present can be to externalize and load your assets from a SWF on a remote server as newer versions of AIR support this.

Good luck!

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded