This change adds support for dexpreopting standalone system server
jars from prebuilts.
Bug: 203198541
Test: -
1. Add a standalone system server jar (e.g., by patching
aosp/1906158)
2. Build and drop a module SDK and an APEX.
3. Build a system image from prebuilts.
4. See the odex and vdex files generated in
$ANDROID_PRODUCT_OUT/system/framework/oat/
Change-Id: I8f4eaed10a1053cd560b8583efa12dc495f58db1
The property is used to customize uid/gid/mode/capabilities of files in
an APEX.
Bug: 209971551
Test: m
Change-Id: I484e46ff819a5266c1e8046dae337e18ef3fefea
... in preparation for adding the support for custom canned fs config
Bug: 209971551
Test: m nothing
Change-Id: I7f2576ff99c65bdb6c9ce4ace61bc783eea2f0d4
App compact impact is hard to judge (see http://b/124106384#comment9
ff), so this tries it early in the dessert cycle.
This is also a workaround for b/209867137 where the symlink install
rules interact badly with the artifact_path_requirements.mk check.
Test: m installclean && m droid
verify that $(PRODUCT_DIR)/system/bin doesn't have dalvikvm and
dex2oat symlinks
Bug: 124106384
Bug: 209867137
Change-Id: I044fb40f656beeb7c6e61f1d418fa13f56714a70
Each conversion required defining a separate mutator, which will each
operate on _all_ modules and requires each to repeat checks whether the
mutator should operator. Instead, we introduce a single mutator and
modules can define a ConvertWithBp2build to implement bp2build
conversion for that module.
Test: bp2build.sh
Bug: 183079158
Change-Id: I99d4b51f441c2903879092c5b56313d606d4338d
The ART AOT exemption only applies to Q/R/S, so module jars that have
min_sdk T+ do not need to follow the module package restriction, even if
they are part of a Q/R/S module (but not loaded on Q/R/S).
Relax the restriction to only apply to jars that have min_sdk before T.
Bug: 208773835
Test: m (runs apex tests)
Change-Id: I2c3ad8984ca05ad763bf6162bd478f93ab4ee650
apex_set modules failed to set prebuiltCommon.installedFile, which
caused LOCAL_SOONG_INSTALLED_MODULE to be empty and base_rules.mk
to create a duplicate install rule. Set it to the path to the
apex file installed by Soong.
Bug: 204136549
Bug: 209867137
Test: m SOONG_CONFIG_art_module_source_build=false
Change-Id: Ia7fec09598823343242ebd44f1732e6bba21d027
Soong has enough information to build the license metadata files
without resorting to the fixups required in Make.
Bug: 207445310
Test: m checkbuild
Change-Id: I8e74108376162b8fdb87ba098ebe94350aa1f7c4
Inidividual boot or system server jars may have higher min_sdk_version
than the contianing apex, since the runtime respects the values of
min/max_sdk_version; e.g. runtime would not load a boot jar with
higher min_sdk_version. This allows shipping new boot jars via apexes
that target older platforms.
Bug: 190818041
Test: presubmit
Change-Id: I08ec0b4463a17bc8265b948fe09da55eb4e52ac3
apex.binaries accepts a list of module names, which should be resolved to
their fully qualified labels. Bazel treats string_list and label_list
attributes differently, most notably with the latter adding dependency edges.
Test: apex_conversion_test.go
Bug: 209743852
Change-Id: Iafdc5c728e8658cce0e99d42f32e7bb6fe2f3168
This is configured from Make by setting up Darwin+Arm64 as a HOST_CROSS
target (which is largely true, as binaries can't be executed on X86_64
machines). On the Soong side, it's a bit blurier, as we don't current
have any other users that are the same OS but not natively executable
(Linux/musl is executable, Windows/x86 is a different OS).
Instead of requiring cc_binary/etc to become multi-architecture-aware
and using something like common_first/MultiTarget, this defaults all
non-multi-architecture-aware modules to be built with both
architectures. It then adds a dependency with the
DarwinUniversalVariantTag so that supporting modules can get the outputs
of the other variant.
Cc uses that dependency tag to run lipo on shared libraries and binaries
so that the output of the x86_64 variant is actually a fat binary
including both architectures.
Bug: 203607969
Test: build sdk-repo targets on a Mac
Change-Id: Icbddb0a177c0ba19d3e0d11f8cf568e0d1ea3245
Without these errors, the last encountered deapexer would silently be
used. However with PRODUCT_INSTALL_APEXES there will only be deapexer
for installable APEXes, and we can assume only a single installable
APEX exists for each APEX variant, so make it an error if it isn't the
case.
Corresponding to http://ag/15156931.
Test: m nothing SOONG_CONFIG_art_module_source_build=true
Test: m nothing SOONG_CONFIG_art_module_source_build=false
Test: m nothing SOONG_CONFIG_art_module_source_build=false
with installable:true for the com.android.art.debug prebuilt APEX -
check that it fails with an "ambiguous duplicate deapexer" error
Bug: 192006406
Bug: 192542393
Change-Id: I44566fd26b12f82a8a67fe4a69e56303460756d0
This is to help following refactor for individual modules to have their
own version of checking where needed.
For example, apk in apex may want to enforce it's own version of
CheckMinSdkVersion.
Bug: 205923322
Test: presubmit
Change-Id: Ia2fad6c52af39e21f65385bcb283f1e3adab5548
The new property is used to mimic some of the build behaviors that
currently are applied only when an APEX is `updatable: true`. This
property is helpful to minimize the sudden impact (e.g. change in size)
when an APEX becomes updatable.
Currently, the behavior that this property mimics is the disabling of
the size optimization.
Bug: 207336449
Test: m
Change-Id: I500306afa1221625fda3e89a8d12d5d341791a1f
We will need the profile when we generate the primary boot image on
device.
Bug: 203492478
Test: Run `banchan com.android.art x86_64 && m` and see
`$ANDROID_PRODUCT_OUT/apex/com.android.art/etc/boot-image.prof`.
Test: Run `lunch aosp_cf_x86_64_phone-userdebug && m` and see both
`$ANDROID_PRODUCT_OUT/apex/com.android.art/etc/boot-image.prof` and
`$ANDROID_PRODUCT_OUT/system/etc/boot-image.prof`, in different
sizes.
Test: Start Cuttlefish with the built image and see both
`/apex/com.android.art/etc/boot-image.prof` and
`/system/etc/boot-image.prof` on device.
Change-Id: Id879dc49b234133dfbb9563814328661a1f4a6c0
Vendor APEXes do not formally support updates outside of the main OTA
process. We should clarify this at build time.
Test: set vendor apex to updatable, observe failure
Test: apex_test.go
Change-Id: Ife8d242a42415ebf00d7dced72c07cda1fde1839
Previously, could not set an empty string as a value of an attribute;
however, this is necessary in some cases. To not unnecessarily create an
empty string, use string pointers for attributes rather than strings.
Test: go test bp2build tests
Change-Id: I03b3a3567452d455246d22d81f86c317d06b7c39
This CL updates platform_systemserverclasspath,
systemserverclasspath_fragment, and
prebuilt_systemserverclasspath_fragment to write entries for
STANDALONE_SYSTEMSERVER_JARS to systemserverclasspath.pb. A new property
`standalone_contents` is aded to `systemserverclasspath_fragment` and
`prebuilt_systemserverclasspath_fragment` to list the standalone system
server jars in the APEX, and entries will be written to
systemserverclasspath.pb accordingly at build time.
To add more context, these entries will be consumed by derive_classpath
in order to generate an environment variable
PRODUCT_STANDALONE_SYSTEM_SERVER_JARS. The environment variable will
then be comsumed by odrefresh to determine what jars to preopt on early
boot.
Note that the variable should not end with "CLASSPATH" because the list
is not used by runtime as a classpath. It is just a colon-separated list
of jars. System server loads the jars separately with paths hardcoded in
the code.
Bug: 203198541
Test: manual -
1. Add some jars to PRODUCT_STANDALONE_SYSTEM_SERVER_JARS
2. Add some other jars to PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS
and standalone_contents.
3. Build an image.
4. Flash the image to a device.
5. adb shell echo \$STANDALONE_SYSTEMSERVER_JARS
6. See the correct list of jars.
Change-Id: I09a6fd1d3db85c194330da9b751702a9bf069e26
The sh_binary module is not supported the vendor variant. So, even if
there is "vendor: true" in sh_binary module, the image variant is
"image:" instead of "image:vendor.Tiramisu".
But the vendor APEX has vendor variant, so vendor APEX module and
sh_binary module have different variants and the sh_binary cannot be
added to vendor apex.
So the Sh_binaries property is added, and the image variant is removed
at DepsMutator.
Bug: 205065320
Test: make -j40 && sh_binary is added to vendor APEX && install check
Change-Id: I30e2d96a73b45e7b06eff24550542cb010008c41
Perform consistency checks as per http://go/updatable-shared-libraries
These include:
* no attribute can specified can be less than T
* max-device-sdk can't be less than min-device-sdk
* min and max-device-sdk need to be at least the module's
min_sdk_version
* using on-bootclasspath-before implies that the module's
min_sdk_version is at least T or the library has min-device-sdk of at
least T
Test: m nothing
Bug: 191978330
Change-Id: Iaca5cf23fb0bc7e65effb3529c8e829560894c2e
Merged-In: Iaca5cf23fb0bc7e65effb3529c8e829560894c2e
(cherry picked from commit f9e584dd20)
We are expanding PackageManager's supported attributes and this change
enables the developer to define them in the .bp file.
Test: m nothing
Bug: 191978330
Change-Id: I01d579190fb585662086a7fc456f3b33cb89fb57
Merged-In: I01d579190fb585662086a7fc456f3b33cb89fb57
(cherry picked from commit 826863c8e0)
As libsync is NDK/LLNDK, it doesn't need to be aded to allowlist as
apex_available.
Bug: n/a
Test: m
Change-Id: I16cfb258a24bde4def428f1e6277f5d3c95c228c
Move apex module installation rules into Soong by overriding
InstallBypassMake.
Soong installs don't support post install commands, so move the
symlinks into separate rules and add dependencies on them.
This relands If65d283abc86f18ad266da0bf16fe95971a0bf9c with fixes
to install files into $OUT/apex and I606286e971b55d9d1fc4dcd0fbd476962de5fa79
with a fix for reversed logic.
Bug: 204136549
Test: m checkbuild
Change-Id: Ie65c53ebc7911efacdb8e11ba49059448f03c658
Extract and install the primary apk normally, and then unzip the rest
of them as a post install command.
Bug: 204136549
Test: app_set_test.go
Change-Id: I17437ff27f49df6bc91bdbbea6173b46c7d3ec4e
Revert submission 1869814-vapex-multi-config
Bug: 206551398
Reason for revert: DroidMonitor-triggered revert due to breakage https://android-build.googleplex.com/builds/tests/view?invocationId=I55600009996329947&testResultId=TR93527797572038984, bug b/206551398
Reverted Changes:
I0cd9d748d:Adds multi_install_skip_symbol_files field (defaul...
I5912a18e3:Demonstrate multi-installed APEXes.
I0e6881e3a:Load persist props before starting apexd.
I932442ade:Adds a new prop context for choosing between multi...
I754ecc3f7:Allow users to choose between multi-installed vend...
Change-Id: If09bf590e3ad93e14fbf89299f80d497c9604a78
Add scripts to generate java APIs used by Mainline modules. This is
aosp/1879177 with fixed build error that caused by dexdeps analyzing
resource only APKs which doesn't contains any .dex files. Now skip the
error generates in that case in gen_java_usedby_apex.sh
Forrest run:https://android-build.googleplex.com/builds/abtd/run/L38900000951898586
Test: TARGET_BUILD_APPS=com.android.adbd m dist apps_only
Change-Id: Id539cbe1b7306ace69c047f95ffc02265a467511
Multi-installed APEXes share the same apex_name and are installed
at the same time.
Should be set to true for all multi-installed APEXes except the singular
default version within the multi-installed group.
Only the default version can install symbol files in $(PRODUCT_OUT}/apex,
or else conflicting build rules may be created.
Bug: 199290365
Test: see https://r.android.com/1872018
Change-Id: I0cd9d748d7be3a2de40ed14f13bad71912457ddc
Move apex module installation rules into Soong by overriding
InstallBypassMake.
Soong installs don't support post install commands, so move the
symlinks into separate rules and add dependencies on them.
Bug: 204136549
Test: m checkbuild
Change-Id: If65d283abc86f18ad266da0bf16fe95971a0bf9c
* changes:
Rename amod variable in AndroidMkEntries.fillInEntries to base
Make HostToolPath, HostJNIToolPath and sboxPathForToolRel use pathForInstall
Add PathForGoBinary
Remove PathForOutput from InstallPathToOnDevicePath
Use pathForInstall instead of PathForOutput for HostToolPath,
HostJNIToolPath and sboxPathForToolRel so that they internally produce
an InstallPath that can later support being converted to Make install
path.
Bug: 204136549
Test: m checkbuild
Change-Id: Ie16a62641d113873daeec4d1dd4261251bc0d0eb
Add PathForGoBinary that uses pathForInstall to return the install
path of a GoBinaryTool. This will replace various places that used
PathForOutput to reconstruct a path to a Go tool, and will support
moving Go tools to the Make install directory outside of the
PathForOutput directory in a future patch.
Bug: 204136549
Test: m checkbuild
Change-Id: I83a3be9f5c621975540f5ed601a0b9e2611c98b9
This CL fixes a bug that `required` property of apex modules is not
reflected to the generated Android.mk file.
Bug: N/A
Test: m nothing
Change-Id: I36ccf538882f083f9433bd3eb05b3a5127f3822b
A new property indicates a CLI tool to sign the APEX contents. The value
is stored in apexkeys.txt so that releasetool (sign_target_files_apks)
can use it to invoke the tool to re-sign the apex contents.
Bug: 193504286
Test: m out/soong/apexkeys.txt
com.android.virt.apex line has sign_tool value
Change-Id: Ifd472049b75b5b87c1ed320f5e1190ff65ed54f2
Since coverage support was added to bootclasspath_fragment in
https://r.android.com/1684807 and bootclasspath_fragments were
integrated into the ART APEX it is no longer necessary to treat ART
APEXes differently to other APEXes.
Change https://r.android.com/1684807 added coverage support, follow
up changes integrated
Bug: 177892522
Test: m droid
m EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true
Change-Id: I4800a003c7459c4686607e16f4c5bde0be105f16
This WalkDeps loop was expecting the dependencies to be fully filled
out, which isn't necessarily true on AllowMissingDependencies builds,
especially on Mac when the modules may exist, but not be enabled.
This was triggered when make_erofs was added to an apex, but wasn't
enabled on Mac.
It shouldn't be a problem to skip the disabled dependencies, since we'll
have already marked the current module as missing dependencies, which
means it won't actually get built.
Test: `m nothing` on a mac
Change-Id: Icd6d597117be4cde5bff041be3fd47361c54cad9
This CL adds more tests to ensure that dexpreopted files are generated
and APEXes depends on them.
Bug: 201371822
Test: m nothing
Change-Id: I407ad54c55cbca9ef78bbd335e95d4b765e174a0
A prebuilt_apex/apex_set module can make a dex implementation jar
available for use by Make targets but it does not have access to a real
classes implementation jar; the jar in the corresponding sdk is just an
empty file. Exporting that invalid file to Make means that the phony
target created for the module depends on an invalid classes jar which
causes the build to fail.
This change removes the logic that make classes and header jars
available to Make so that building the phony target no longer fails.
Bug: 202521005
Test: m TARGET_PRODUCT=armv8 TARGET_PRODUCT_VARIANT=eng TARGET_BUILD_UNBUNDLED=true SOONG_ALLOW_MISSING_DEPENDENCIES=true core-icu4j
- above was performed in master-art.
Change-Id: If667b36b988e2d331acd85f60f3369778838d034
Previous change that was reverted: https://r.android.com/1835222
An additional test was added that revealed a bug in the previous change
which has been fixed here.
Previously, the behavior of the stub_flags and all_flags properties
was different between S and T. In S they contained paths for the
complete set of stub flags and all the encoded flags. However, in T
they contained filtered sets of flags which if used in S would prevent
build checks from detecting possible inconsistencies. Also, a new
signature_patterns property was added in T that is not supported in S.
This change creates separate properties/files for T and reverts the
behavior of the properties/files that were added in S back to how they
behaved in S. The new properties are called filtered_stub_flags and
filtered_flags.
The S and T properties are tagged with the appropriate
supported_build_releases tag to ensure that they are only output when
specifically targeted.
Bug: 197842263
Test: m nothing
Change-Id: I1ce0a3d6623dabf73e32af1a7457b9b444fc3b7c
Variable PRODUCT_UPDATABLE_SYSTEM_SERVER_JARS was renamed to
PRODUCT_APEX_SYSTEM_SERVER_JARS in https://r.android.com/1779472.
Bug: 191127295
Test: m nothing
Change-Id: I0c8ae839cab443c824760b40d30b4374982010f9
Introduce `commonAttributes` & `fillCommonBp2BuildModuleAttrs used in
CreateBazelTargetModule
Adapt `bp2BuildInfo` to use `commonAttrs` instead of `Name`.
And thus also all downstream users of `CreateBazelTargetModule`.
As initial user, the Soong `required` property will be
translated to Bazel's `data`.
Bug: 198146582, 196091467
Test: build_converstion_test.go:TestCommonBp2BuildModuleAttrs
Test: go test
Test: mixed_{libc,droid}.sh
Change-Id: Ib500e40f7e2cb48c459f1ebe3188962fc41ec124
Previously, the behavior of the stub_flags and all_flags properties
was different between S and T. In S they contained paths for the
complete set of stub flags and all the encoded flags. However, in T
they contained filtered sets of flags which if used in S would prevent
build checks from detecting possible inconsistencies. Also, a new
signature_patterns property was added in T that is not supported in S.
This change creates separate properties/files for T and reverts the
behavior of the properties/files that were added in S back to how they
behaved in S. The new properties are called filtered_stub_flags and
filtered_flags.
The S and T properties are tagged with the appropriate
supported_build_releases tag to ensure that they are only output when
specifically targeted.
Bug: 197842263
Test: m nothing
Change-Id: Iec8b9c539796c507245b69c0aed980fde6d8694f
* changes:
Generate prebuilt_systemserverclasspath_fragment.
Add a new SDK member type java_systemserver_libs.
Add exported_systemserverclasspath_fragments to prebuilt_apex rule.
Add prebuilt_systemserverclasspath_fragment rule.
