The order of library dependencies is important. Also we recommend devs to use a prefix in their resources when using libraries (look at app compat, it uses the abc_ prefix).
aapt's help output says the left most -S option is higher priority IIRC. (we don't use multiple -S anymore, we merge manually first so that it can be incremental) I've been thinking about allowing ( through the gradle file) to disable overlays and break on conflicts and then let developers control how the conflicts get resolved but it's a lot of work and low priority. On Wed, Dec 18, 2013 at 2:54 PM, William Ferguson < william.fergu...@xandar.com.au> wrote: > *bump* > > > On Tuesday, December 17, 2013 8:56:03 PM UTC+10, William Ferguson wrote: >> >> 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 <tno...@google.com> wrote: >>> >>>> On Mon, Dec 16, 2013 at 6:27 AM, William Ferguson < >>>> william....@xandar.com.au> 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 adt-dev+u...@googlegroups.com. >>>> 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 adt-dev+unsubscr...@googlegroups.com. > 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 adt-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
