Skip to content
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

Unpacking and copying app contents causes app to appear hung #983

Closed
kollivier opened this issue Jan 16, 2017 · 4 comments
Closed

Unpacking and copying app contents causes app to appear hung #983

kollivier opened this issue Jan 16, 2017 · 4 comments

Comments

@kollivier
Copy link
Contributor

We have an app that has a lot of data files, and we support preloading our app on devices without internet access, so the Play restrictions do not apply and furthermore we cannot rely on downloadable asset packs. When the app is first loaded, the unpack and copy of all the app's data files to the /data partition causes the app to appear hung for upwards of 1 minute because the unpack happens in onCreate. Having an app display a blank screen for any real length of time, much less a minute or more, gives a pretty bad first impression.

My understanding is that the technical reason for this process is that fopen and co. will not directly open files on Android because of the need to use AssetManager, so this is worked around by moving all the files to a place where files are directly accessible. I've found another cross-platform app developer who addressed this by devising a drop-in replacement for the fopen series of functions that use the asset manager under the hood.

http://www.50ply.com/blog/2013/01/19/loading-compressed-android-assets-with-file-pointer/#comment-1850768990

Would something like this be an option? Or perhaps a slightly more advanced version that tries the asset manager only for certain paths, or falls back to fopen when that fails? I've spoken with @inclement and others on kivy-dev about this, but I wanted to open a ticket to track this issue as we will really need to get this fixed to continue using p4a.

@inclement
Copy link
Member

As far as I know, something like that could work but needs some hacking to test it out.

@kollivier
Copy link
Contributor Author

kollivier commented Jan 17, 2017 via email

@inclement
Copy link
Member

For patched software like Python 2, do you have a repo where you maintain the patches or do you basically just download the tarball, apply the patches, and then just make new ones each time there's a change like this?

Just the latter one, so you can make new patches by downloading the tarball, adding the relevant files to a repo, committing any changes and getting the patch with git diff.

@inclement
Copy link
Member

Closing as resolved by #990

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants