The default display is used by some tests that exercise features only
functional only on the default display (like policy rotation). This CL
makes this display not get removed with the created test displays and
ensures no collision in id space from a previous test run (done in the
test setup).
Change-Id: Ia14b9c023c779d263283fe8c7b512dca17ff312f
Fix: 36385757
Test: bit FrameworksServicesTests:com.android.server.wm.StackWindowControllerTests#testRemoveContainer_deferRemoval
New apps should create their own channels.
Not using channels will silently fail.
STOPSHIPS:
Throw to provide better feedback for developers.
Delete the default channel for all apps that target O.
Test: runtest systemui-notification
Change-Id: Ic93f103efe397f563eaaf1c2e7d8bf9093b2b2e1
Replace the existing Vibrator APIs with a new class to encapsulate the
haptic effect information, and add the ability to control the vibration
strength.
Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.cts.VibratorTest
cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases -t android.os.cts.VibrationEffectTest
runtest systemui-notification
Manual testing with $T/google_experimental/users/michaelwr/Vibrator
Bug: 30961353
Change-Id: Idbb9864a7b084c85e7b7de3257a0e6b40d9d91d6
The intent is for this not to cause any behaviour changes, just to
make it easier to see what is going on with the code.
Permissions are checked in DevicePolicyManagerService. All calls to
CertificateMonitor are privileged.
Test: runtest -x frameworks/base/services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases
Change-Id: I98224087315a62234732f08b53fe91884be86386
Let's have several separate contexts instead of doing strange things
with package names in one monolithic context representing every single
user on the device at once, sometimes multiple times in the same call.
Syntax looks like:
runAsCaller(callerContext, dpms, (dpm) -> {
assertSomething(dpm.doSomething(caller, param));
});
When a caller calls into DevicePolicyManager here's what happens:
PRE
- a new DevicePolicyManager is created with the caller context
- service context callingIdentity is saved
- the callingUid, callingPid, and callingPermissions are added to the service context
TEST
- client-side test code interacts with DevicePolicyManager using the caller context
- server-side coder under test runs as DevicePolicyManagerService using the service context
POST
- service context callingIdentity is restored to what it was before the test.
This should be easier to reason about.
Test: runtest -x frameworks/base/services/tests/servicestests/src/com/android/server/devicepolicy/DevicePolicyManagerTest.java
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases
Change-Id: I148e3f298b0a958639ce261e9cf91f6eb49fae4d
There is some flakiness in View#onConfigurationChanged callback -
if ViewRootImpl receives config update earlier than ActivityThread,
it may not detect the configuration change and skip inner updates.
Also now ViewRootImpl assumes that it receives the global config as
a param, but instead it gets merged config from WM. This means that
ViewRootImpl#sConfigCallbacks was sending incorrect values to the
recipients.
This CL switches to sending global and override configuration to the
client separately. Also in case if there is a corresponding activity,
it first updates it and waits for update callback to ViewRootImpl.
This way global config and override config for activity will always
be set first and resources will be updated before inner state of
ViewRootImpl is updated.
Bug: 35870157
Bug: 34164473
Test: android.server.cts.ActivityManagerDisplayTests
Test: testOnMovedToDisplayCallback
Change-Id: Ic9e7541cf25ecfac6ec90e48f7efb0ece91f657e
- Allow apps to delete notification groups (which cascade to delete all
channels therein)
- Allow apps to get their groups, so they know what they might want to
delete
- Don't throw if someone tries to delete something that already doesn't
exist.
Change-Id: I5f6e25497c5da1e57b52737586e86097332f88f9
Fixes: 36245468
Fixes: 36127382
Test: runtest systemui-notification, cts
Apps can listen for the LOCALE_CHANGED broadcast to
change names if needed.
Fixes: 35336590
Test: runtest systemui-notification, cts, manual
Change-Id: I62d2778f61e99200692755a6f268828a374837e6
Mock DevicePolicyManager in the unit tests.
Bug: 34600579
Test: runtest frameworks-services -c com.android.server.SyntheticPasswordTests
Change-Id: Ieca30a74d7d9d867994e912d188231510f54e76c
This CL adds the APCT tests within this project to
a similar suite as CTS known as device-tests.
The current method of running APCT tests in the infrastructure
is unaffected.
Bug: 35882476
Test: `make dist device-tests -j` and local builds of
continuous_instrumentation_tests & continuous_native_tests
Change-Id: Ifa382fe691842c1cd76897775b9e2a1653449eb5
Previously this test was marked as blocked by b/35034729. This bug
has been fixed, however the test still fails due to other issues
addressed here.
Addressed issues are as follows:
1. Updating rotation by display manager requires a display with the
default display id present. This display is removed during setup. The
first id to be used by a display after this point is the
default id + 1. We already have logic in place to avoid collisions so
it is safe and correct to start out at the default id.
2. Without allowing the animator to complete its steps after a
rotation, future rotations will be deferred. We must simulate the
steps taken by the and resulting from the animtor. These include
marking the orientation change as complete and performing a surface
placement afterwards.
Bug: 35034729
Test: bit FrameworksServicesTests:com.android.server.wm.AppWindowTokenTests
Change-Id: Ib01c047ac49982a4a3c1debaa3cee1b7b9b53632
Harmless issue but which can spam the logs.
Test: mostly manual since the check is buried deep inside and cannot be
verified accurately. I added another test to DexManager to stress that
code path and then checked the logs.
Bug: 36117123
Change-Id: I1a878a200f3f726dfaa85f1bed1398acc8dce979
This allows to avoid A11yManager -> A11yManagerService IPC, when there's no
subscribers to a given event
Test: steps:
- Enable A11yManager.DEBUG
- Navigate through a few random activities
- In logcat, ensure log messages are present, notifying that certain events
won't be dispatched
Change-Id: Ia019fb66053f10095b3651407d09de8e89cdd227
This CL moves rotation tracking from WindowManagerService to
DisplayContent. This way displays can be rotated independently and
rotation of the main display won't affect rotation of secondary
ones.
Bug: 34242678
Test: android.server.cts.ActivityManagerDisplayTests
Test: testRotationNotAffectingSecondaryScreen
Change-Id: Ic46aaa523482b31ff5ec77f0c2908ceda1156fc0
This procStateSeq is associated with the process state change of
an uid and will help in identifying if network policy rules have been
updated for a process state change.
Bug: 27803922
Test: runtest -c com.android.server.am.ActivityManagerServiceTest
frameworks-services
Change-Id: Iaab8d004f476b96f28d08c886c7b0a6b585b9fef
Exposing actions from the PIP InputConsumer to accessibility,
stripping all actions from a covered PIP app, and adding the
InputConsumer's actions on the PIP app's root view.
We were also using an "undefined" accessibility ID to mean
three different things: a root view, a host view of a virtual
view hierarchy, and a truly undefined view. I've introduced
new values for cases where the id could be defined.
Also gathering all window IDs into one place to reduce the
chance of collisions.
Bug: 34773134
Test: In progress. Current cts passes.
Change-Id: I97269741a292cf406272bf02359c76c396f84640
(cherry picked from 76e319f015c2b43498ce3ce610a253d63e76cbf3)
Some additional internal only refactorings were done as well.
Bug: 32912773
Test: make checkbuild
Change-Id: I96e3da967fad731fc8f39bde9db95f50ab7353fb
This reverts commit daab865344fcfa45fe2789e43462f730a44fba64.
IMMS is currently sending wrong target candidates, so we need to revert
this until we figure-out what is going on there :(
Bug: 31559891
Bug: 35903813
Test: DisplayContentTests
Change-Id: I5c5beff4bac1b0781fa6663b13ff0dfe83a7806b
This also catches any potential state exceptions which may
occur when errors occur during storage queries on a package.
This should stop the crashes.
Change-Id: Idab92434f74eaf44ba7b3fdbbc6c2c1ac9b10ee2
Fixes: 36075582
Test: FrameworkServicesTest & manually verified file is populated
This knob is designed to effectively tune the battery saver.
Bug: 34693888
Test: FrameworksServicesTests
Change-Id: I9fd7896f59fabd9baf649cdb12f01b1baaf4c34b
The BatterySaverPolicy is designed to consolidate all battery saver
knobs into a central location. Usually it is consistent to
mLowPowerModeEnabled unless it gets different data for specific
service. By adding these knobs, we can effectively tune the battery
saver.
This cl sets up the framework for BatterySaverPolicy and updates
following service to get battery saver data from BatterySaverPolicy
1. GnssLocationProvider
2. VibratorService
3. WindowManagerService
4. BackupManagerService
5. SoundTriggerService
6. NetworkPolicyManagerService
Screen brightness will come in a following cl.
Bug: 34693888
Test: FrameworksServicesTests
Change-Id: I6b040e93391614b44d136a485faa4a332c396e51
Make sure Settings.Global.NETWORK_RECOMMENDATIONS_ENABLED reflects
the current active scorer state. When valid the setting will have a
value of 1, when invalid it will be 0 (or more
accurately not 1, see below).
Introduced a new valid setting value, -1, which indicates the feature
has been forced off.
Test: runtest frameworks-services -c com.android.server.NetworkScorerAppManagerTest
Test: runtest frameworks-services -c com.android.server.NetworkScoreServiceTest
Bug: 35896421
Change-Id: I271725f798e5d0acc7c08c79678dba5115f8faad
Settings.Secure.DEFAULT_INPUT_METHOD is a misnomer. It does not really
record a permanent default of any sort - it just indicates the currently
chosen IME. Thus, isDefaultInputMethodSetByOwner() should more
appropriately be called isCurrentInputMethodSetByOwner().
Furthermore, it turns out that setting a different IME for a user and
the user's work profile is unsupported. Thus, it is sufficient for the
intended use case to just retrieve the calling user's default IME.
There is no need for a |user| parameter.
Bug: 32692748
Test: unit tests (see DevicePolicyManagerTest.java for invocation)
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases
Change-Id: Ia0846d38a1361042429dae7430a8b055575ef2e0
