I've added several thousand files to my assets and suddenly it takes a minute to start when debugging from eclipse. Is there a way to have it not recopy all the asset files over each time?
Is there a way to have it not recopy all the asset files over each time?
No, other than to don't put them in assets/, but instead access them in some other fashion (e.g., external storage).
Note that the Play Store has a 50MB limit on the size of your APK file, in case your problem is literally in the transfer time to the device or emulator.
Related
When I launch the app, where do the assets/ folder contents go?
Are they loaded into RAM?
Or maybe AssetsManager always reads from inside /sdcard/?
Am I safe to assume that any Android device handles assets/ folder in the same manner?
My concern comes from the fact that some devices that I target are very limited in the amount of RAM they can provide, while all of them have a decent /sdcard/ storage, therefore I must decide if the assets should be downloaded at runtime or if they can safely be included into the apk file.
Assets are not saved in the "external files" directory (a.k.a the SD card). They're saved in the main app storage.
You can encourage your app to be installed on the SD card via android:installLocation="preferExternal". Your app will use this less valuable storage for everything, not just assets.
To have just assets on external storage consider expansion files like #pskink mentioned in a comment, or downloading them yourself and caching them in external storage.
I have successfully launched a 587 MB application on a device that comes with 512 MB available RAM, so it turns out that at least some of the devices indeed avoid pulling the whole assets/ folder to RAM upon launching the application.
When I complete the Android app I am developing I will want to distribute it so that about 300 image files are stored on the sdcard. Is there any way to do this within the usual automatic installation system? I don't want to hog the internal memory by including the files in res/raw.
I believe the app can now be built with an instruction to install on the sdcard so I suppose I could do that and include the files in res/raw but is there any limit on the number of files in res/raw?
If you didn't want to include the images you could utilize the APK Expansion Files mechanism:
http://developer.android.com/google/play/expansion-files.html
It will even save it to the sdcard.
Otherwise, you will either have to include the images or download them programmatically to the sdcard. As for the limits of the res/raw/assets folder I couldn't find any hard figures. The upper limit though would be the max size of the apk. You could always write a little script that would place 5k/10k/20k 1byte files and see for yourself on that upper bound. If the actual amount of files became an issue you could always zip them in the assets/raw and unzip them to external storage.
I have personally shipped an application for a client that had upwards of 500 images in the assets folder and it worked very well.
I making an application with phonegap/cordova where I need to keep a lot of files up to date. Some files (mainly images) will need to be erased in time, and some new ones will get downloaded. The thing is, in Android, to manipulate those files, it seems I need to have them on the sdcard; so I copy the files the app starts with from my assets folder to the sdcard. It just seems like a waste of memory space.
Do you know if is there anyway I can start with the app having those files the app starts with already inside the sdcard? or at least somewhere I can delete them later?
Thank you.
Files that are delivered to the device as part of your APK will be stored in a form that cannot be modified by your application (other than by updating to a new version of the apk).
If you copy the files out of the APK into the private internal storage area or the external storage area, those copies can be modified, but the originals inside the apk will remain.
The most efficient solution may be to not put these files in your apk, but have your app instead download them separately on the first run, using whatever mechanism you wanted to use to change them in the future.
(Some people object to this feeling that such files are less secure against unauthorized use, but as the contents of an .apk are trivial to extract this is not a strong argument. Needing to maintain a server to download from is a slightly more substantial objection.)
You do not need to store the files on the SD Card. Each app has its own internal storage that is not accessible by any other apps. For more information see the official docs: http://developer.android.com/guide/topics/data/data-storage.html
I've been developing this content-based app for Android which includes over 120 MB of video .mp4-files saved on the raw folder and in addition it includes over 20 MB of sound files also saved in the raw folder.
The problem is I cannot install the app on my Android phone due to limited internal memory to handle all those files. Also, I read somewhere that the app size limit on the Android market is 50MB so I won't be able to even upload the damn thing.
I've saved the videos on the raw folder as I was able to play them fine (using VideoView).
My question is how do i cope with such size, do I have to go through making the user download the content after installing the app or is there any other way of dealing with such sizes (~140 MB).
You cannot distribute an APK through the market that is more than 50MB. Its not a good idea to take up 120MB of the internal storage for a single app as many phones don't have a lot of internal storage space.
You should consider stripping out all of the large files, hosting them on a server and then having the application download the files on the first launch. I would also recommend you save the files to the SD card so you don't use up too much of the precious internal storage.
Edit: I will admit that any time an app tries to download a lot of data on the initial launch I get really frustrated. Make sure you do it in a way that doesn't require the activity to be open the entire time the file is downloading. Do the downloading through a service so the user can at least use their phone while your app is downloading the media files.
Well, if you're sure you need all this content inside your application, the only solution I see is to download the content from a server when the application is opened for the first time. But as a user I think I won't be very happy to have a 150 Mb application on my phone. Do you really need all this data?
I have 2 binary files that i would like to package with my apk. (/res/raw)
i need to copy these 2 files to /sdcard when the application is run
how can i do this?
We have the same issue ... the direction we are exploring is to have two separate installs - the first one is the app and the second one is the data-app. When the data-app installs it copies the binary files to the SD card. When we uninstall the data-app it frees up the internal storage.
We don't have this one completely licked yet, and would love to hear other input and maybe find someone to help us by writing a couple of skeletal sample applications for us.
There are so many people who are in this boat (based on my googling) that if this approach doesn't work I suggest we (or someone) set up a generic file delivery web server and generic file delivery Android service and make it available to developers for a very low cost.
You need to use the AssetManager.
That will give you can InputStream that you can copy to a FileOutputStream.
It all depends on what your goal is by doing this.
Are you trying to be nice to the user and conserve disk space on the device by moving files to the sdcard? Or do you merely want to ensure that these files are on the sd card?
If you just want to put the files on the sdcard then you should use the AssetManager as CaseyB mentioned
If you are trying to conserve phone memory then consider distributing the apk file without the 2 raw files, and then on first run download the files from a server that you have set up. This may cause a bit of a problem due to the time needed to download the files, but some users on devices with limited memory available on the device itself will be appreciative of it.