-fprofile-sample-accurate allows the compiler to de-optimize cold code
paths according to the profile. However we have a number of micro-
benchmarks that tests these paths and we often trigger regression
reports from those benchmarks.
Turning off the flag mitigates the issue at a cost of ~2MB increase in
system image size. But the more deterministic codegen could reduce the
differential OTA size.
Test: presubmit
Bug: 283235002
Change-Id: I1016f573f21a60223a97c64f5818f0e7e66e41e3
To support stem, cc libraries will be generated in
<pacakge_name>/<label.name>. Update RUNPATH of java binaries so that it
can find its jni deps
Test: bp2build
Test: TH
Bug: 240563612
Change-Id: Ia2f70f0424a8526ee35856225c1a8cd1067a8570
By default, the artifacts generated by cc_binary and cc_library in Soong
track the module name. But Soong supports overidding this using the stem
property. e.g.
```
cc_library {
name: "foo.1.2",
stem: "foo",
}
```
will generate foo.so
This CL adds this property to bp2build
Test: bp2build unit tests
Bug: 240563612
Change-Id: I1dfed870d5bad450511b72c397d2355c01fa3b60
This change cleans up references to android.JavaApiLibraryName() so that
rdeps link against "android_*_stubs_current" instead of
"android_*_stubs_current.from-text".
Bug: 284995489
Test: m
Change-Id: Ibdf33b15981317c43e468dbc1657229d54bbd226
Redefined core and core platform API surface java_library using the
product variable build_from_text_stub so that the correct static libs
are linked based on build configuration
Test: m --build-from-text-stub and verify no ninja path between "core.current.stubs" and "core.current.stubs.from-source"
Bug: 285410821
Change-Id: I26febc65697be6278624a504ffbb61be0953d798
Build_from_text_stub can be used to specify static lib and exclude
static lib based on build configuration.
Bug: 285410821
Test: m
Change-Id: I083f32325c7b3ab5e88c4f5cb248c00f2094fb1e
Exclude_static_libs property can be used to specify static libs that
should not be used to build the module. The list acts as filter for
static_libs.
Bug: 285410821
Test: go test ./java
Change-Id: Iee7f160ba88b5f64bdd265c30d47c9f51feb0f5e
The CFI transition being applied creates a situation where Bazel
clears its convenience symlinks. This change points the script
directly to the location of the deapexer artifact instead of the
symlink.
Bug: 261733820
Test: Ran the tests
Change-Id: I23951f0fe75ce1fbc3c0dd969244a797ac1ff983
In-order to automatically detect which type of authentication to use for
RBE, we need to be able to run these binaries in bootstrap. Hence
allowlisting them.
Bug: 283828386
Change-Id: I1e0e021acc8283ec3e66c96f6676c6095bf0892b
Apparently there's some special case-code in package manager that
scans apps as privileged regardless of their location. BT is one
such app -- so allow it to specify a privapp allowlist even though
it isn't in priv-app.
Bug: 284500052
Test: use privapp_allowlist in Bluetooth and its overriddes
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:a91268a690e2aa98a0fa7b376a948a48f41b1265)
Merged-In: Ib9ac86ebc45087a176100fe8df07db7bf81a85a7
Change-Id: Ib9ac86ebc45087a176100fe8df07db7bf81a85a7
truth-prebuilt and truth-host-prebuilt are able to be
built by bazel now.
Bug:285001041
Test: presubmit
Change-Id: I49ca0c4ccd55a0df591176554eab4e82c95e4699
Since vendor APEXes are installed in vendor partition, there shouldn't
be system_file according to Treble. Instead, we can force-label / and
/apex_manifest.pb as vendor_apex_metadata_file so that apexd (and other
system components) can still read them.
Bug: 285075529
Test: m nothing (soong test)
Change-Id: Idb36b8c4c68b29e2235dbda38ee323d4b781e1d5
In non-incremental build, there is no ninja_log. For this case, use
HINT_FROM_SOONG as an alternative solution.
Bug: 273947040
Test: 1.m after removing out/.ninja_log
2.check if non-incremental CI build uses HINT_FROM_SOOONG
3.check if incremental CI build uses NINJA_LOG
4.check if there is no regression in CUJ
Change-Id: I00cd216df096cb2288eeab233729acefb0d1b73c
Use the APK's filename as the on-device filename for the allowlist.
Previously the filename of the source xml file was used, which leads to
a problem when the same source file is used for different apps (even
if only one of those modules ends up being installed).
Bug: 284500052
Test: app_test.go & presubmit boot tests
Change-Id: I0b43a35e3a310464d79d7f37e0900d639f4a479c
These warnings are not critical. We can fix them later.
Bug: 285361108
Bug: 285356805
Bug: 285356799
Test: build with WITH_TIDY=1 using clang-r498229
Change-Id: I594279a10ffb4fda07dfc33350b44d09c42d3f97
In Soong, cc libraries depend on source files generated from xsd_config
using generated_sources and generated_headers. In Bazel, these souces
will be wrapped in a static library. Updated bp2build so that these are
written to implementation_whole_archive_deps instead.
Bug: 211678537
Test: bp2build test in sibling CL in system/tools/xsdc
Change-Id: Ib57c563a1eb7483bd7b04ba0d3852ecac17cde6c
In Soong, java libraries can use src files generated from xsd_config. In
Bazel, instead of providing srcs, java_xsd_config_library will provide a
jar. Update bp2build so that all src references to xsd_config modules in
srcs get routed to deps and exports attributes
This CL creates an interface in build/soong/android to get around a
circular dependency issue. The bp2build logic needs to exist in
soong-java, but soong-java does have soong-xsdc in its package path. Use
the interface and type assertions to special case xsd_config references
Bug: 211678537
Test: bp2build test in sibling CL in system/tools/xsdc
Change-Id: Ida924bb20b1fd7eb8beeef950b070d37a9c6f3b5
