The use of this field to return information from bootImageProfileRule
up the call stack to one of the users resulted in data races being
detected. This change simply returns the profile path back up the call
stack.
Bug: 245956352
Test: m nothing
go test -race ./sdk/... -run TestSnapshotWithBootclasspathFragment_ImageName -test.count 100
# Run the previous command without this change and sometimes it
# shows the data race around profilePathOnHost. With this change
# that data race is not reported. Although there is still another
# data race.
Change-Id: I03b09e514cc94f2a6c9d5117d3b2f130cc2e4f5b
Add warnings to the structs to explain how they are supposed to be used
and deprecate fields that are used incorrectly.
Bug: 245956352
Test: m nothing
Change-Id: I090698287b96fd37102b88beb5d7252977bddc54
Currently, tagging a symbol with #apex is not required when the symbol
is in a non-NDK library. However, this is considered dangerous because
such a symbol will automatically be promoted to NDK APIs when the
library is promoted to an NDK library. When that happens, the native API
council won't be able to notice the promotion because promoting a
non-NDK library into an NDK library doesn't require an update of the
map.txt file, but Android.bp only.
To prevent that, we should mandate #apex (or #systemapi if the api is
provided by the system, not apex) tag for Mainline APIs regardless of
whether the library the API belongs to is an NDK library or not.
Bug: 184712170
Test: m
Change-Id: Iad589b606bc6ed06ef1237f4c9f0c22518b0db75
By default, ndkstubgen does not omit NDK symbols as long as they
satisfy the API version and the CPU architecture requirements. This
change adds a new flag --no-ndk to ndkstubgen which is used to
override the default behavior. If the flag is set, NDK symbols are
omitted leaving only the annotated symbols (e.g. #apex, #systemapi,
etc.).
This will be used for stub libraries that are not part of NDK. So far,
symbols in such libraries haven't needed to be annotated as #apex, and
that has caused a confusion that those symbols belong to NDK. The
follow-up change will ensure that those symbols are always annoated as
either #apex or #systemapi so that their roles are clearly visible.
Bug: 184712170
Test: atest test_ndkstubgen
Test: atest test_symbolfile
Change-Id: Ic8d2c7d0b32bdef79f7563621035e60f406e4131
The generated Bazel workspace will only contain api specific targets.
This is feasible since these targets do not have any cross dependencies
with the targets in the bp2build workspace
The advantages of a new mode are
1. Does not pollute bp2build workspace with api targets
2. Does not block api targets with the current allowlist conversion
mechansims in bp2build
(In the future we might want to combine these two workspaces)
A Soong module type will generate a Bazel target if it implements
ApiProvider interface
Test: m apigen
Test: m nothing
Change-Id: I69c57ca6539f932e0ad554ce84a87fb7936fdba0
Add barebones riscv64-linux-android support. This should be enough
to add riscv64-specific entries to Android.bp files, but can't
actually compile anything until there are riscv64 toolchains.
Test: arch_test.go
Change-Id: I0dcc7e797d9352dd38243be908a7f19004ff3db1
The certificate module is handled the same in Soong between android apps
and apexes, so share the bp2build code as well.
There are a few changes in this CL:
- If override_apex.certificate is unset, the generated apex also unsets
it. This prevents the generated apex from using the base apex's
certificate, which is most likely incorrect (e.g. google variant using
the cert for the aosp variant). Instead, rely on the default
certificate handling in the macro.
- If the certificate prop is a string, then it gets generated into
certificate_name in order to disambiguate. This behavior is identical
to android_app.
Test: added various unit tests.
Bug: 249089160
Fixes: 249089160
Change-Id: I99e18964ff546429a985d0f64dc21e2c69d35d9d
Revert submission 2164342-use-jdk17
Reason for revert: DroidMonitor-triggered revert due to breakage b/250426490
Reverted Changes:
Ib1a24e7ea:Update path for libjli.so
I3375bd4e4:Use the toolchain from JDK 17
I9183e5511:Use the toolchain from JDK 17
Change-Id: I28fc32290dd337b7d44bb98bc52956ee84f01aaa
Remove Toolchain.GccRoot, Toolchain.GccVersion, and Toolchain.GccTriple
that were only used by an unused function. This removes most of the
references to GCC, although there are still some left in the host
toolchains.
Test: No change to build.ninja for aosp_cf_x86_64_phone-userdebug or aosp_raven-userdebug
Change-Id: I72b8af1f9aa83e6e15c9e00ed1e817b6cc3a031a
musl_linker_script is no longer required as the entry point is now
_start.
Bug: 242601708
Test: m USE_HOST_MUSL=true host-native
Change-Id: I5acfaeb181a2dd39aac72edd94bd2030881d9d27
Bug: 249769908
Test: packages/modules/common/mainline_modules_sdks.sh
# With modification to add UpsideDownCake to list of releases
# to build with.
Change-Id: I050811e7d9a5d0a8cf54a42c03ad889defa3a251
customBindgenTag is used to describe a particular host tool - don't
propagate apex dependency across it.
Bug: 249849807
Test: Adding rusqlite to apex no longer requires bindgen allowed
Change-Id: Ifcb2a94c577c72558f757bf10e975212558fe790
