Compared to full list, flat list drops dependency edges and simply
lists all transitive dependencies for a top-level apex bundle.
Bug: 149622332
Test: m, manually build flatlist
Change-Id: Ibd521c96b7aeab90b95965c1b524e0a0152aaf5a
Move depsInfo into android for easier sharing with APK code.
Bug: 149622332
Test: m, diff'ing outputs for conscrypt module.
Change-Id: If0ee967d37425540e69b4ce9304229d9f2cd86bd
Previously, errors that were found when splitting visibility rules were
only reported in the check phase and simply ignored during the gather
phase. That was because every visibility property that was processed in
the gather phase had already been checked in the check phase. However,
that is not strictly true as it has always been possible to add a
mutator between the check and gather phases that creates a module with
invalid visibility properties that will just be ignored. Fortunately,
that has not happened.
A follow up commit will add the capability to create modules after the
defaults have been applied which means the chances of invalid visibility
properties being ignored will increase.
This change makes both phases report any errors they find. It will not
have any impact on existing code as if any errors are reported in the
check phase then the build will exit before the gather phase. It will
prevent any invalid visibility errors from being ignored.
Bug: 155295806
Test: m nothing
Change-Id: I101fa6b03d2530b16e4394a9e466fead48be0ff0
Adds a couple of new methods to manage visibility property instances to
reduce duplication and encapsulate the implementation slightly better.
The AddVisibilityProperty method is exported as it will be needed by
other packages in follow up commits.
Bug: 155295806
Test: m nothing
Change-Id: Ic1a9bb1e151fc6ae65761344fd210b4e4ba74fbc
The first component is the apex name, or a special name "platform"
if the boot jar is a platform jar rather than a part of some apex.
This is a prerequisite change for moving core-icu4j to a separate
com.android.i18n apex.
Old one-column format is still supported, but all unqualified
components of PRODUCT_BOOT_JARS get "platform:" prepended to them
after reading the product makefiles.
Test: aosp_walleye-userdebug boots
Bug: 138994281
Change-Id: Ic229159fdcdaf6182210a53b63850a389dd786fc
This change adds 'test_for' property to cc_test_* types. The property is
used to mark a module as a test for one or more APEXes, in which case
the module has accecss to the private part of the listed APEXes. For
example, the module is linked with the actrual shared library in the
APEX instead of the stub of the shared library.
Exempt-From-Owner-Approval: already +2'ed by owner
Bug: 129539670
Bug: 153046163
Test: m
Change-Id: I45ed0d7a15540b0d69b2a3b8d9c4cb202adff6f2
A module is marked unavailable for platform when 1) it does not have
"//apex_available:platform" in its apex_available property, or 2)
it depends on another module that is unavailable for platform.
In that case, LOCAL_NOT_AVAILABLE_FOR_PLATFORM is set to true for the
module in the Make world. Later, that flag is used to ensure that there
is no module with the flag is installed to the device.
The reason why this isn't entirely done in Soong is because Soong
doesn't know if a module will be installed to the device or not. To
explain this, let's have an example.
cc_test { name: "mytest", static_libs: ["libfoo"]}
cc_library_static { name: "libfoo", static_libs: ["libbar"]}
cc_library { name: "libbar", apex_available: ["com.android.xxx"]}
Here, libbar is not available for platform, but is used by libfoo which
is available for platform (apex_available defaults to
"//apex_available:platform"). libfoo is again depended on by mytest
which again is available for platform. The use of libbar should be
allowed in the context of test; we don't want to make libbar available
to platform just for the dependency from test because it will allow
non-test uses of the library as well.
Soong by itself can't tell whether libfoo and libbar are used only in the
context of a test. There could be another module depending them, e.g.,
cc_library_shared { name: "mylib", static_libs: ["libfoo"] }
can exist and it might be installed to the device, in which case
we really should trigger an error.
Since Make has the knowledge of what's installed and what's not,
the check should be done there.
Bug: 153073816
Test: m
Test: remove "//apex_available:platform" from libmdnssd (it is currently
installed to /system/lib), and check that `m system_image` fails
Change-Id: Ia304cc5f41f173229e8a154e90cea4dce46dcebe
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
Change-Id: I2d4c54fb397e29dc9b3203be7fb17be4536529f7
This exposes test func on ValueMatcher and helpers relevant for testing neverallows.
Bug: 153333044
Test: m
Change-Id: Ied07cd33afa537f9d7aa3c33e59f4ac985901a0f
It has been wrong to split ALL_VERSIONS into exclusive two sets of
before/after TARGET_PLATFORM_VERSION.
And PLATFORM_VERSION_ALL_CODENAMES supports all *active* list of
non-finalized codenames.
Bug: 152960049
Test: m
Exempt-From-Owner-Approval: cp from master
Merged-In: I78ca88758998e440bea72ba2d56d90eea3ec99ae
Change-Id: I78ca88758998e440bea72ba2d56d90eea3ec99ae
(cherry picked from commit 424175d72a)
Allow the platform stubs to specify sdk_version: none,
and add generic support for a regexp matcher.
Bug: 144149403
Test: m
Change-Id: Icaece0d9797bace8ae9741f7a029b9ea57fcbbb9
Apex can use codenames like "Q", "R" for its min_sdk_version property.
Also, cc_library can use codenames for its stubs.versions.
Bug: 152655956
Test: m
Merged-In: I077ad7b2ac5d90b4c8708921e43846206f05ba70
Change-Id: I077ad7b2ac5d90b4c8708921e43846206f05ba70
(cherry picked from commit 29e91d2121)
When a source and a prebuilt module are present in the same build a
dependency is added from the source module to the prebuilt module.
Previously, the code for generating the APEX did not recognize that
tag and in some cases (e.g. for cc_(prebuilt_)library_shared) will
fail the build.
This change:
1) Adds a test to reproduce the problem.
2) Improves the debug message by pretty printing the tag.
3) Adds a new ExcludeFromApexContents interface that can be implemented
by a tag to declare that it should be excluded from the APEX
contents.
4) Ignores tags that implement that interface when generating APEX
contents.
5) Implements that interface on prebuiltDependencyTag to fix the
test.
Bug: 153326844
Test: m nothing
Change-Id: I9dd4312c4f995c816c0a31d8d733eb5d7f56e1ea
Having dependency tags in the dependency path that shows why a specific
module is considered part of an apex makes it easier to understand why
that is the case and detect possible issues.
Bug: 152762638
Test: m nothing
Change-Id: Iba2a8a5a6abe03dadee456e760aa4373cd00c07b
This is to guard against the potential situation when someone adds
updatable modules to the list of boot jars by mistake.
Test: aosp_walleye-userdebug builds.
Test: Manually break the checks and observe the errors:
- move updatable module 'conscrypt' from
PRODUCT_UPDATABLE_BOOT_JARS to ART_APEX_JARS:
internal error: module 'conscrypt' from updatable apex 'com.android.conscrypt' is not allowed in the ART boot image
- add updatable module 'conscrypt' to ART_APEX_JARS
(but do not remove it from PRODUCT_UPDATABLE_BOOT_JARS):
error: A jar in PRODUCT_UPDATABLE_BOOT_JARS must not be in PRODUCT_BOOT_JARS, but conscrypt is.
- move updatable module 'framework-tethering' from
PRODUCT_UPDATABLE_BOOT_JARS to PRODUCT_BOOT_JARS:
internal error: module 'framework-tethering' from updatable apex 'com.android.tethering' is not allowed in the framework boot image
- add non-updatable (in AOSP) module 'android.net.ipsec.ike'
to PRODUCT_BOOT_JARS:
internal error: failed to find a dex jar path for module 'com.android.ipsec.ike', note that some jars may be filtered out by module constraints
Bug: 147579140
Change-Id: I25ca2f52530fcfa1f9823b2cfa3485db9c0d0db1
The DepIsInSameApex() and RequiredSdks() methods were defined in a few
places to avoid having to depend on the whole ApexModule/SdkAware
interfaces directly. However, that has a couple of issues:
1) It duplicates functionality making it difficult to change, changes
to the definitions outside the main interfaces do not cause compile
time failures, instead they result in a runtime change in behavior
which can be difficult to debug.
2) IDE navigation (specifically in Intellij) does not detect that the
duplicate definitions can resolve to the definitions in the main
interface.
This change extracts the methods into their own interfaces and reuses
those interfaces instead of duplicating the methods to fix both of
these issues.
Bug: 152878661
Test: m nothing
Change-Id: I0cfdf342a14eb0bfb82b1bd17e0633d81c7facfb
Revert submission 1242911-sdk_version_variant
Reason for revert: b/153394225
Reverted Changes:
Ife99745fb:Use libnativewindow for platform variant of libagq...
I1bae84c43:Use libnativewindow for platform variant of androi...
I6e6021ed3:Use stl to depend on libc++
Ife99745fb:Use libnativewindow for platform variant of libRSS...
I2c9f439b9:Fix static dependency on libprotobuf-cpp-lite-ndk
Iff2aff9cf:Set sdk_version for cc_genrules used by modules wi...
I7d72934aa:Add sdk mutator for native modules
Ief378a007:Use sdk variant of Soong modules when LOCAL_SDK_VE...
Bug: 149591340
Change-Id: I798fa902c779469c6382b6699351e5d12bf14785
Fixes: 153394225
blueprint.writeAllModuleActions attemts to sort modules by name, and
sorting them assumes that each module's name is unique. Although
soong_config_module_type_import modules will not generate anything,
their names should be unique, too for that reason.
Fixes: 150421585
Test: m nothing
Change-Id: I6782e42c129dc3b0fc7649ce97d5f94effc63fa7
Previously, when Q-targeting apexes are bundled-built, they are built
against the latest stubs.
It was because unwinder is linked dynamically in R and APIs are provided
by libc while Q apexes should run on Q where libc doesn't provide those
APIs. To make Q apexes run on Q device, libc++ should be linked with
static unwinder. But, because libc++ with static unwinder may cause problem
on HWASAN build, Q apexes were built against the latest stubs for bundled
build.
However, Q apexes should be built against Q stubs.
Now, only for HWASAN builds, Q apexes are built against the latest stubs
(and native modules are not linked with static unwinder).
Bug: 151912436
Test: TARGET_SANITIZE=hwaddress m
=> Q apexes(media, resolv, ..) are linked with the latest stubs
m
=> Q apexes are linked with Q stubs,
and Q apexes' libc++ is linked with static unwinder
Merged-In: If32f1b547e6d93e3955c7521eec8aef5851f908c
Change-Id: If32f1b547e6d93e3955c7521eec8aef5851f908c
(cherry picked from commit 7406660685)
Exempt-From-Owner-Approval: cp from internal
Change-Id: If32f1b547e6d93e3955c7521eec8aef5851f908c
Compiling native modules against the NDK disables platform features
like ASAN. For anything shipped on the system image there is no
reason to compile against the NDK. Add a new mutator to Soong that
creates a platform and an SDK variant for modules that set
sdk_version, and ignore sdk_version for the platform variant. The
SDK variant will be used for embedding in APKs that may be installed
on older platforms. Apexes use their own variants that enforce
backwards compatibility.
Test: sdk_test.go
Test: TestJNIPackaging
Bug: 149591340
Change-Id: I7d72934aaee2e1326cc0ba5f29f51f14feec4521
