One of our apps has several thousand small data files that we're currently packaging as assets. It would help our code if we could package them as raw resources. I have tried to track down what the limits are for the number of resources an app can have of each type, but I haven't found any documentation on this. Does anyone know what the limits are on the number of Android resources?
Asked
Active
Viewed 2,308 times
3 Answers
11
After a lot of experimenting, it seems that you can have up to 16 bits worth of resources (65,536 resources) for each resource type. (There may be additional bits reserved for future use, which would reduce the max resource count, but I couldn't find any evidence of this.) It would be nice if someone could provide an authoritative answer, but after a year, I'm giving up.
EDIT (see the comment below by @B T): Based on this answer by hackbod in another thread, It seems that there are, indeed, 16 bits available, so one can have up to 65,535 resources of any one type (not 65,536, because zero is not available). Also, note that this limit applies only to the number of resources for a single configuration (locale, pixel density, etc.). Variations of a resource for different configurations share the same resource ID and don't contribute to the count. So you can actually have a lot more than 65,535 resources of any one type (e.g., layout or string), just not for any one configuration.
Ted Hopp
- 232,168
- 48
- 399
- 521
-
aapt imposes a 16-bit limit per resource type, per app. apklib resources add to the application's total number of resource declarations. – James Wald Nov 18 '13 at 03:07
-
@JamesWald - Thanks. I figured it couldn't be any more than 16 bits, but I wasn't sure if we perhaps had less. Can you point to any documentation for this? – Ted Hopp Nov 18 '13 at 03:37
-
2I had to dig through the aapt source code because it's not documented. The most significant 8 bits of the resource value represents the package id. The next most significant 8 bits represents the resource type. This leaves 16 bits for addressing resources. See makeResId() in https://android.googlesource.com/platform/frameworks/base.git/+/android-4.4_r1.1/tools/aapt/ResourceTable.h. Additionally, line 3817 of https://android.googlesource.com/platform/frameworks/base.git/+/android-4.4_r1.1/tools/aapt/ResourceTable.cpp sets the package id to 127, giving us a base value of 0x7f000000. – James Wald Nov 18 '13 at 05:38
-
This is why all app resources have values such as 0x7f010001, 0x7f030012, etc. Android platform resources are given values such as 0x00010013 because their package id is 0. This avoids resource value conflicts between the platform and applications. – James Wald Nov 18 '13 at 05:41
-
1@JamesWald - Okay. I had figured out most of that myself (except where to look in the source code :).) Although the code doesn't definitively address the question of whether Google considers any of the 16 remaining bits reserved for future use, it sure looks like all 16 bits are available. Thanks for the links. – Ted Hopp Nov 18 '13 at 07:12
-
1This comprehensive answer from @hackbod (http://stackoverflow.com/a/6646113/1386784) gives a lot of useful definitive answers in the scope of this question (like default package IDs, starting values for the type and resource bits, etc). It appears the correct answer is actually 65,535 (starts at 1). Also android platform resources are given a package ID of 0x01, not 0x00 (aapt does not use 0 for package, type, or number to "catch cases where they are not supplied" - from https://github.com/android/platform_frameworks_base/blob/master/include/androidfw/ResourceTypes.h) – btalb Dec 06 '14 at 12:37
-
1@BT - Thanks for that link. That's pretty definitive! If I had thought about it, I would have realized that 0 is not available so the limit is 2^16 (as I suspected) minus 1. – Ted Hopp Dec 07 '14 at 03:07
0
There's no explicit documentation on this that I know of either, however one can make reasonable assumptions that the Android devs have designed Android appropriately given their recommendations. They recommend that you put strings and drawables into resources with the potential to supply different ones for different locales, screen sizes, screen densities and orientations. The sheer number of these possibilities suggests to me that they expect apps to include thousands of resources and you'll be just fine supplying a few thousand small raw resources.
kabuko
- 36,028
- 10
- 80
- 93
-
The problem here is that you can't count different locales, screen sizes, etc., of a single string as separate resources. They are actually overlapping and use the same resource ID value. What I'm concerned about is pretty simple: how many bits of a resource ID are available for each resource type? Many bits are reserved to identify the resource type itself, so it's certainly not 32 bits. From browsing through some R.java files, it seems that it's at most 16 bits for any one resource type. If we have that many, we can get by, but any less and we may have problems. – Ted Hopp Nov 21 '11 at 21:52
-
That's a good point. Maybe the best way is to just try. You could write a quick app to generate files, maybe 1.txt, 2.txt, up to a configurable number maybe with the same number as the file contents. Then do the same to generate some simple java to read the resource in Android and maybe throw an exception or something if it fails. You could even directly generate a JUnit test. – kabuko Nov 21 '11 at 22:44
0
Taken into account the automatically class R and the resource value used in the api I would assume somewhere around Integer.MAX_INTEGER for string, drawable and layout id each.
Xeno Lupus
- 1,504
- 3
- 12
- 17
-
There's no way that is right. Each int value in R has at least half the bits reserved for flags of various sorts (for the resource type, whether it is a system or user id, and who knows what else). Like I said in another comment, a casual look at a well-populated R suggests that at most 16 bits are available for distinguishing between resources of any one type. – Ted Hopp Nov 21 '11 at 23:55