Update FLAG_ONLY_ALERT_ONCE docs to match implementation
from Android P and onwards.
Bug: 222328375
Test: atest BuzzBeepBlinkTest
Change-Id: Ic058b8265551362b04b9cd0363e43a4c08ecd736
We read the wallpaper within the synchronized block, this is a long time
operation, might block the other thread who is going to obtain the lock.
So we have to move the operation beyond the synchronized block.
Bug: 228435216
Test: atest WallpaperManagerTest#testPeekWallpaperNotBlockingOtherThread
Change-Id: Ic2a947b473710ffe68db436586769858950588a4
We initially were using PACKAGE_USAGE_STATS permission to guard
the API BroadcastOptions.recordResponseEventWhileInBackground()
but changed it's implementation to use the new
ACCESS_BROADCAST_RESPONSE_STATS permission later but didn't update
the annotation to specify the new permission.
Bug: 228894230
Test: treehugger
Change-Id: I5142e2d2f754e8014c0c291d56b5ec2254449e77
Notification API downscales oversized icons in all formats except in MessagingStyle. This seems to be an oversight that can cause massive memory usage.
This downscales avatars to a reasonable size if they're too big.
Bug:193720474
Bug:221890932
Test: atest NotificationTest
Built a test app with 4000x4000 avatar icon.
Memory usage went from 250MB to ~170KB per notification.
Change-Id: I35377cdb5d61ee6e23fccc2bffb5d3aec6ca2b7d
Even if the app's notifications are disabled.
Test: NotificationManagerServiceTest
Test: NotificationInfoTest
Test: manually call device
Fixes: 227456870
Change-Id: Ib218e57d585a6066ddbc713d2d3a8445ac959ad2
Bug: 227653108
This adds a helper class that can reduce much of the boilerplate in
code that uses IpcDataCache (or the internal-only variant,
PropertyInvalidatedCache). See the changes to DevicePolicyManager for
example usage.
Two PropertyInvalidatedCaches APIs are exposed for testing. The
method createPropertyName() is changed so that apis like "Foo" are
converted to "foo", not "_foo".
Unit tests for the new behavior are added to IpcDataCacheTest.
This was manually tested by dumping the cache info from builds with
and without this change. Special attention is paid to the
DevicePolicyManager caches. The same caches were found (as identified
by their key and api) and the caches were enabled/disabled the same.
In the course of testing, multiple instances of DevicePolicyManager
caches were observed. Cache performance is better if the caches are
static; making them static will be addressed in b/228452829.
Test:
* atest FrameworksCoreTests:IpcDataCacheTest
* atest FrameworksCoreTests:PropertyInvalidatedCacheTests
* atest FrameworksServicesTests:DevicePolicyConstantsTest
* atest FrameworksServicesTests:DevicePolicyEventLoggerTest
* atest FrameworksServicesTests:DevicePolicyManagerServiceMigrationTest
* atest FrameworksServicesTests:DevicePolicyManagerTest
* atest FrameworksServicesTests:EnterpriseSpecificIdCalculatorTest
* atest FrameworksServicesTests:OverlayPackagesProviderTest
* atest FrameworksServicesTests:OwnersTest
* atest FrameworksServicesTests:PolicyVersionUpgraderTest
* atest FrameworksServicesTests:SecurityEventTest
* atest FrameworksServicesTests:SystemUpdatePolicyTest
* atest FrameworksServicesTests:TransferOwnershipMetadataManagerTest
* atest MixedDeviceOwnerTest#testIsDeviceOrganizationOwnedWithManagedProfile
* atest MixedDeviceOwnerTest#testSetKeyguardDisabledFeatures
* atest MixedManagedProfileOwnerTest#testIsDeviceOrganizationOwnedWithManagedProfile
* atest MixedManagedProfileOwnerTest#testNetworkLoggingDelegate
* atest MixedManagedProfileOwnerTest#testSetKeyguardDisabledFeatures
* atest OrgOwnedProfileOwnerTest#testIsDeviceOrganizationOwnedWithManagedProfile
* atest OrgOwnedProfileOwnerTest#testNetworkLoggingDelegate
* atest OrgOwnedProfileOwnerTest#testSetKeyguardDisabledFeatures
* atest android.devicepolicy.cts.DevicePolicyManagerTest
* atest android.devicepolicy.cts.NetworkLoggingTest
* atest com.android.cts.devicepolicy.DeviceOwnerTest#testAdminActionBookkeeping
Change-Id: I2f4fe4ed25db5fb3100334b9d2ce748ee928c10d
This will be used to let the application thread
know whether or not to block for network rules to
be updated when coming to the foreground.
Bug: 226299593
Test: atest tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Change-Id: I9bff481a0026fb57af8dbee580e617c8410f9ebe
We disable these four test cases temporarily from presubmit.
We will add back after fixing test fail.
Bug: 225076204
Test: atest CtsVoiceInteractionTestCases
Change-Id: I0cdc92cb37db305df75947502e3569bfc38795a3
The input injection mode for pointer events in sendPointerSync() was
accidentally changed to WAIT_FOR_RESULT instead of WAIT_FOR_FINISH in
ag/17506923, causing test failures. Change it back to WAIT_FOR_FINISH.
Bug: 228203157
Bug: 228201593
Test: atest HoverTest
Change-Id: I2d3a77621290509d5be6279ee450e1881bd9d84d
Starting from T, a MotionEvent's default source is SOURCE_CLASS_POINTER.
This means injecting a newly obtained MotionEvent into
sendTrackballEventSync would cause the exception to be triggered.
Adding such an exception doesn't make sense in T, since it adds the
additional precondition to sendTrackballEventSync that the MotionEvent's
source must correctly configured. This precondition did not exist before,
so we remove the exception.
Bug: 228194124
Test: atest android.app.cts.DialogTest
Change-Id: I039e30e6c768ce11c64d077d20373da12f27b72f
Don't use the notification ID to determine if it's being
canceled or not.
Bug: 203105544
Test: atest FrameworksMockingServicesTests:BackgroundRestrictionTest
Change-Id: I0ddcb7de57800c5f8b69100353ba7f71157a5448
Previously, any app could inject input events into the system via the
IInputManager#injectInputEvent API. The injection was only allowed if
the input event targeted a window owned by the same UID as that of the
process calling the API. This had drawbacks metioned in the bug.
Here, we change the input injection security model so that the signature
permission INJECT_EVENTS is required to inject events. This permission
is given to the system and the shell, so input injection can still be
done through the 'adb shell input' command. We also allow injection from
instrumeted processes where the instrumentation source has the
permission. For exmaple, running a test from the shell allows for the
test to inject events.
We also add support for a targeted injection mode, where the input
injection succeeds only if the target window for the event is owned by
the provided UID. This allows us to support injection from the
Instrumentation class, which only allows for injection into windows
owned by the same UID. In contrast to this, injection from the
UiAutomation class will target all windows, including system and spy
windows.
Bug: 207667844
Bug: 194952792
Test: atest inputflinger_tests
Test: atest WindowInputTests
Test: manual with test app: app cannot inject navigation gestures
Change-Id: Ib0d66eff3fc2f061e7c0d3b7e139a841a9bcebc7
Test: m -j update-api. Build and flash and test back behavior throughout
the system.
Bug: 227500290
Change-Id: Ibdb13d02e044741d05d99f1cad96e43dc0129fe4
There can reset the system bars color once the splash screen window is
going to be removed, so the real system bars color can be
controlled by app, without waiting for the reveal animation.
Also clear this effect when transfer splash screen to client, so client
can control the color on their own.
Bug: 196550450
Test: verify no status bar color changed when playing reveal animation.
Change-Id: Ibb353d350fa2921188c8c4b54f8e029ee3869c16
It's possible for an app to come to the TOP state before
the oomAdj computation is done and we cannot wait for
oomAdj computation to complete and then inform NPMS about
the state change. So, inform NPMS early about the state
change when we know the app is going to the TOP state.
Bug: 226299593
Test: atest tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Change-Id: I5d582618652cead179c419f7fe084283dd89d514
