The method is a thin wrapper around GetWalkPath and GetTagPath to make
it easy to construct a string representation of the current path.
It was originally inlined in the apex package. This change makes it a
function and moves it to the android package so make it more useful.
Bug: N/A
Test: m
Change-Id: I7e2bc2074baed759d67d9097151c9ac10e34ed31
Move depsInfo into android for easier sharing with APK code.
Bug: 149622332
Test: m, diff'ing outputs for conscrypt module.
Change-Id: If0ee967d37425540e69b4ce9304229d9f2cd86bd
Shared lib dependencies of a test is included in the APEX regardless of
whether the test has test_per_srcs or not.
Bug: N/A
Test: m (apex_test.go amended)
Change-Id: I6b16843cc7467c42e250aba88d79d5580ba47324
runtime_resource_overlay is put to an APEX via 'apps' property. It is
placed under ./overlay directory in it.
Bug: 154822536
Test: m
Change-Id: I8edf4a26c26368c52fb7b327b2ecc829f21ea148
Bug: 148447155
Test: built a testing apex with unsigned payload.
Merged-In: I95aa3f11ff1adc1421fcd7ed5a356ee531a0a818
Change-Id: I95aa3f11ff1adc1421fcd7ed5a356ee531a0a818
(cherry picked from commit 98410fd9d6)
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
The marked library(ies) were available to the APEXes via the
hand-written whitelist in build/soong/apex/apex.go. Trying to remove the
whitelist by adding apex_available property to the Android.bp of the
libraries.
Bug: 150999716
Test: m
Merged-In: I11a4e877ee27f7c55e2f00371c6fa58daedb1a9f
Change-Id: I11a4e877ee27f7c55e2f00371c6fa58daedb1a9f
apex_deps/apex/apex_flattened mutators don't have to run if module is
disabled.
For some branches which have no valid targets, apex modules are disabled
by the os mutator. e.g. aosp-build-tools
Some enforcement checks which run during those mutators may fail because
build-environment doesn't provide full context information.
For example, "Platform_version_all_codenames" config variable is not
set while apex.min_sdk_version uses one of those codenames.
Bug: 152655956
Test: m
Change-Id: I47e27d2d025ba4c36534708b113ce77c4cb2397b
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)
It is no longer needed because non-static java_library dependencies are
not considered to be part of the depending APEX.
Bug: 153443117
Test: m nothing
Change-Id: I7d58d1047b2d400395a253e492b35008284778ff
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
Previously, adding java_library to an sdk required that the names of
any APEXes that transitively compiled against it were added to its
apex_available property. This change removes that requirement.
Also corrects the dependency path in the TestApexAvailable_IndirectDep
error which previously passed through "shared from static" static
dependency tags even though those are explicitly NOT followed when
checking apex_available settings.
Bug: 152878661
Test: m droid
Change-Id: I995ed38956c1bc210b09494812de012fed9f9232
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
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
Delegate the responsibility for determining whether the
walkPayloadDeps() should visit a child dependency to its do function.
This is needed to allow the visitor in checkApexAvailability() to avoid
checking the apex_available setting after crossing the APEX boundary.
Bug: 152878661
Test: m droid
Change-Id: If46a2f74b6eca670befc3aeae430650e85542346
The apex available check can traverse quite a long path (5+ steps) to
get from the apex to a module that is missing the apex from its
apex_available property. Understanding where that dependency came from
can often require examining the dependency path which can be difficult.
This change adds the path to the error to simplify that process.
Test: m nothing
Bug: 152762638
Change-Id: Ic4eb169dc2026cd8339d49e23b25d6d1c3879750
Coverage build adds extra dependencies for the runtime libs. Marking
them and their transitive dependenciese with apex_available doesn't make
any value; it instead adds noise.
Bug: 150999716
Test: m
Change-Id: I08e51cec1de6ded624ef9d4c41c1e5b2e611ff38
The marked library(ies) were available to the adbd APEX via the
hand-written whitelist in build/soong/apex/apex.go. Trying to remove the
whitelist by adding apex_available property to the Android.bp of the
libraries.
Bug: 150999716
Test: m
Change-Id: I6afbe905dda11056559521b937803dcd85b32fe5
The marked library(ies) were available to the APEXes via the hand-written
whitelist in build/soong/apex/apex.go. Trying to remove the whitelist
by adding apex_available property to the Android.bp of the libraries.
Bug: 150999716
Test: m
Change-Id: I91d1b1076733a949ca2a959ba640ce34d0233492
The NDK prebuilts are implicitly used when building with sdk_version set.
Make the module types be available to any apex so that we don't need to
manually add apex_available property to the module definitions manually.
Bug: 150999716
Test: m
Change-Id: I0870afa4c74b4a06ab1273dff84615778561ecc9
Revert submission 1254009-vdex-symlinks
Reason for revert: This causing some devices to fail to boot. See b/151836042 for details.
Reverted Changes:
Iced89071b:Expect vdex files in a target-independent director...
Ifbceb8457:Share vdex files in the ART apex between architect...
Change-Id: I5bd88f8e61d442eed921d840c90777a2750ddb16
Test: aosp_walleye-userdebug boots.
Test: Check symlinks to *.vdex files in the ART apex:
$ adb shell 'find /apex/com.android.art -name '*.vdex' | xargs ls -l'
lrw-r--r-- 1 system system 23 1970-01-01 01:00 /apex/com.android.art/javalib/arm/boot-apache-xml.vdex -> ../boot-apache-xml.vdex
lrw-r--r-- 1 system system 25 1970-01-01 01:00 /apex/com.android.art/javalib/arm/boot-bouncycastle.vdex -> ../boot-bouncycastle.vdex
lrw-r--r-- 1 system system 23 1970-01-01 01:00 /apex/com.android.art/javalib/arm/boot-core-icu4j.vdex -> ../boot-core-icu4j.vdex
lrw-r--r-- 1 system system 24 1970-01-01 01:00 /apex/com.android.art/javalib/arm/boot-core-libart.vdex -> ../boot-core-libart.vdex
lrw-r--r-- 1 system system 19 1970-01-01 01:00 /apex/com.android.art/javalib/arm/boot-okhttp.vdex -> ../boot-okhttp.vdex
lrw-r--r-- 1 system system 12 1970-01-01 01:00 /apex/com.android.art/javalib/arm/boot.vdex -> ../boot.vdex
lrw-r--r-- 1 system system 23 1970-01-01 01:00 /apex/com.android.art/javalib/arm64/boot-apache-xml.vdex -> ../boot-apache-xml.vdex
lrw-r--r-- 1 system system 25 1970-01-01 01:00 /apex/com.android.art/javalib/arm64/boot-bouncycastle.vdex -> ../boot-bouncycastle.vdex
lrw-r--r-- 1 system system 23 1970-01-01 01:00 /apex/com.android.art/javalib/arm64/boot-core-icu4j.vdex -> ../boot-core-icu4j.vdex
lrw-r--r-- 1 system system 24 1970-01-01 01:00 /apex/com.android.art/javalib/arm64/boot-core-libart.vdex -> ../boot-core-libart.vdex
lrw-r--r-- 1 system system 19 1970-01-01 01:00 /apex/com.android.art/javalib/arm64/boot-okhttp.vdex -> ../boot-okhttp.vdex
lrw-r--r-- 1 system system 12 1970-01-01 01:00 /apex/com.android.art/javalib/arm64/boot.vdex -> ../boot.vdex
-rw-r--r-- 1 system system 1229 1970-01-01 01:00 /apex/com.android.art/javalib/boot-apache-xml.vdex
-rw-r--r-- 1 system system 2043 1970-01-01 01:00 /apex/com.android.art/javalib/boot-bouncycastle.vdex
-rw-r--r-- 1 system system 2883 1970-01-01 01:00 /apex/com.android.art/javalib/boot-core-icu4j.vdex
-rw-r--r-- 1 system system 865 1970-01-01 01:00 /apex/com.android.art/javalib/boot-core-libart.vdex
-rw-r--r-- 1 system system 395 1970-01-01 01:00 /apex/com.android.art/javalib/boot-okhttp.vdex
-rw-r--r-- 1 system system 7125 1970-01-01 01:00 /apex/com.android.art/javalib/boot.vdex
Bug: 150934453
Change-Id: Ifbceb845749f4c218693f4118e8b35b59ff26de1
libselinux no longer is included in any APEX. Only the platform variant
of it (/system/lib/libselinux.so) exists and APEXes link to it.
Removing the lib name from the whitelist to make it clear that the
library is not available to any APEX.
Bug: 151053366
Bug: 150999716
Test: m
Change-Id: Id4fb933141ad32ff5217a58f1c7d689cc657e9ea
Makes sure that the module snapshots do not rely on the white list
of apex available settings so that when those lists are removed it is
not necessary to update any snapshots.
Bug: 142935992
Test: m nothing
Change-Id: Iedcff7dfc2646a4da77258d16e06657dd2f411f9
Test apexes no longer check to see whether their contents are available
so the special handling is no longer necessary.
Bug: 142935992
Test: m nothing
Change-Id: Iecae7dcbb87908d19c672f74d3c1ed8810d4485b