tree 5d8bc8cdc04402ede23d9b271f08894ec5996f98
parent ab50b0795ac0ef5b4b6062b9d91fafbc9dda8645
author Jiyong Park <jiyong@google.com> 1620807236 +0900
committer Jiyong Park <jiyong@google.com> 1621321529 +0900

Record the actual APEXes that a module is part of.

Consider this case:

apex {
    name: "com.android.foo",
    native_libs: ["foo"],
}

override_apex {
    name: "com.mycompany.android.foo",
    base: "com.android.foo",
}

cc_library {
    name: "foo",
}

There are two APEXes defined: "com.android.foo" and
"com.mycompany.android.foo" which is a copy of "com.android.foo" with
some properties overridden (e.g. signing keys).

The module "foo" is mutated into two variants by the apex mutator: the
platform variant and the apex variant. The former has the variation name
"" and the later has "apex<min_api_ver>" which usually is "apex10000".

Internally, the apex variant has an alias "com.android.foo".

ApexInfo.InApexVariants() returns only "com.android.foo" when called for
the module "foo".

We can see that the information that "foo" is also part of
"com.mycompany.android.foo" is completely lost. This is causing problem
when we compare the apex membership by their "soong module name", not
the "apex name". In the example above, the two modules have different
soone module names, but have the same apex name: "com.android.foo".

To fix that, this CL introduces a new field `InApexes` to the `ApexInfo`
struct. It has the actual name of the APEXes that the module is part of.
With the example above, `InApexes` is ["com.android.foo",
"com.mycompany.android.foo"].

Bug: 180325915
Test: m nothing
Test: m nothing on non-AOSP targets with ag/13740887 applied.

Change-Id: I4e7a7ac5495d2e622ba92a4358ed967e066c6c2e