aconfig: create aconfig_storage_write_api crate

aconfig_storage_write_api crate is the lib to be used by aconfig storage
daemon to update flag value at a given offset.

Note that mmap api is unsafe from memmap2 crate. This is due to the
possibility of other code write to the file after mmaping the file into
memory. Therefore the api to write to storage value file is also marked
as unsafe. In reality, the persistent storage value file is protected by
SELinux policy to allow write access only to aconfig storage daemon. In
addition, aconfig storage daemon is single threaded. So at any time,
only one thread is writing to a storage file, and only thru the mmapped
file in memory (not thru direct file write). So it would safe for
storage daemon to call this api.

Bug: b/312444587
Test: m libaconfig_storage_write_api; atest
aconfig_storage_write_api.test

Change-Id: I93cffea0d94e4c40e711d809418c0b18b6d9bfe1
10 files changed
tree: 347b67b81e2ba5a45497d6c39f28848ee81b0a78
  1. ci/
  2. common/
  3. core/
  4. packaging/
  5. target/
  6. teams/
  7. tests/
  8. tools/
  9. .gitignore
  10. banchanHelp.sh
  11. buildspec.mk.default
  12. Changes.md
  13. CleanSpec.mk
  14. cogsetup.sh
  15. Deprecation.md
  16. envsetup.sh
  17. help.sh
  18. METADATA
  19. navbar.md
  20. OWNERS
  21. PREUPLOAD.cfg
  22. rbesetup.sh
  23. README.md
  24. shell_utils.sh
  25. tapasHelp.sh
  26. Usage.txt
README.md

Android Make Build System

This is the Makefile-based portion of the Android Build System.

For documentation on how to run a build, see Usage.txt

For a list of behavioral changes useful for Android.mk writers see Changes.md

For an outdated reference on Android.mk files, see build-system.html. Our Android.mk files look similar, but are entirely different from the Android.mk files used by the NDK build system. When searching for documentation elsewhere, ensure that it is for the platform build system -- most are not.

This Makefile-based system is in the process of being replaced with Soong, a new build system written in Go. During the transition, all of these makefiles are read by Kati, and generate a ninja file instead of being executed directly. That's combined with a ninja file read by Soong so that the build graph of the two systems can be combined and run as one.