So the window will be notified to resize, then it may
compute a new non-zero requested size according the
result of the first relayout.
Fix: 147086315
Test: atest DisplayContentTests#testRequestResizeForEmptyFrames
Change-Id: Ibaef927b045041398c3ed0c069af930bd7466163
Rename android.util.TimestampedValue to android.os to avoid dependency
from android.util onto android.os, which is disallowed by lint.
Bug: 147012511
Test: boot
Change-Id: I4b84db03c8ad24bbef63e45d6d15fb306a10364e
Add a method to the DevicePolicyManager for finding out if the device is
an organization-owned device with a work profile (i.e. it has a work
profile but the work profile was created during the provisioning flow).
This method is currently available for privileged callers (system API),
since other methods (e.g. isDeviceManaged) are also restricted.
NOTE: Addition of GTS tests is pending final decision on whether this
will be public API or not.
Bug: 143518237
Bug: 144978467
Bug: 147340575
Test: atest FrameworksServicesTests:DevicePolicyManagerTest#testIsOrganizationOwnedDevice
Test: CTS tests that are on hold for now.
Change-Id: I26ce1de10844dc297924427a6d46df9208931ab0
RecognitionModes property field was not being properly sanitized from
hidl layer. Unit test updated to test this also.
Bug: 142070343
Test: atest SoundTriggerMiddlewareImplTest
Change-Id: I8452c38faaae79d768345cf0ef3d00a335a7a10e
We're no longer allowing any notification to be a bubble if the app is
foreground when the notif was sent; it must always fulfill the communication
policy.
- removed check & FLAG_BUBBLE when app is foreground
- removed the tests for FLAG_BUBBLE on foreground produced bubbles
- added a test to ensure that FLAG_BUBBLE doesn't happen just because the
app is foreground
- attempted to clean up some of the bubble helper methods
- no foreground service bubbles unless its a phone call (test for this
in CTS CL)
Test: atest NotificationManagerServiceTest
Test: atest NotificationManagerTest (needs CTS CL)
Bug: 138116133
Bug: 144352570
Change-Id: Idba370c23a3ccaa6479f61a94632f29d623a1e76
This adds a utility class that can track instantaneous app behavior and
manages count quotas for the owning system. A system service just needs to
create a tracker, set the limits, and call the relevant APIs to determine
what to do for each behavior. JobScheduler will use it to prevent apps from
calling JobScheduler.schedule() too often.
Bug: 135764360
Test: atest CountQuotaTrackerTest
Change-Id: Iacd4286bd7f4ab3fc428d8e2ec573671b287f225
The detector class to be used by the CountryDetectorService can be set
by overlaying config_customCountryDetector in the device config.
For automotive devices only.
Test: atest CountryDetectorServiceTest
Bug: 141626568
Change-Id: I158abd6397e3102d13e431ba043e8ce45061b64a
doAnswer type of stubing doesn't completely eliminate race conditions.
The failure happens because when answers are commited to
InvocationContainerImpl it uses a local variable invocationForStubbing
to save the stubbing method, which could be changed from a different
thread by a natural call into the mock/spy before answers are added to
InvocationContainerImpl.
Sequence of events:
1) [testing thread] Commiting stubbing by calling method into the
mock/spy. In this case it could be
DisplayContent#supportsSystemDecoration() in line 159 in
TestDisplayContent in this case. The call was intercepted by
MockHandlerImpl#handle() and further handled by
InvocationContainerImpl#setMethodForStubbing(), in which it already set
invocationForTesting field and didn't clear doAnswerStyleStubbing yet.
2) Another thread calls into the same mock/spy regularly. In this case
it is DisplayContent#getDisplay() as shown in the stack trace in the
bug. It's intercepted by MockHandlerImpl#handle() as well and likely it
thinks we're in the process of doAnswers style procssing and calls into
setMethodForStubbing(). It then mistakenly think we're stubbing
DisplayContent#getDisplay() and found the answer we offered isn't
compatible in the return value.
This is a caveat in Mockito thread safety, though it can be fixed in
Mockito if they're willing to do so. However it's certainly a lot faster
to fix it in our test code.
Also check the caller holds global lock in lieu of synchronization
clause because caller is supposed to be in tests with
RunWith(WindowTestRunner.class) annotation.
Bug: 144611135
Test: atest com.android.server.wm.AnimatingActivityRegistryTest
Change-Id: I8cc4b6ce11ad6c205309476c9eeb4db315f558d6
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: atest FrameworksServicesTests:RebootEscrowDataTest \
FrameworksServicesTests:LockSettingsServiceTests \
FrameworksServicesTests:RecoverySystemServiceTest \
FrameworksServicesTests:RebootEscrowManagerTests
Test: use fake OTA console app to apply update
Change-Id: I59df6942b27ea2bdd11b757922f5169085a325f0
range of the bytes to be read and parsed.
Note that the tests for the RuleIndexingController will be implemented
when its identifyRulesToEvaluate method is implemented.
Bug: 145493956
Test: atest FrameworksServicesTests:BinaryFileOperationsTest
Change-Id: Ie43e292f1a19c6c067a61d1d03da911d67620516
- Use WC#getDisplayContent instead WC#mDisplayContent in
WC#okToAnimation and WC#okToAnimate.
- Fix some places that calls isAnimating() needs to add PARENTS flag.
- Add unit tests to verify Task / Stack can applyAnimation with expected
animation state.
- In Task#createRemoteAnimationTarget(), use WC#getTopMostActivity to
get top most activity rather than using getTopVisibleActivity, to
prevent closing activity may not get corresponding activity instance
case.
- Fix WC#isWaitingForTransitionStart and WC#isAppTransition won't get
correct result when animating app transition on Task / TaskStack container.
- To ensure onAppTransitionFinished will be called when enabling
hierarchical animation, needs to let activity.onAnimationFinished()
also be called.
- Implement Task#getAnimationBounds to get stack's bounds when
appStackClipMode is STACK_CLIP_BEFORE_ANIM.
Bug: 142617871
Bug: 131661052
Test: atest WindowContainerTests
Change-Id: Id97087819cab54ba35fb4b9ae4b5b95a572ad377
