construct_context.py is a script that runs at Ninja stage and constructs
class loader context arguments for dex2oat. Previously it accepted lists
of library paths and concatenated them into one class loader context
string. The script also handled the dependency of "android.hidl.manager"
on "android.hidl.base" that is not tracked by the build system and must
be handled in a special way.
Now that class loader context representation is going to change from
flat lists to trees, passing paths to individual libraries as script
arguments is no longer possible, because a list of paths cannot
represent a class loader context tree. Passing the trees in a serialized
form is also inconvenient, because the script would have to parse them,
which would complicate it a lot.
Therefore this patch ports all the concatenation and "android.hidl.base"
handling to Soong. It is not possible to port the remaining script to
Soong because Soong has no information about the targetSdkVersiion of
the dexpreopted apps (it is in the manifest and sometimes in an APK, and
has to be extracted at Ninja time).
Test: construct_context_test.py
Test: new subtests in TestUsesLibs
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: Icdb03cf00d1e27e4cff3844b89bfaec4de502dd7
The version in the tag is the SDK version that in which compatibility
library was added as a separate libary. Using distinct tags makes it
possible to differentiate between dependencies for different SDK
versions (this will be needed in subsequent CLs).
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: I72296c05d6649e811ddc701aaeb84f91d1ba66cb
Mimick the way PackageManager handles it at runtime: do add it to class
loader context for apps with targetSdkVersion < 30, but only if
"android.test.runner" is used. Previously it was not added at all.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: I4c06635277ab13e21069b9fa0b46eb6a2547dfdd
Also, add tests for compatibility libraries in class loader context.
This CL separates special-case handling of compatibility libraries into
a "fixup" step that is done after class loader context is constructed by
Soong. This allows to handle compatibility libraries and normal
libraries uniformly, which should enable further simplification of class
loader context representation (in subsequent CLs).
Currently the only "fixup" step is removal of libraries from conditional
class loader context if they already are in unconditional context. This
check cannot be done at the time when the libraries are added to
conditional context, because the full uncoditional context is not yet
known at that time. Previously construction of unconditional context was
delayed, now it is no longer delayed and handled in the same way as
unconditional context, and the "fixup" does the filtering.
Test: lunch aosp_cf_x86_phone-userdebug && m
Bug: 132357300
Change-Id: Ie71e9fb2d3d529b5317cd84e09ab3c853017c349
This change removes the properties in GlobalJSONConfig that are used to
hold the unmarshalled []string along with the code to convert them into
ConfiguredJarList as they are no longer necessary because the
ConfiguredJarList.UnmarshalJSON(..) method can handle that automatically.
Bug: 171479578
Test: m nothing
Change-Id: Ie297cd00cb23d12e544d922454868db6fe9eb77c
This change:
* Switches BootJars/UpdatableBootJars fields of config.productVariables
from []string to ConfiguredJarList.
* Updates BootJars() method to simply concatenate the jars list from
the BootJars/UpdatableBootJars fields.
* Adds an UnmarshalJSON(..) method to ConfiguredJarList to support
unmarshalling from a single string array to avoid having to change the
format of the JSON file from which the configuration is loaded.
* Adds some additional calls to ConfiguredJarList(..) in tests to
convert from []string to ConfiguredJarList. They pass nil as the
ctx argument as there is no suitable PathContext which will cause any
errors to be thrown using panic. That is reasonable for hard coded
values in tests. A follow up change will clean up the calls to
ConfiguredJarList(..).
Bug: 171479578
Test: m nothing
Change-Id: I59b94dafb479ccd8f0471ed802be175af57be271
This change:
* Changes splitConfiguredJarPair to return an error rather than
reporting it through the context.
* Extracts the splitting of a list of pairs into a pair of lists into a
new splitListOfPairsIntoPairOfLists() method for reuse in a follow up
change.
Bug: 171479578
Test: m nothing
Change-Id: I824ed1bc673b47757424563fc37e1190adff2ed1
... and ramdisk_available modules. If a module is both
vendor_ramdisk_available and ramdisk_available, on a device
that mark recovery_as_boot and move_recovery_resources_to_vendor_boot
simultaneously (and incorrectly),
both will be installed to recovery/root/first_stage_ramdisk. Fix the
path conflict of the two variants by moving the vendor_ramdisk variant
to vendor-ramdisk/first_stage_ramdisk instead.
Also update comments for Vendor_ramdisk_available.
Test: m nothing -j
Bug: 156098440
Change-Id: I2b776b6fd8f5a2c361c0f6a89231e3cebc2646f0
By making the Append and RemoveList methods return a new list instead
of modifying the existing list it makes the ConfiguredJarList usages
easier to reason about and safer to use, especially considering that
they are primarily used in global configuration.
Bug: 171479578
Test: m nothing
Change-Id: I102c4fb42f0c54e4ed299d2921fbf5efeb6e99b9
This is only used from within the ConfiguredJarList implementation and
provides no real benefit over directly accessing the apexes slices.
Similarly, uses of Jar(int) from within the implementation are also
replaced with direct slice access.
Bug: 171479578
Test: m nothing
Change-Id: I7e799b1049f4a1da4140e55831c4559751278de6
We have added a lot of metalava invocations since the highmem
differentation was added, most of which do not use a lot of memory.
By collecting data of max rss per process we have narrowed down
the set of highmem modules to a smaller set, and will annotate the
relevant modules as such.
Bug: 170701554
Test: NINJA_HIGHMEM_NUM_JOBS=3 m checkapi (no long tail of metalava)
Change-Id: Ic9c8c91388b02889111ef596fc6fd8bde9b42b9d
This amends Idad7ef138cdbcbd209d390bf6c10ca8365d4619f. With the change,
when there is a member that returns IsHostOsDependent() == true,
the sdk having the member and the member itself are disable for host and
only the os that the member supports is explicitly enabled.
However, that change will cause a problem when we add the support for
the linux_bionic_arm64 target. The target is not enabled when building
sdk snapshots. The only linux_bionic target that is enabled is
'linux_bionic_x86_64'. However, since the granularity is os which is
linux_bionic, the snapshot is generated as follows.
cc_prebuilt_binary {
target: {
host: {
enabled: false,
},
linux_bionic: {
enabled: true,
},
linux_bionic_x86_64: {
srcs: ["x86_64/bin/..."],
},
// no srcs for linux_bionic_arm64
},
}
Above is a problem for linux_bionic_arm64 target because the target is
enabled (via linux_bionic.enabled: true), but srcs is not provided.
To fix the problem, the enabling of a target is done in a target
(os_arch) granularity, rather than os granularity. For example, above
now becomes ...
cc_prebuilt_binary {
target: {
host: {
enabled: false,
},
linux_bionic_x86_64: {
enabled: true,
srcs: ["x86_64/bin/..."],
},
},
}
Only the targets that the snapshot actually can provide srcs are enabled
and the rest of the host targets are disabled.
Bug: 159685774
Test: m nothing
Test: build/soong/scripts/build-aml-prebuilts.sh
runtime-module-host-exports
Change-Id: Ibca48c40f6dc4628b5f4bfa4ceb68ebe0973cc81
If an android_library has a proguard flag file, that
file should also be used when compiling apps with the
library.
Fixes: 171425221
Test: New unit test in app_test.go, and manually
Install to recovery/root/first_stage_ramdisk if
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT,
otherwise vendor-ramdisk. In addition, append /system
if not InstallInRoot().
On devices with dedicated recovery partition,
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT is not set,
and this installs to the correct place (under $OUT/vendor-ramdisk).
On devices without a dedicated recovery partition:
- To install a module available before switching root
to /first_stage_ramdisk, e.g. a binary under /system/bin,
use recovery{_available} and install the recovery variant
of the module.
- To install a module available after switching root
to /first_stage_ramdisk, e.g. a binary under
/first_stage_ramdisk/system/bin,
use vendor_ramdisk{_available} and install the vendor_ramdisk
variant of the module.
Test: pass
Bug: 156098440
Change-Id: I1af3f8889891a3e58263cda36f0680ce2b480499
Add vendor_ramdisk_available and vendor_ramdisk attribute to
various rules. When a vendor_ramdisk variant of a module is
generated, it is installed to $OUT/vendor-ramdisk.
It is similar to a ramdisk image.
Test: m nothing -j
Change-Id: Ib2d16459f3094dbe21c3bdb7c016cb4b2bf62765
This change introduces the concept of partition dir for InstallPaths.
It's the path to the partition where the InstallPath is rooted at. For
example, it's out/soong/target/product/<device>/<partitoon> for paths
created for device modules. For host modules, it is defined as
out/soong/host/<host_os>-<host_arch>.
The partition dir is obtained using the new PartitionDir() function.
Another change is that a freshly created InstallPath (usually via
PathForModuleInstall) is the result of joining PartitionDir() and the
remaining path elements. For example, PathForModuleInstall(ctx, "foo",
"bar").Rel() now returns "foo/bar". Previously, that call returned the
relative path from config.buildDir() ("out/soong"). This change is in
line with the behavior of other path-creating functions like
PathForModuleSrc where Rel() returns the path relative to the
contextually determined path like the module source directory.
Notice that the Join() call to InstallPath doesn't change
PartitionDir(), while does change the result of Rel().
p := PathForModuleInstall(ctx, "foo", "bar")
p.PartitionDir() is out/soong/host/linux-x86
p.Rel() is foo/bar
q := p.Join(ctx, "baz")
q.PartitionDir() is still out/soong/host/linux-x86
q.Rel() now returns baz
Bug: N/A
Test: m nothing
Change-Id: I916bb1c782a4bfe0fbd4854e349cd2a2a42f56b6
It needs to be in the list since it is needed by codec2_vndk.
It will eventually replace libion(also in the list).
Test: m
Bug: 168333162
Change-Id: If11d7e845bd4704f34f84435b5cac32b614312a8
This error tracks `apex_available` closure, but the message doesn't
indicate this variable specifically. Calling it out to try to make
the problem more searchable/discoverable/intuitable.
Bug: N/A
Test: apex_test.go
Change-Id: Ib254ace1dbd4e77d073ed4f98ee181dd86adfcfc
Prepare for making the relationship between an llndk_library stubs
module and the cc_library implementation module explicit by
adding an llndk_stubs property. Each cc_library will be updated
to point to its llndk_library, and the llndk_library name will
be changed to make the .llndk suffix explicit. Then the implicit
connection and suffix can be removed.
Bug: 170784825
Test: m checkbuild
Change-Id: I6b0482a3f286ec29b2e928551aa4317749f2b499
