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
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)
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
* changes:
Implement battery_usage_stats_before_reset pull atom
Add BatteryUsageStatsQuery parameters: time range
Implement BatteryUsageStatsStore
Convert BatteryUsageStats to and from XML
Add BatteryUsageStats.add(BatteryUsageStats)
* Logs the atom AccessibilityShortcutReported in westworld
Bug: 189860801
Test: make statsd_testdrive && statsd_testdrive 266
Change-Id: I4e5814cb6a1d877af540e278de5ffa398d6d0351
Sending the notification from the InputConnection layer reduces the
number of events that are handled (merged) by ContentCapture. We are
also able to handle composing span being removed; at the TextView layer,
we cannot do that as we don't know if the composing span will be added
back, which happens on typing).
Bug: 184311217
Test: manual - append chars, delete chars, replace text, move cursor to
composing text, move cursor to remove composing span, drag cursor
Test: atest android.contentcaptureservice.cts.LoginActivityTest
Change-Id: I0e9d153cf7ba2734f38cb1b6044eb7b670fb34ad
Previously, a queue would be written to, a lot more often than items
were removed from it. This caused it to grow massively.
This cl changes the way that the synchronizer works, updating both
values when needed and avoiding potential race conditions.
It's relevant to note that mDisplayManager.setBrightness will only change the value if it is different, but Settings.System.putIntForUser will set it regardless, therefore causing a second "int changed" message to be sent.
Bug: 177523959
Test: manual
Test: loop this command: adb shell settings put system screen_brightness \
$((RANDOM%100))
Test: loop this command: adb shell settings put system \
screen_brightness_float 0.$((RANDOM%100))
Change-Id: I6cafb48c204ce5245c4450a6098473e06c334667
