As part of widget restore, we need to notify participants (hosts &
providers) of the mapping between ancestral and new widget ids.
Prior to this change, this was done at the end of system restore
and after each restore-at-install of unbundled apps.
There were two issues with this:
1) We would try to notify not-yet-installed participants at the end of
system restore and then *not* try again when they were installed.
2) We relied on PACKAGE_ADDED broadcasts to know which participants were
installed, but these are delivered asynchronously and not guaranteed
to be processed before the restoreFinished call.
After this change, we:
1) Only notify participants that are actually installed
2) Use receipt of the PACKAGE_ADDED / CHANGED broadcast to trigger
notification of any restore participants that are added or changed
*after* system restore completes.
2 is safe because by the time PackageManager sends the package
added / changed broadcasts, the app data restore has been completed,
and the app has been killed if needed.
Bug: 162057170
Test: Manual restore of Keep widget via cloud and d2d
Change-Id: I51dec33d09b62faba6d7c7daacd718a3c0682f7d
Also rename corresponding field and getter in SystemConfig.java, and add
new ALLOW_VENDOR_APEX flag to control what partitions can specify
allowed vendor APEXEs (so far: /product, /oem and /vendor).
Bug: 189274479
Test: atest FrameworksServicesTests:SystemConfigTest
Change-Id: I680090d7a1237cb95c1aa4ea3975c50d06b35fcc
Bug: 191488536
Test: Use BatteryStatsViewer to take a note of BT usage time
$ adb shell killall com.android.bluetooth
Use BatteryStatsViewer to verify that BT usage time is going up
Change-Id: I8438f19bb4bd6365da6d582fb7347f0a2cbddc1c
Fixes incorrect view transform in ViewRenderer
The tranform was mapping to on-screen coordinates, where
in-window position is needed.
Bug: 183045126
Bug: 189289758
Bug: 189235588
Test: manual, long screenshot the bottom app in split window mode
Change-Id: Ibaa9987b229f9e8ec0a1002ee84d797ca6026fb9
Unlike staged installer check, we can't check if given APEX package is
allowed to be updated at session creation time, since we don't have
knowledge of the package being installed yet. Instead, the check is
implemented in PackageInstallerSession#handleInstall.
Like staged install check, allowed apex update check has similar
exemptions (adb is allowed to update any APEX,
`adb shell pm --bypass-allowed-apex-update-check` makes next install
session bypass the check).
In order to implement these exemptions, a new
INSTALL_DISABLE_ALLOWED_APEX_UPDATE_CHECK flag that can only be set by
system is added. PackageInstallerSession will skip the APEX update
checks if INSTALL_DISABLE_ALLOWED_APEX_UPDATE_CHECK is set.
Bug: 189274479
Test: atest CtsStagedInstallHostTestCases
Test: atest GtsStagedInstallHostTestCases
Test: atest FrameworksServicesTests:SystemConfigTest
Change-Id: I22921a3ac4d43011b565733d7a7183e5cdb4fe80
Merged-In: I22921a3ac4d43011b565733d7a7183e5cdb4fe80
(cherry picked from commit aafaaec0d5)
Unlike staged installer check, we can't check if given APEX package is
allowed to be updated at session creation time, since we don't have
knowledge of the package being installed yet. Instead, the check is
implemented in PackageInstallerSession#handleInstall.
Like staged install check, allowed apex update check has similar
exemptions (adb is allowed to update any APEX,
`adb shell pm --bypass-allowed-apex-update-check` makes next install
session bypass the check).
In order to implement these exemptions, a new
INSTALL_DISABLE_ALLOWED_APEX_UPDATE_CHECK flag that can only be set by
system is added. PackageInstallerSession will skip the APEX update
checks if INSTALL_DISABLE_ALLOWED_APEX_UPDATE_CHECK is set.
Bug: 189274479
Test: atest CtsStagedInstallHostTestCases
Test: atest GtsStagedInstallHostTestCases
Test: atest FrameworksServicesTests:SystemConfigTest
Change-Id: I22921a3ac4d43011b565733d7a7183e5cdb4fe80
The bug proposes to 'move' the /proc/self/fd/ readlink/stat/etc checks
performed by the FileDescriptorAllowlist from before-fork to an earlier
stage.
The original aim was to allow the app zygote Preload hook to open
ashmem/memfd read-only regions to save more RAM (around 5MiB on aarch64)
via sharing more across processes. Potentially other files/sockets can
be opened - the app zygote takes responsibility of managing file
descriptor access controls across its own processes. App Zygote Preload
does not run 3rd party code.
Unfortunately a straightforward move of the checks to
just-before-preload has disadvantages:
* opens more codepaths for potential accidental misuse (the zygote
accepts commands between preload and fork, there are valid usecases
for extending these commands)
* this way FileDescriptorAllowlist would need to support more file
descriptor types (sockets and maybe pipes), which is not needed now
because these FDs are closed right before forking
The solution proposed here is to:
1. Determine the set of file descriptors open before preload
2. Run the preload hook
3. Determine FDs opened by the hook and allow them to remain open across
fork
4. Hypothetical new attempts to preload (if ever supported) will not
affect the allowed FDs - the preload will be able to toss its own FDs
the way it wants, but not open the new-new ones
Bug: 184808875
Test: Manual: unreleased Chrome patch: while in app zygote preload,
create ashmem region, passes it to 'untrusted_app' (=browser
process), and call mmap(2) on it.
Change-Id: Ie302eabca83a0e4f409cb131e4308b73e5f6a580
