Merge operations: - root manifest: attributes ignored, warn if defined. - application: G- {@code @attributes}: most attributes are ignored in libs except: application:name if defined, it must match. except: application:agentBackup if defined, it must match. (these represent class names and we don't want a lib to assume their app or backup classes are being used when that will never be the case.) C- activity / activity-alias / service / receiver / provider => Merge as-is. Error if exists in the destination (same {@code @name}) unless the definitions are exactly the same. New elements are always merged at the end of the application element. => Indicate if there's a dup. D- uses-library => Merge. OK if already exists same {@code @name}. => Merge {@code @required}: true>false. C- meta-data => Merge as-is. Error if exists in the destination (same {@code @name}) unless the definitions are exactly the same. New elements are always merged at the end of the application element. => Indicate if there's a dup. A- instrumentation: => Do not merge. ignore the ones from libs. C- permission / permission-group / permission-tree: => Merge as-is. Error if exists in the destination (same {@code @name}) unless the definitions are exactly the same. C- uses-permission: => Add. OK if already defined. E- uses-sdk: {@code @minSdkVersion}: error if dest<lib. Never automatically change dest minsdk. Codenames are accepted if we can resolve their API level. {@code @targetSdkVersion}: warning if dest<lib. Never automatically change dest targetsdk. {@code @maxSdkVersion}: obsolete, ignored. Not used in comparisons and not merged. D- uses-feature with {@code @name}: => Merge with same {@code @name}=> Merge {@code @required}: true>false. - Do not merge any {@code @glEsVersion} attribute at this point.F- uses-feature with {@code @glEsVersion}: => Error if defined in lib+dest with dest<lib. Never automatically change dest. B- uses-configuration: => There can be many. Error if source defines one that is not an exact match in dest. (e.g. right now app must manually define something that matches exactly each lib) B- supports-screens / compatible-screens: => Do not merge. => Error (warn?) if defined in lib and not strictly the same as in dest. B- supports-gl-texture: => Do not merge. Can have more than one. => Error (warn?) if defined in lib and not present as-is in dest. Strategies: A = Ignore, do not merge (no-op). B = Do not merge but if defined in both must match equally. C = Must not exist in dest or be exactly the same (key is the {@code @name} attribute).D = Add new or merge with same key {@code @name}, adjust {@code @required} true>false.E, F, G = Custom strategies; see above. What happens when merging libraries with conflicting information? Say for example a main manifest has a minSdkVersion of 3, whereas libraries have a minSdkVersion of 4 and 11. We could have 2 point of views: - Play it safe: If we have a library with a minSdkVersion of 11, it means this library code knows it can't work reliably on a lower API level. So the safest end result would be a merged manifest with the highest minSdkVersion of all libraries. - Trust the main manifest: When an app declares a given minSdkVersion, it also expects to run a given range of devices. If we change the final minSdkVersion, the app won't be available on as many devices as the developer might expect. And as a counterpoint to issue 1, the app may be careful and not call the library without checking the necessary features or APIs are available before hand. Both points of views are conflicting. The solution taken here is to be conservative and generate an error rather than merge and change a value that might be surprising. On the other hand this can be problematic and force a developer to keep the main manifest in sync with the libraries ones, in essence reducing the usefulness of the automated merge to pure trivial cases. The idea is to just start this way and enhance or revisit the mechanism later.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|