mWinFrame as set when returning from relayout will be in screen
space coordinates. repositionChild however expects coordinates relative to the
parent position (like relayout).
Bug: 31112993
Change-Id: Id4fcd7fcb771908e8a7db981207d19c99fb51b98
Methods onRestrictBackgroundWhitelistChanged() and
onRestrictBackgroundBlacklistChanged() were replaced by a more generic
onUidPoliciesChanged().
Test: m javac-check RUN_ERROR_PRONE=true
Test: m -j32 FrameworksServicesTests && adb install -r -g ${ANDROID_PRODUCT_OUT}/data/app/FrameworksServicesTests/FrameworksServicesTests.apk && adb shell am instrument -e class "com.android.server.NetworkPolicyManagerServiceTest" -w "com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner"
BUG: 28791717
Change-Id: I18b2ee4af06802e0d23822b153d1be9b429d5811
- Non-test-only DO/PO still can't be installed when there are
accounts.
- Test-only DO/PO can be installed even when there are accounts,
as long as all the accounts have the
"android.account.DEVICE_OR_PROFILE_OWNER_ALLOWED" feature.
Some authenticators claim to have any features, so to detect it,
we also check android.account.DEVICE_OR_PROFILE_OWNER_DISALLOWED
and disallow installing if any of the accounts have it.
- Also add logs on certain important events in DPMS.
Bug 28928996
Change-Id: I62efce10e9cc22e994ea8cae91a4fafcce25dd77
If the OTA updates a system app which was previously preopted to a non-
preopted state the app might end up being verified at runtime. That's
because by default the apps are verify-profile but for preopted apps
there's no profile.
Do a hacky check to ensure that if we have no profiles (a reasonable
indication that before the OTA the app was preopted) system apps get
compiled with a non-profile filter (by default interpret-only).
Bug: 30032273
Test: Andreas "has verified that Calin's change to A/B works as expected
and promotes things like SystemUI to speed. From my side, that's
ready to be merged"
Change-Id: I7a052a8ea76cab7f649dc993237ea05534d6c4b9
(cherry picked from commit 0bd7762079)
Add functionality to capture/intercept installd communication, and
use this to return the full communication for dexopt. These parameters
can be used to drive otapreopt_chroot directly.
Keep the old direct invocation alive until devices have transitioned
to a service that exposes this API.
In preparation for renaming of A/B OTA artifacts to include target
slot names.
Bug: 25612095
Bug: 28069686
Change-Id: I14728ee1266f3882cada8f08dd21891ed5f7a0cb
(cherry picked from commit cc241a580c)
To be able to report progress of an A/B OTA dexopt, expose a
progress function that the script can query.
Bug: 25612095
Bug: 29223204
Change-Id: Ie8162946d18f6fa78649a40ad5d3949d31a181cd
(cherry picked from commit bf06232f4d)
It was possible for apps to put toast type windows
that overlay other apps which toast winodws aren't
removed after a timeout.
Now for apps targeting SDK greater than N MR1 to add a
toast window one needs to have a special token. The token
is added by the notificatoion manager service only for
the lifetime of the shown toast and is then removed
including all windows associated with this token. This
prevents apps to add arbitrary toast windows.
Since legacy apps may rely on the ability to directly
add toasts we mitigate by allowing these apps to still
add such windows for unlimited duration if this app is
the currently focused one, i.e. the user interacts with
it then it can overlay itself, otherwise we make sure
these toast windows are removed after a timeout like
a toast would be.
We don't allow more that one toast window per UID being
added at a time which prevents 1) legacy apps to put the
same toast after a timeout to go around our new policy
of hiding toasts after a while; 2) modern apps to reuse
the passed token to add more than one window; Note that
the notification manager shows toasts one at a time.
bug:30150688
Change-Id: Ia1dae626bd9e22541be46edb072aa288eb1ae414
