1, See AconfigStorageReadAPI.java to see java APIs to map storage files
and read flag values. It is using fast native annotation, in theory it
should be faster than regular JNI without much of the overhead.
2, The java api calls into Rust wrapper in srcs/lib.rs, note that
MappedByteBuffer is not copied during JNI. In the rust side
implementation we get the underlying raw pointer and buffer size and
reconstruct a rust slice. However, at current implmentation, the string
input such as package name and flag name are most likely copied. They
are converted from JStirng to JavaStr first without copy, then the
into() call to convert it to Rust string. We could potentially optimize
it to without copy.
3, Add an android_test target to lock down the API behaviors.
Bug: b/321077378
Test: atest -c
Change-Id: I8915fe70e8eb341be563c70f85e19e644e8aa6be
Update storage read api to not find storage file location from a pb
file, instead directly read from /metadata copy. Previously for
package.map and flag.map, we are reading from the respective RO
partition. Now we are reading from /metadata/maps dir. This has a few
advantages:
1, early flag availability, since /metadata can be mounted much earlier
than mainline modules, so it would make mainline flags availabile even
before mainline modules are mounted.
2, we no longer need to read from a pb file to find where package.map
and flag.map are. Thus the read api can be further simplified and
downsized. With this change, we are able to shrink the cc flag read api
lib size from 171k to 120k.
Bug: b/321077378
Test atest -c
Change-Id: Ic9086fe4c49c139a4d1c66a8d472023a88c9dd17
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
1, add storage file type into storage files serialization
2, update aconfig_storage_read_api integration tests to not rely on
soong to produce read only storage files. Instead, have the test process
create temp read only storage file copies.
Bug: b/312444587
Test: atest aconfig.test; atest.aconfig_storage_file.test
Change-Id: I1607fb000b48e8acffc966b16a5136578911ab3e
Current aconfig_storage_file crate contains two things: 1,
aconfig storage file definition (which is used by aconfig crate for
storage file creation) and 2, flag storage file read api. With this
change, we are splitting 2 into its own crate aconfig_storage_read_api
In the long run, there will be 3 crates for aconfig_storage
1, aconfig_storage_file
It contains aconfig storage file definition, as well as a binary to help
print/dump aconfig storage binary files into some readable format.
2, aconfig_storage_read_api
This crate contains flag read apis. This crate depends on
aconfig_storge_file crate. This crate will be used by codegen.
3, aconfig_storage_write_api
This crate contains flag write apis. This crate depends on
aconfig_storage_file crate. This crate will only be used by aconfig
daemon to update flag values.
Bug: b/321077378
Test: atest aconfig_storage_read_api.test; atest
aconfig_storage_file.test; atest aconfig_storage_read_api.test.rust;
atest aconfig_storage_read_api.test.cpp
Change-Id: Ia6afdc40a45c7c59652fbfd123c2b77bf6666dd9
