According to the Android reference page, FileBackupHelper should "be used only with small configuration files, not large binary files."
I managed to successfully backup a database file of 8 kilobytes, but I'm curious at what point a file becomes a "large" binary file. Do you think Android is referring to files in the megabyte range?
I believe there is no hardcoded limit in Android source code (which defines "large" vs "small"). At least, I didn't find within 10 minutes looking through Android source.
Generally speaking, you should take into consideration a speed of wireless connection. It depends a lot on where you and your users are located. If it's major cities with 3G/4G coverage - I think you can backup a megabyte, if's rural area and your users are charged per kilobyte, I would rather scale back to dozens of kilobytes.
Related
I am a newcomer to the world of Android. Few days ago I tried to write a program whose purpose is to enable / disable bluetooth by following instruction in a book for beginner and succeeded. However its size is 888 kb, compared with one bluetooth enabler application that I found on the Internet, whose size was only 56kb. Was my code too complicated ? Which ways can I take to review my code for a smaller size ?
First off without seeing the code or even comparison of the two apps it's hard to make a comparison. However, some things that come to mind are
Proguard
Fewer/smaller icons and images (only 1 image for mdpi)
Fewer layouts
But either way, I wouldn't be worrying much about 900kB. Most template apps generated by Android Studio will have some minimum size.
Make sure in your Gradle file you have minifyEnable.
If you have a ton of images in your app, you need to optimize them to the resource sizes.
I have an android native shared library (.so) that is used in an android application. This library was originally written for windows/desktop, and then ported to mobile platforms. It contains an "algorithmic" code, which works on large data set. Within the library I don't use a standard heap (malloc and friends), instead memory pages are allocated via mmap with flags MAP_PRIVATE | MAP_ANONYMOUS and then partitioned appropriately.
Now, the problem is that at some point mmap fails with error code = 12, which is out-of-memory. This happens when the total allocated memory size reaches about 650MB. I know this value if pretty large, and way above what a typical android application needs. But in my specific case this is legitimate IMHO, since this is indeed what this library/application does, and this is realized and approved by the user.
Specifically I try to run this on Samsung tablet SM-T800, which has 3GB RAM, a 32-bit armeabi-v7a architecture, and more than 7GB of free storage space (flash memory). So that technically there should be no problem.
Also this is not a problem of virtual memory fragmentation: the mmap fails when I ask to allocate additional memory chunk of as much as 16MB. So, most probably some artificial limitation is imposed by the system on how many memory pages can be allocated for the process.
So, my question is, if and how this limitation can be removed. From what I found in online documentation, there is no mention of this limitation, but I'm pretty sure it exists. I've also read in some forums that starting from Android 5.0 some applications fail to allocate as much memory as they could in older systems.
In case this limitation can't be removed, would it help to work with file mapping? Currently I store the data in source files in a compressed way, then I read it and build a complex data structure in memory. Instead I could store the whole data structure in a file (means, the file would be larger), and just map it into memory via mmap. The total size of the virtual address space would be the same, but if the limitation is not on its size, but on how many pages are allocated and not backed by a file - this could work.
As a last resort I can abandon the idea of having all the data in (virtual) memory, and manually read & lock only the data portions that I currently need, and discard those that are not used recently. But by such a way I actually duplicate the work of memory manager, since the paging mechanism does exactly this.
Thanks in advance.
I'm going to write a music player for android which satisfies specific needs (which doesn't matter to my question).
I'd like to identify internal playlists with directories (inside of one main directory) on sdcard because I know my users will set up organized directories. So simply reading all audio files in a single list to let the user create playlists manually afterwards would probably be annoying.
I'm wondering whether it's worth to generate a hierarchical playlist file for this purpose.
My current plan is to run a "library inspector" when the app is started. This inspector will use a "library state" containing of hierarchical data of the form
String filename;
long modified; // timestamp of last modification
to check the library recursive for the need of creating a new playlist file. If this matching check fails, this hierarchical file (metadata: title, artist, album, ... - for example xml) is created including a new "library state". This file should prevent to read all the metadata every single run of the app.
To make that clear: I'm searching for an efficient way to play music - but safe battery!
Since I'm new to the development of mobile apps, I'm not very familiar with battery saving. Is it that more saving to read one file instead of recursive metadata reading? Or maybe I'm about to overdo things? Do you know some strategies of established applications?
I'm very interested in your thoughts :) and I hope my bad english doesn't prevent your understanding ... I'm sorry for that.
Thank you!
Max
I can't answer from the perspective of using MediaStore or SQLite, but can give you some suggestions about minimizing battery usage.
Don't use recursion. Recursion is structurally compact but awful in terms of efficiency. Every call is very expensive due to accessing stacks, possible doing context switches, etc. If the recursion is very deep, there are also issues with regards to disk usage, page swapping, etc.
Use an efficient searching algorithm for any large list. The faster you complete what you're doing, the more the processor is idle, the deeper the power state, the more power savings.
Gather your searches / accesses together as much as possible. For example, if you have to do 3 searches, each 1 second apart and taking .5 seconds to execute, you'll keep the processor active in a high power state for over 4.5 secs before letting it rest and drop into a lower power state. If you gather your queries together, you spend 1.5s in a high power state, and 3 seconds in a lower power state. Roughly speaking, you use <1/3 the power.
Use on board memory as much as possible. I don't know how slow accesses to sdcards are, but it'll slow down your algorithm and possibly increase your power consumption.
Try to setup your database entries and other data structures so that they are naturally aligned with your processor's caches (e.g. 16B aligned). That will speed up routines by a significant amount (L1 cache access might be 1 cycle, L2 10 cycles, and memory 100 cycles - these values are illustrative but ballpark). And the fast your routine, the more idle, and the greater the power savings.
My timing durations (e.g. 1 sec apart) are just for illustration purposes. There are multiple idle states and different rules for dropping into those states that can make a real illustration very complicated.
I don't know much about the power efficiency of databases. I do know there are some data bases designed for mobile and low power devices. Unfortunately, I don't recall what they are. (Don't quote me on this, but I recall something about Berkeley and real time.
PS Your English seems excellent.
I'm developing an app that will download large files (mostly videos). What I need to know is this:
Is there a max singe file size imposed by either Android or iOS? All I've seen is the 4GB limit of a FAT filesystem. The max video size should come no where near that, but we want to be 100% sure that there isn't a lower limit
Is there a max amount of space allocated to a single app on either system? Google turned up nothing on this question, so I am going to assume there isn't a limit beyond available file space (which seems logical, but also far to free for an Apple-built system)
Is there a max number of individual files or directories for either system? Again, Google turned up nothing. I don't see why there would be here, but I want to cover all the bases here.
Thanks!
All answers here are for Android:
Is there a max singe file size imposed by either Android or iOS? All I've seen is the 4GB limit of a FAT filesystem.
I would not exceed 4GB.
Is there a max amount of space allocated to a single app on either system?
No, there is no per-app quota system at this time. That being said, try not to make users regret using your app. :-)
Is there a max number of individual files or directories for either system?
Yes, but since the counts should be in the millions, your app will grind to a halt long before you hit those limits.
Can't answer for iOS, but for Android, your APK can't exceed 50MB (if it does, you can include expansion files for your additional data).
Here is the link to the docs explaining all the details:
http://developer.android.com/guide/google/play/expansion-files.html
Android - What is the maximum file size that setMaxFileSize can be set to in respect to Androids mediarecorder? I know it's somewhere between 4147483650 and 5147483650. Why is there a limit in the first place?
I'm recording on to a SDCARD, detecting the size of the cards space before we run.
"ERROR/AuthorDriver(31): setParameter(max-filesize = 7270309850) failed with result -5"
"ERROR/AuthorDriver(31): Ln 903 handleSetParameters("max-filesize=7270309850") error"
"ERROR/AndroidRuntime(409): java.lang.RuntimeException: setMaxFileSize failed."
Why is there a limit in the first
place?
SD cards use the msdos (FAT16) filesystem, which has a file size limit. This is not an Android limitation, but a limitation of SD cards in general.
If you look in AuthorDriver.cpp, you'll see that it performs a check to see if the time value you passed in will fit into a 16bit int. There's a comment that reads "PV API expects this to fit in a uint16". So, yeah, there doesn't appear to be a way to get around this for now.
I have tried on GS5, Hauwei Y550, Note 3 and they all can't record files longer than 4096 MB (even with their official camera application). This limits 1080p videos to 35 minutes and 4K videos to less than 20 minutes. The reason is the one provided by Shane-Kirk (except it is 32bit).
I have opened an enhancement issue on Android source code with all details, if you are interested please consider starring it, the more we are the more likely they will make a patch to AuthorDriver.cpp.
https://code.google.com/p/android/issues/detail?id=145618&q=mediarecorder&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars
I'm working on an android recorder as well.
use StatFs and pass the path of the external storage directory to the constructor and you can call functions such as getAvailableBlocks() and getBlockSize() on the StatFs object.
So that way you know how much more space is available on the SD card.