This directory is used to store the Weaver/GateKeeper slot map so GSIs
do not overwrite host keys in secure storage.
Bug: 123716647
Test: /metadata/password_slots exists after boot
Change-Id: Ib0ca13edec38e68cba1fc2124465571feedc4be7
In order to test Trusty gatekeeper automatically, the storage proxy
needs to be active inside the emulator. This patch allows storageproxyd
to speak a length-framed RPMB to an external RPMB daemon.
For a concrete example of a daemon speaking this protocol, see rpmb_dev
in the Trusty tree.
Bug: 124277696
Test: Launch storageproxyd with -t virt, use Trusty test infra
Change-Id: I391d4768976f0eb1f3b8df58eefd58fc3a9409cd
am: e7a9fabd64 -s ours
am skip reason: change_id I4ef6433391c8758626334731d2b5de038e4468ae with SHA1 1417cdbddb is in history
Change-Id: I0b6eb14568d480b13fd0cea14863a9ad4c14c0cd
am: e7cfa67a05 -s ours
am skip reason: change_id Ie555933aafa6a6b7aa1dbf5518ebe804376e0afd with SHA1 fe31bef940 is in history
Change-Id: I3c357f360da2969e1850f32419e4b074bbe17e21
am: b68fe506e0 -s ours
am skip reason: change_id I4ef6433391c8758626334731d2b5de038e4468ae with SHA1 34c3cb84a0 is in history
Change-Id: I2521241013c39d3cc16f45b1df996135f92a053f
am: 9eee2302ee -s ours
am skip reason: change_id Ie555933aafa6a6b7aa1dbf5518ebe804376e0afd with SHA1 4dbc24d393 is in history
Change-Id: I42d2080003936bcf99fec6917fe5e52366855c07
This is to measure an application's behavior with respect to being LMKed
(the longer an app lives before being LMKed, the better).
Bug: 119854389
Test: Manual
Change-Id: I4ef6433391c8758626334731d2b5de038e4468ae
Merged-In: I4ef6433391c8758626334731d2b5de038e4468ae
(cherry picked from I4ef6433391c8758626334731d2b5de038e4468ae)
am: 962e0442d1 -s ours
am skip reason: change_id I4ef6433391c8758626334731d2b5de038e4468ae with SHA1 1417cdbddb is in history
Change-Id: I56f76418a5c6a3435dec766d731068f60bd4b642
am: 2bc24f88ca -s ours
am skip reason: change_id Ie555933aafa6a6b7aa1dbf5518ebe804376e0afd with SHA1 4dbc24d393 is in history
Change-Id: I5676596b2ee9f7448faa0b0274ac9425c7525fb0
This is to measure an application's behavior with respect to being LMKed
(the longer an app lives before being LMKed, the better).
Bug: 119854389
Test: Manual
Change-Id: I4ef6433391c8758626334731d2b5de038e4468ae
Merged-In: I4ef6433391c8758626334731d2b5de038e4468ae
(cherry picked from I4ef6433391c8758626334731d2b5de038e4468ae)
Currently, moving or copying a Maps object leads to double free of MapInfo.
Even moving a Maps object did not prevent this, as after a move
the object only has to be in an "unspecified but valid state", which can
be the original state for a vector of raw pointers (but not for a vector
of unique_ptrs).
Changing to unique_ptrs is the most failsafe way to make sure we never
accidentally destruct MapInfo.
Test: atest libuwindstack_test
Failed LocalUnwinderTest#unwind_after_dlopen which also fails at master.
Change-Id: Id1c9739b334da5c1ba532fd55366e115940a66d3
Log min_score_adj when lmkd kills a process to determine the oom_score
levels that lmkd considers during the kill.
Bug: 123024834
Change-Id: I986ae8f2808199b1654bc8d2a32dd88046c79aa3
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Summary: Boot sequence around apexd is changed to make it possible for
pre-apexd processes to use libraries from APEXes. They no longer need to
wait for the apexd to finish activating APEXes, which again can be
done only after /data/ is mounted. This improves overall boot
performance.
Detail: This change fixes the problem that processes that are started
before apexd (so called pre-apexd processes) can't access libraries
that are provided only by the APEXes but are not found in the system
partition (e.g. libdexfile_external.so, etc.). Main idea is to activate
system APEXes (/system/apex/*.apex) before /data is mounted and then
activate the updated APEXes (/data/apex/*.apex) after the /data mount.
Detailed boot sequence is as follows.
1) init prepares the bootstrap and default mount namespaces. A tmpfs is
mounted on /apex and the propagation type of the mountpoint is set to
private.
2) before any other process is started, apexd is started in bootstrap
mode. When executed in the mode, apexd only activates APEXes under
/system/apex. Note that APEXes activated in this phase are mounted in
the bootstrap mount namespace only.
3) other pre-apexd processes are started. They are in the bootstrap
mount namespace and thus are provided with the libraries from the system
APEXes.
4) /data is mounted. init switches into the default mount namespace and
starts apexd as a daemon as usual.
5) apexd scans both /data/apex and /system/apex, and activate latest
APEXes from the directories. Note that APEXes activated in this phase
are mounted in the default namespaces only and thus are not visible to
the pre-apexd processes.
Bug: 125549215
Test: m; device boots
Change-Id: I21c60d0ebe188fa4f24d6e6861f85ca204843069
