New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android does an ugly copy of all assets #3465

Closed
est31 opened this Issue Dec 18, 2015 · 7 comments

Comments

Projects
None yet
4 participants
@est31
Contributor

est31 commented Dec 18, 2015

Currently, the Android copies all assets to the storage so that it is "inside" a directory. This however is totally ugly, as now there are two copies of the same files, using up highly constrained memory. Combined with bug #3464, the asset is stored three times on the disk! Also, it creates an overhead when starting the app, because the stuff has to get copied every time. And, it is bad when multiple forks of minetest are installed on the same device: they overwrite each other, and cause conflicts.

This bug is related to #2097.

I see two ways to fix this bug:

  1. Use obb files. Once downloaded, they are very convenient to use as one can simply mount them to a point. No further changes required, except setting path_share accordingly. The problem with them is that f-droid doesn't support them right now, so we would have to host them ourselves, or convince/help f-droid to support them. Additional issue is that I can't test a potential play store downloader on my own as I lack the required developer access to the play store. It would be great if @nerzhul or @MoNTE48 could help out on this.
    One would also have to think something to get it work for development builds, perhaps there we can ship the obb with the apks assets and copy it to the place on startup (I know, irony xD, but this is only for development so no big issue).
  2. Use the AAssetManager_* functions from android/asset_manager.h. Very tedious to implement, as for implementing it we have to replace the current direct way of loading stuff with our functions. A short cut would be to use hacks like this.

@est31 est31 added the Android label Dec 18, 2015

@MoNTE48

This comment has been minimized.

Contributor

MoNTE48 commented Dec 18, 2015

I keep these files files.zip on assets, and then simply unpack the archive. I'm using the version comparison through sharedpreferense. Unpacking takes a few seconds and happens only if you delete the destination folder, or a new version of apk. Can I license my code as a LGPLv2 and help you if nrz apologize to me.

@sapier

This comment has been minimized.

Member

sapier commented Dec 18, 2015

Well this isn't really fixable for following reasons:

  1. Irrlicht doesn't support android/asset_manager.h
  2. Minetests architecture separates client from server almost completely if you wanna use shared resources you'd have to mess up the design

@1, feel free to implement it for irrlicht I'm quite sure those guys will accept your patch.
@2 I know this is very painfull on android but messing up the design is even worse.

Edit1:
I can't help if those minetests forks did do bad work and not fix their own paths! Blame them not minetest!
BTW files aren't copied on any start the only thing done is checking if all files are present! So the only thing left is cache wich isn't copied if it's present too.

@est31

This comment has been minimized.

Contributor

est31 commented Dec 19, 2015

  1. I think I have a way to make it work even with current irrlicht. Either by using createImageFromData and then using createDeviceDependentTexture or if that is not possible by implementing our own IArchiveLoader.
  2. that's more about #3464 so better discussed there.

@est31 est31 removed the Won't fix label Dec 20, 2015

@est31

This comment has been minimized.

Contributor

est31 commented Dec 23, 2015

Okay, implemented a first prototype with the AAssetManager_* functions: https://github.com/est31/minetest/tree/asset_loader

It works: you can connect to singleplayer and network games. But it has one problem: it is very slow. Most likely that's because every single file is decompressed.

Now I even wonder whether we should perhaps even keep an asset copy. But still, the way we currently do it is very ugly. We should store the stuff into an app-local folder, and we should use a better algorithm for checking whether something changed. Currently we don't update if the file changed, so that people have to delete the folder, and we do check every file on start, even though it causes an observable overhead.

@MoNTE48

This comment has been minimized.

Contributor

MoNTE48 commented Dec 23, 2015

I once again an excuse to see my code. He's very fast. Checks only version of the game. If the version apk changed, then it will be Unpacking again.

@sapier

This comment has been minimized.

Member

sapier commented Dec 29, 2015

est31: I remember some thing about assets on android. For what I remember reading a file from it involves decompressing whole assets till that file is found. Maybe that's why it's so slow to you.

@est31

This comment has been minimized.

Contributor

est31 commented Dec 29, 2015

My next try will be obb :)

@paramat paramat removed the Enhancement label Oct 29, 2016

@est31 est31 closed this Apr 25, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment