Check that device is shipped supporting v3 in order to enable it.
Otherwise fallback.
Bug: 331202590
Test: th
Change-Id: I218fbaa6a044420af39be70b055da5ffbfced158
Flag type is encoded as a u16 in flag table file. Previously we are
assinging value of 1 for flag type to indicate that they are all boolean
flags. In this change, we formalize the flag type designation with an
enum.
ReadWriteBoolean -> 0
ReadOnlyBoolean -> 1
FixedReadOnlyBoolean -> 2
Bug: b/321077378
Test: atest aconfg.test; atest aconfig_storage_file.test
Change-Id: I114818435b44f1e82a611f0509787993a5a8e70e
These two TODO tags were improperly formatted, which means automation
will not alert anyone if the ticket is closed.
Bug: 327420679
Test: git diff
Change-Id: I99c8215fe3e24cdf3fa7be517291964cc5eb1ecf
Signed-off-by: Lucas Henneman <henneman@google.com>
Add a mode that lets the user use the new aconfig storage.
Bug: 324436145
Test: adb shell aflags list --use-new-storage
Change-Id: I97d7a229a64c6ef1aea844281298ce5449b02570
Flag info file is another memory mapped file to store the file
information such as if current flag has been staged or not, is it sticky
and etc. This file will be created by aconfig storage daemon during
container initialization.
Bug: b/321077378
Test: atest aconfig_storage_file.test
Change-Id: I8f70e04c74b5770f89dbe981d9f03c787ea5eeed
We need the aconfig APIs to be available on every mainline module, so
set the min_sdk_version as low as possible.
Bug: 328444881
Test: m
Change-Id: I02e569d510a30f4809d4a82f7630326b0b30f263
This reverts commit 54101665ee.
Reason for revert: Fixed build breakage
Bug: 322090587
Change-Id: I065a187bf5863cbb381b4f3308aae7b7200ffa6d
Test: compare build.prop before and after
Test: build multiple times and see build.prop isn't rebuilt
Logging the apk_name will improve debugging process if
`GetMinSdkVersion` returns an exception.
Test: None
Change-Id: I3ddf602d92701dcaaa4821fe42a76a870a721a11
Test: Sign target files package where
SYSTEM/product/media/bootanimation-dark.zip is a symlink to
bootanimation.zip.
Change-Id: I4648c3c39c094cb090cbe337c566c3e9ad894691
In the case that a vendor is on s build (which doesn't have snapuserd),
and is takinga v3 -> v3 upgrade, we want to fallback to v2 vabc ota.
Test: th
Change-Id: Iba259b139b9b423ac77d82e14a113cf35fbfea64
Allow override for vabc_cow version if specified from the command line.
If OPTIONS.vabc_cow_version is already defined, then we don't want to
modify this value since it was defined by --vabc_compression_param=
Test: th
Change-Id: I57b8129faf5caf9de1dc8ad96e7570214a9f3313
To build system.img in Soong, we need all artifacts including
build.prop. This fully migrates buildinfo.prop file into Soong as a
first step to build build.prop on Soong.
Bug: 322090587
Test: compare build.prop before and after
Test: build multiple times and see build.prop isn't rebuilt
Change-Id: I0d5aab21a825cfe22f97a6834209f9df196625d9
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
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
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
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
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
Lines now have a new column, and look like this:
com.android.example.flag1 enabled - server read-write system
com.android.example.flag2 enabled (->disabled) server read-write system
The dash represents no change on boot, the (->value) represents a change
to value on the next boot.
Test: adb shell device_config put staged multitasking*com.android.wm.shell.enable_taskbar_navbar_unification true && adb shell aflags list | grep navbar_unification
Bug: 324436145
Change-Id: I022460bc69fcb2ccd9c6db8f060fcbd0337d1ea6
