Great, thanks Tor, Xavier. All of that makes sense to me except for the bit about overlaying resources.
If we are talking about an apk that has a dependency on a single aar then you could I guess decide that the apk resources overlay those of the aar. But what about when you have 2 aars that have similarly names resources. The aars are likely to have been developed independently with the name clash entirely unintended/unexpected. BTW when resources are provided to aapt using the "-S" flag how does it determine which resource is top most? First, last, arbitrary? William On Tuesday, December 17, 2013 5:03:14 AM UTC+10, Xavier Ducrohet wrote: > > App override library resources, always. As Tor said, we don't care about > strings.xml, we do the merge on resources, not on files. > > Libraries are compiled with non-final resource IDs, and classes.jar does > not include the R class. > R.txt is meant to clearly define what resources are in the library. > > App generate the final list of resources, merging resources from the app > and the libraries. We use aapt to generate the IDs for the combined > resources, using the app's package name and using final integers. Once this > is done we go through all the libraries and use their R.txt file to > manually generate a R class in their own package name. These are final > integers as well. > (there's also some code to deal with the case where libraries have the > same package name, but we might move away from allowing this). > > > On Mon, Dec 16, 2013 at 10:55 AM, Tor Norbye <[email protected]<javascript:> > > wrote: > >> On Mon, Dec 16, 2013 at 6:27 AM, William Ferguson < >> [email protected] <javascript:>> wrote: >> >>> Can someone please explain to me how Resource id generation is going to >>> work now with AARs. >>> >>> Incorporating APKLIBs was slow but fairly straight forward. I have just >>> spent the last 48 hours trying to get the android-maven-plugin to build an >>> APK that depends on an AAR that has code referencing it own resources. As >>> part of that I have spent a large chunk of time trawling through the >>> android platform tools source and it's not clear to me that all use cases >>> have been covered. >>> >>> So I hoping that someone can clarify a raft of questions that surfaced >>> as part of my investigations for which I couldn't find any doco. >>> >>> An AAR contains the following (plus some optionals) >>> >>> - /AndroidManifest.xml (mandatory) >>> - /classes.jar (mandatory) >>> - /res/ (mandatory) >>> - /R.txt (mandatory) >>> >>> >>> In my APK that consumes this AAR I will presumably also have resources. >>> >>> Q1: What should happen when there is a name clash between the AAR and >>> APK for those resources? Eg >>> - AAR/res/layout/layout_main.xml vs APK/res/layout/layout_main.xml >>> >> - AAR/res/values/strings.xml vs APK/res/values/strings.xml >>> - AAR/res/values/strings_a.xml (string1) vs >>> APK/res/values/string_b.xml (string1) >>> Should the build break in any/all 3 cases? >>> >> >> Case 2: they are unrelated. Value files can be named anything. This >> should not be treated as a clash. >> Cases 1 and 3 are the same; for non-value resources, the resource name is >> derived from the file, so they both define @layout/layout_main. >> Again for case 3 the value of the file name doesn't matter, but they're >> defining the same string. >> >> I believe the right thing to do here is to treat this as an overlay: the >> app redefines the resource. At least that's how we treat the case where >> multiple flavors provide definitions for the same resource. Seems >> reasonable that a library would be treated similarly, though Xav should >> confirm. >> >> Q2: Does/Should AAR classes.jar contain a compiled R class. >>> >> >> No. The id's in the R class *must* be changed when the final app is >> assembled, so it's done at that time (it computes a global set of unique >> id's, then creates R classes for each namespace required by the various >> compiled classes, assigning those id's). >> >> Q3: Should that R class have non-final fields. As suggested by >>> http://tools.android.com/tips/non-constant-fields? >>> If it has non-final fields then how are those fields updated to >>> reflect the the values generated during the APK build. >>> If they are not updated then how are id clashes from more than one >>> dependent AARs prevented? >>> >> >> Id's in library cannot be final since if they were, they would get copied >> into the various classes.jar classes in the library, and could then clash >> with other libraries. By being non final, they will defer to runtime to >> look up the actual value, where they can find the id's actually assigned in >> the final app assemble. >> >> Q4: If the AAR R class either doesn't exist or has final fields then the >>> final values will have been burnt into the compiled classes that use them. >>> During he APK build when the resource ids are generated for all the >>> resource contained in the APK (including the AAR resources), how are the >>> references in compiled classes updated? >>> >> >> Again, it creates multiple R classes, one for each library package, but >> ensures that the R id's are identical across these classes. >> >> -- Tor >> >> -- >> You received this message because you are subscribed to the Google Groups >> "adt-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > > > -- > Xavier Ducrohet > Android SDK Tech Lead > Google Inc. > http://developer.android.com | http://tools.android.com > > Please do not send me questions directly. Thanks! > -- You received this message because you are subscribed to the Google Groups "adt-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
