With the equivalent command line, why aapt.exe output different ids than aapt2.exe? also how work exacly the r.java? I use aapt and aapt2 to produce the r.java like this :
"aapt.exe" package -f -m -M "AndroidManifest.xml" -I "android.jar" -S "\res" -J "\RJava" --auto-add-overlay
But I still not understand why the value of the generated ids inside the R.java matter? How those ids work exactly
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.
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.
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
0x7f
(application), but also 0x01
(Android framework) and 0x00
(shared resource library) are common.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.
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).