Thanks Xavier, very helpful. If/when you decide to allow aapt to disable overlays it's going to have to default to allow overlay otherwise lots of builds will immediately break.
William On Thursday, December 19, 2013 9:31:30 AM UTC+10, Xavier Ducrohet wrote: > > 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 < > [email protected] <javascript:>> 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 <[email protected]> wrote: >>>> >>>>> On Mon, Dec 16, 2013 at 6:27 AM, William Ferguson < >>>>> [email protected]> 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]. >>>>> 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] <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.
