bpf program is put to an APEX via 'bpfs' property. It is
placed under etc/bpf directory in it.
Fix: 167530625
Test: m
Original change: https://android-review.googlesource.com/c/platform/build/soong/+/1418308
Merged-In: Ia36b486f0cffb619ecc4f7a318cde881abc5baf4
Change-Id: I42631beea4e668d86ba437d3e2edb392137706f0
(cherry picked from commit 05e47c0c5d)
The list contains an entry for the unstable interface (used in
development branches) and the SDK current interface (used in the module
branch on older module versions), but is missing an entry for the stable
interface, with minSdkVersion=29.
Bug: 166414751
Test: m
Change-Id: Ifd4a43321547256b8a738aca9133ec69e58133f9
prebuilt_apex has been disabled when the device is configured for
flattened APEXes, sanitized, instrumented, or built unbundled. However,
apex_set which is another type of APEX prebuilt wasn't disabled for the
same conditions.
This change fixes the discripency. apex_set modules are also force
disabled when the prebuilts are not expected.
Bug: 161316762
Bug: 160933444
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m
The built image has only the flattened APEXes and the device boots
Merged-In: I6c90dfb28d565861a473a1bdce93269ec370601d
(cherry picked from commit 10e926bc8d)
Change-Id: I6c90dfb28d565861a473a1bdce93269ec370601d
Pass a list of unstripped JNI libraries to Make so that they can be
installed into the symbols directory.
Bug: 159726429
Test: forrest
Change-Id: Ieb4bffbb3d0a09f476da011399c5b8b1611929d7
Merged-In: Ieb4bffbb3d0a09f476da011399c5b8b1611929d7
(cherry picked from commit 403cc15f1b)
Instead of tracking per module and per module variant, track allowed
list of dependecies for all modules combined. This avoids issues with
different products and different downstream branches having different
build graphs.
Bug: 149622332
Test: m (with different products)
Change-Id: Ic518fbd9ebfe1b46aaf9a58df731780a7e5a676b
Merged-In: Ic518fbd9ebfe1b46aaf9a58df731780a7e5a676b
(cherry picked from commit 019560ff02)
We put reproducible timestamps in zip files so that the artifacts
are consistent, but that leads to old timestamps in the output
directory if they are unzipped as part of the build. Use
unzip -DD when unzipping to update the timestamps.
Bug: 161015009
Test: touch -d 2020-01-01 ref; find $OUT/system -not -newer ref
Change-Id: I70407a627cb070e24be510faa6a774e3d9eae3a8
Merged-In: I70407a627cb070e24be510faa6a774e3d9eae3a8
(cherry picked from commit d783bbbace)
* changes:
Make native_coverage clause work with ClangCoverage
Introduce product variables to select Java code coverage paths in Soong.
Rename native code coverage paths product variables in Soong.
Make uses NATIVE_COVERAGE to enable gcov coverage and CLANG_COVERAGE
to enable clang coverage. NATIVE_COVERAGE is translated to the Soong
Native_coverage product variable which triggers the native_coverage
clause in Android.bp files. The clause also needs to be triggered
for CLANG_COVERAGE.
Rename the existing Native_coverage product variable to GcovCoverage,
and regenerate Native_coverage when either GcovCoverage or
ClangCoverage are set.
Also remove NativeLineCoverage, it wasn't doing anything differently
than Native_coverage.
Bug: 159059537
Test: m checkbuild
Merged-In: I215124a9b35a2ad50ad562079d392e3d33da11f4
Change-Id: I215124a9b35a2ad50ad562079d392e3d33da11f4
apex_set is a set of prebuilt apex files. To support GSI which installs
both flattened and unflattened APEXes when apex_set is used, we extract
the contents from the selected APEX file.
Bug: 159711661
Test: TARGET_PRODUCT=gsi_gms_arm64 m
should install flattened apexes in /system/system_ext/apex
Change-Id: I0a51b9f4a4537d3230aaa3eece532664ea18bc7c
Previously, when a boot jar was provided by a java_sdk_library_import
module the check-boot-jars check failed because the file it depended on
was not available. In an incremental build the build failed due to the
file in the out directory not having a rule to generate it.
That was because the module was named prebuilt_<module>.<apex> instead
of <module>.<apex>. This was fixed by simply removing prebuilt_ prefix
from the name if it was present.
After fixing that the check-boot-jars still did not work properly
because it was expecting a jar file containing .class files but instead
was given a jar file containing .dex files which meant the check did
not work properly.
This was fixed by defining a new ApexDependency interface for use by
the apex/apex.go code to use instead of java.Dependency for generating
the androidmk entries. The *SdkLibraryImport type then implemented
those, by delegating to the implementation library.
Bug: 158304459
Bug: 159112414
Test: m check-boot-jars
m checkbuild
manual inspection of the .jar file used by check-boot-jars to
ensure it contained .class files and not .dex files.
Change-Id: I545c5c9072dd472337d2f9b4dfdf08f53c981662
Merged-In: I545c5c9072dd472337d2f9b4dfdf08f53c981662
Because override_apex can modify the contents of the base apex,
allowed_files (which describes the contents) should be overridable.
Bug: 159503079
Bug: 159392784
Bug: 158169437
Test: m (soong test added)
Change-Id: I12744b0465dc3cfc90a66643867e65b4092cd0f7
Q+ and R+ mainline modules may only add code in a restricted set of Java
package prefixes, that may never be changed.
If a mainline module owns the Java package prefix "foo.bar", it may have
classes in "foo.bar", "foo.bar.baz", "foo.bar.baz.bat" etc.
Test: m
Bug: 156725734
Change-Id: I30bf510ed473309871469bf439d7c81575450931
Previously, when there is apex_set that is overriding another module,
the entry for the overridden module is removed from apexkeys.txt.
However, this is wrong because the existence of the apex_set module
doesn't necessary mean that the module is insatalled instead of the
overridden module. That is determined by PRODUCT_PACKAGES which Soong
has no knowledge of. Therefore, we don't delete the entry for the
overridden (actually possibly overridable) modules in the file.
Bug: 158729168
Test: m
Change-Id: I85d0c756f862323bae556bf657d66ec50038985f
apex_sets is a new module type that can be used to deliver pre-signed
APEXes, which previously could be done only via prebuilt_apex.
Soon gnow understands apex_sets module types and emits the signing info
of the modules to apexkeys.txt
Exempt-From-Owner-Approval: cherry-pic from AOSP
Bug: 158729168
Test: m
Merged-In: I9507375342ec053309660d94c931a79bf4f21218
(cherry picked from commit 8d6c51ebcc)
Change-Id: I9507375342ec053309660d94c931a79bf4f21218
If a java_sdk_library_import has a corresponding java_sdk_library then
make the java_sdk_library_import export both the xml and impl modules
created by the java_sdk_library.
Makes java_sdk_library_import consistent with java_sdk_library by
providing libraries within the same APEX access to the implementation
library instead of the stubs.
Bug: 158304459
Test: m nothing
Test what happens when building com.android.tethering with and without
a preferred "framework-tethering" java_sdk_library_import. Make sure that
it does not change the generated APEX.
Merged-In: I2f4edea937ac377431a5696c92cbd467bded62ef
Change-Id: I2f4edea937ac377431a5696c92cbd467bded62ef
(cherry picked from commit eedc5d55ce)
Ida6f7bb784efe74cc1fa0e8d370eaee803f08b0f made it possible to add
dex_import modules into apex, but that change had a bug. When creating
Android.mk for the dex_import module, the code executed an unchecked
type assertion to convert java.DexImport to java.Dependency, which
cannot be successful. This change fixes the bug by doing a checked type
assertion instead.
Exempt-From-Owner-Approval: cp from AOSP
Bug: 157886942
Test: m (test added)
Merged-In: Id22c20d42effce539fab10b0d349bf340d467f02
(cherry picked from commit 9e83f0b531)
Change-Id: Id22c20d42effce539fab10b0d349bf340d467f02
Give prebuilt_etc and sh_binary their own packages and split the
gigantic main Android.bp up to small, per-package ones.
(This is a cherry-pick change.)
Test: m nothing, TreeHugger
Bug: 156980228
Change-Id: I7b00cd344b9f16861f1ff39edf0029f016b853d0
Merged-In: I7b00cd344b9f16861f1ff39edf0029f016b853d0
apex now respects stem of java_library modules.
As a follow-up we need to suppor the same for other types of modules.
Exempt-From-Owner-Approval: cherry-pick from AOSP
Bug: 157638999
Test: m
Merged-In: Iaf5023020b5440f1ffd4f5414b5a7864655fc22a
(cherry picked from commit a62aa23990)
Change-Id: Iaf5023020b5440f1ffd4f5414b5a7864655fc22a
Introduce a singleton apex rule to merge contents of individual
deps-info results into a single output file.
Bug: 149622332
Test: m
Change-Id: I4ab7e1a3527fead97a81a5a2cb0e1e93a429117c
Merged-In: I4ab7e1a3527fead97a81a5a2cb0e1e93a429117c
Exempt-From-Owner-Approval: cp from aosp
(cherry picked from commit 849f844252)
For a given variant of a module that implements ApexModule interface,
the "updatable" property tests if this variant comes from an updatable
apex. For platform variants it is always false.
Test: lunch aosp_walleye-userdebug && m nothing
Bug: 138994281
Merged-In: I2d4c54fb397e29dc9b3203be7fb17be4536529f7
Change-Id: I2d4c54fb397e29dc9b3203be7fb17be4536529f7
Exempt-From-Owner-Approval: cp from aosp
(cherry picked from commit 7c140d828a)
Access to the implementation JARs is restricted to avoid code from
depending on implementation details that could change from one release
to the next which could cause compatibility issues. That is not a
problem when referenced from within the APEX that contains the
java_sdk_library.
As references from within the same APEX often need to access
implementation specific details of the java_sdk_library and doing that
from within the same APEX is safe this change all references to a
java_sdk_library made within the same APEX to use the implementation
jars instead of stub jars.
Bug: 155164730
Test: m droid
Change-Id: If239059690de61683c2ad2d8a0ce2e47286a3637
(cherry picked from commit 9b879594ed)
