When an OTA is downloaded, the RecoverySystem can be triggered to store
the user's lock screen knowledge factor in a secure way using the
IRebootEscrow HAL. This will allow the credential encrypted (CE)
storage, keymaster credentials, and possibly others to be unlocked when
the device reboots after an OTA.
Bug: 63928581
Test: make
Test: boot emulator with default implementation
Test: boot Pixel 4 with default implementation
Change-Id: I1f02e7a502478715fd642049da01eb0c01d112f6
This change is part of a topic that moves the recovery resources from the
system partition to the vendor partition, if it exists, or the vendor directory
on the system partition otherwise. The recovery resources are moving from the
system image to the vendor partition so that a single system image may be used
with either an A/B or a non-A/B vendor image. The topic removes a delta in the
system image that prevented such reuse in the past.
The recovery resources that are moving are involved with updating the recovery
partition after an update. In a non-A/B configuration, the system boots from
the recovery partition, updates the other partitions (system, vendor, etc.)
Then, the next time the system boots normally, a script updates the recovery
partition (if necessary). This script, the executables it invokes, and the data
files that it uses were previously on the system partition. The resources that
are moving include the following.
* install-recovery.sh
* applypatch
* recovery-resource.dat (if present)
* recovery-from-boot.p (if present)
This change includes the sepolicy changes to move the recovery resources from
system to vendor. The big change is renaming install_recovery*.te to
vendor_install_recovery*.te to emphasize the move to vendor. Other changes
follow from that. The net result is that the application of the recovery patch
has the same permissions that it had when it lived in system.
Bug: 68319577
Test: Ensure that recovery partition is updated correctly.
Change-Id: If29cb22b2a7a5ce1b25d45ef8635e6cb81103327
Since these libraries were vndk-sp, previously, passthrough HALs were
able to load them. However, now that they have been removed from the
vndk-sp set (these libraries are empty), marking them as
same_process_hal_file so that vendor passthrough implementations that
still link against these empty libraries can still use them.
Bug: 135686713
Test: boot device using these libraries from an sphal (otherwise,
bootloops)
Change-Id: Ic5170eb0fcbb87c82bbea840dcfcb17899eaa899
This duplicated ashmem device is intended to replace ashmemd.
Ashmem fd has a label of the domain that opens it. Now with ashmemd
removed, ashmem fds can have labels other than "ashmemd", e.g.
"system_server". We add missing permissions to make ashmem fds usable.
Bug: 139855428
Test: boot device
Change-Id: Iec8352567f1e4f171f76db1272935eee59156954
Since this was an example service providing no real functionality and
accidentally got installed on a device.
Bug: 140115084
Test: install on test device and see that it runs
Change-Id: I553da8e1f4da7d6a9f0c3e7d4a3561f0b22321dc
The audio HAL service name previously contained the audio HAL version
of the first audio HAL it supported.
Nevertheless, the same service can and do host all audio HAL versions.
Aka there is only one audio HAL service, and the version in its name is
technical dept and should not be changed.
This caused many confusions during vendor HAL upgrade as the
service version number was erroneously updated leading to
device boot loop.
The new service name is:
android.hardware.audio.service
The old one was:
android.hardware.audio@2.0-service
Keeping both names valid as most phones will not rename
the service immediately.
Bug: 78516186
Test: boot & check the audio HAL is up with the old and new name
Change-Id: I2ce0182fd919af6eb8325d49682b4374be00344e
Signed-off-by: Kevin Rocard <krocard@google.com>
The space between 2K and 16K in /misc is currently reserved for vendor's
use (as claimed in bootloader_message.h), but we don't allow vendor
module to access misc_block_device other than vendor_init.
The change in the topic adds a `misc_writer` tool as a vendor module,
which allows writing data to the vendor space to bridge the gap in the
short term. This CL adds matching labels to grant access.
Long term goal is to move /misc as vendor owned, then to provide HAL
access from core domain (b/132906936).
Bug: 132906936
Test: Build crosshatch that includes misc_writer module. Invoke
/vendor/bin/misc_writer to write data to /misc.
Change-Id: I4c18d78171a839ae5497b3a61800193ef9e51b3b
Merged-In: I4c18d78171a839ae5497b3a61800193ef9e51b3b
(cherry picked from commit 42c05cfcc1)
The space between 2K and 16K in /misc is currently reserved for vendor's
use (as claimed in bootloader_message.h), but we don't allow vendor
module to access misc_block_device other than vendor_init.
The change in the topic adds a `misc_writer` tool as a vendor module,
which allows writing data to the vendor space to bridge the gap in the
short term. This CL adds matching labels to grant access.
Long term goal is to move /misc as vendor owned, then to provide HAL
access from core domain (b/132906936).
Bug: 132906936
Test: Build crosshatch that includes misc_writer module. Invoke
/vendor/bin/misc_writer to write data to /misc.
Change-Id: I4c18d78171a839ae5497b3a61800193ef9e51b3b
Bug: 130509605
Test: No avc denial log and NFC works with hal v1.2
Change-Id: If54884f76a32705d11f2085f66fe83b9e0354f79
Merged-In: If54884f76a32705d11f2085f66fe83b9e0354f79
(cherry picked from commit a5dde796b5)
Modify sepolicy configure file, so that cas@1.1 service can run
Test: Manual
bug: 124016538
Change-Id: I0b160bc1c575aa18ffead7ff136509fc9dcfb472
Merged-In: I142a6cd66a81ad9e0c8b4d87da672fb8f5c181d6
