The generated IDs in R.java
will not only differ between a run of aapt
vs a run of aapt2
, but potentially also between consecutive runs of aapt
resp. aapt2
themselves.
Purpose of resource IDs
The generation of the R.java
file assigns to each resource an ID for referring to it during the app's runtime. As written in B.Burd & J.P.Mueller (2020), Android Application Development All-in-One For Dummies, 3rd Ed., Wiley, p.87:
The hexadecimal values in a R.java
file are the jumping-off points for Android’s resource management mechanism. Android uses these numbers for quick and easy loading of the things you store in the res branch.
Structure of resource IDs
The structure of a resource ID is as depicted in Fig.1 (taken from the slides mentioned below):
Fig.1: Structure of a resource ID
- Package type: Mostly
0x7f
(application), but also 0x01
(Android framework) and 0x00
(shared resource library) are common.
- Resource type: There is no fixed mapping between types and values (by just looking at an ID value one can’t say if one is dealing with e.g. a string or an integer), but within the same package, all resources of the same type will have the same type identifier.
- Entry: This is simply a running number.
Because of the fields Resource and Entry there's always the chance of changes in the ID assignment by aapt
during compile time, even in consectutive runs. In the app's runtime the IDs will be static.
More info
For further details see the Android Dev Docs on accessing your app resources and these interesting slides by M.Kongstad & Z.Jovanovic from their talk on the SonyXperiaDev 2018. For an elaboration on the Doc's note
Caution: You should never modify the R.java file by hand—it is generated by the aapt tool when your project is compiled. Any changes are overridden next time you compile.
you may also take a look on the associated Stackoverflow thread on How to manually generate R.java. In short -- if one manually edits R.java
one highly likely ruins the resource references and gets errors at the latest at runtime (the most pesky type of errors ever).