Previously we are ensuring that the public rust api to get mapped file
is safe as we are ensuring that the file being mapped has a permission
of 444. However, a file permission of 444 is not possible due to build
system needs to make file 644 while creating img files. Thus need to make the rust api to get mapped file unsafe.
In reality, this should have no impact. Because, even though the storage
files have a file permission of 644, they are on a RO partition like
system. So the files are not writable anyway. This is true for all the
containers (platform partitions and mainline modules) we know so far.
Bug: b/321077378
Test: atest aconfig_storage_read_api.test; atest
aconfig_storage_read_api.test.rust; atest
aconfig_storage_read_api.test.cpp
Change-Id: I643fe191e697a524e2303a32750f04c268f408fd
It was broken by the last change (because unlike `which adb`, `command
adb` does not search $PATH if there's already an entry in the hash).
No-one's noticed in almost a year, but this has caused (rare) confusion
in the past.
Bug: http://b/24473359
Change-Id: I6bbb207992449132ba8563a8bcf298256c599c0d
This is safe since GTS tests already exist to check for mandatory modules, which these modulea are a part of.
Test: packages/modules/common/build/mainline_modules_sdks.sh
Bug: 238203992
Ignore-AOSP-First: changes in topics with internal-first/internal-only projects.
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:e14f4862bb439a73214bef4d909e9bdf35de8e40)
Merged-In: Ica19b306bdbd67a86d2cf73478d0f886f782118c
Change-Id: Ica19b306bdbd67a86d2cf73478d0f886f782118c
We have moved the storage records metadata pb file to the boot dir.
Bug: b/321077378
Test: atest aconfig_storage_read_api.test
Change-Id: Ic5bd89052e311ec5b1993ba1779d49be8451caa2
Due to branch constraints, remove the extra targets defined inside the
build script and revert to having them be passed in via command line.
Test: ./build/make/ci/build_test_suites_x86_64-trunk_staging --target_product aosp_x86_64 --target_release trunk_staging --with_dexpreopt_boot_img_and_system_server_only <extra_targets>
Bug: 314171817
Change-Id: I89a82e969d294104f587d778ad319a41905320f8
If devkeys are present, we don't need to specify a serialno. In this
case we should conditionally add serial no to our metadata
Test: create_brick_ota
Change-Id: I9c93aa0f9ec5752693a9ddde5b76be4c12d6fc3b
In preparation of switching over the git_main test suites target to
using this script change it to a no-op first to insure there's no
initial impact.
Test: ./build/make/ci/build_test_suites-trunk_staging --target_product aosp_x86_64 --target_release trunk_staging --with_dexpreopt_boot_img_and_system_server_only
Bug: 314171817
Change-Id: I7afab933143e4b617866b1975b1cbc71107f5b2f
This is required to use the install_symlink module on these
partitions.
Test: Create install_symlink module on /system_ext
Change-Id: I78e93c5df12bae8fc23b378a30d43bf6c0b67d53
Only include a release_config_map.mk file the first time it appears in
the list.
If the flag declaration is identical to one already declared, do not
raise an error.
This eases the process of migrating where flags are declared.
Bug: b/328781415
Bug: b/328495189
Test: manual, TH
Change-Id: I18316e769438f62071723771762d6e89be98b813
Merged-In: I18316e769438f62071723771762d6e89be98b813
VNDK Current APEX is being removed because VNDK is deprecated with
202404 and VNDK current APEX is no more available. This change removes a
reference to the VNDK current APEX so it won't look for removed module.
Bug: 328994089
Test: AOSP CF build succeeded
Change-Id: Id3c65b1e9a403847f43d2fa344c832ae43c2051d
Language services builds are usually executed in a non-building state of the codebase as the user is actively editing the code.
This change ensures we can build as many dependencies as possible for language services by ninja.
Note that this doesn't change the error-limit for soong itself, i.e. we can still fail-early if we encounter errors while generating ninja files.
Change-Id: I594e2ae4591d2e75db082486f28f705833ceb4a8
SDK products, which are required to build the SDK, require checkapi
to run in order to generate the exportable artifacts, which are copied
to the dist directory. Thus, this change adds a conditional to emit an
error when WITHOUT_CHECK_API environment variable is set when the target
product is a SDK variant.
Test: lunch sdk-trunk_staging-eng && m WITHOUT_CHECK_API=true and observe the expected error being emitted
Bug: 329374072
Change-Id: I0dc628742c49845792b03f9af1ea60cd9eb4b8c3
Now that ANGLE on system is in fully released, clean up the build file
configuration and remove the flags.
Bug: b/293503000
Test: atest CtsAngleIntegrationHostTestCases
Change-Id: Ie8294b6494e2fad44ff102ecf0018916d61b082a
Merged-In: Ie8294b6494e2fad44ff102ecf0018916d61b082a
Now the read api lib no longer owns the memory mapped file. The rust lib
aconfig_storage_read_api api to get memory mapped file just returns an
Mmap rust struct. However cxx does not support Mmap data type, so we
cannot export the api to get memory mapped file from rust to c++. This
means we have to implement c++ apis to get memory mapped files.
This change is basically implementing c++ api to get memory mapped files,
mirroring the rust implementation. In addition, the integration test is
also updated to lock down the new c++ api implementation.
Bug: b/321077378
Test: atest aconfig_storage_read_api.test.cpp
Change-Id: I5e93a220cdd05cc0e5b0eb441284ac3e9dc34da7
Right now, aconfig_storage_read_api rust lib would own mapped files. So
individual flag lib does not need to. The original intent is that all
these flag lib can dynamically link against this lib. So say we have
different variants of flag lib for one flag package, there is just one
unique memory mapped file. In addition, the exposed rust apis hides the
memory mapped files. So when exporting these apis to c++/java, we don't
have to implement memory mapping in c++/java flag read api lib.
However, this design has its own downside. The biggest being that these
memory mapped files are stored in a mutable static hash map. For rust,
it must be protected by a mutex lock. The real effect on the lock is
mostly minimal as it immediately unlocks when the clone of memory
mapping is returned. But still we could get more performance out of it
in exchange of having more c++/java side implementation of mapping
files. (Note, apis that interpret mapped files are still exported by
Rust, so no c++/java implementation needed).
In this change, aconfig_storage_read_api give away its ownership of
memory mapped file in its api to get memory mapped file. The memory
mapped file is supposed to be owned by generated flag lib. By doing so,
no more mutex lock is needed. Also, since each flag lib has one flag
package, which maps to a single owning container. The flag lib can have
the memory mapped files as non mutable static variables. So no mutex
lock penalty on flag lib side.
Bug: b/321077378
Test: atest aconfig_storage_read_api.test; atest
aconfig_storage_read_api.test.rust
Change-Id: I29060bae90db6f7d296252ed73f7e312143f4b7e
