Previously the cached state highly depends on the path of oom-adj
update, that causes potential lock contention between WMS and AMS.
Because the original major problem might be the heavy IO operations
by accessing the resources when handling configuration change from
dozens of non-important processes. The client side config deferring
could be enough help for the case.
This is also the last removal of holding WM lock in the path of
oom-adj update.
Bug: 143432064
Bug: 159104503
Test: ActivityThreadTest# \
testHandleProcessConfigurationChanged_DependOnProcessState
Change-Id: Iefc9e02aa374bc74f263cf0c10612f89b864530b
Do not use USES_POLICY_PROFILE_OWNER / USES_POLICY_DEVICE_OWNER.
Instead, use explicit methods for checking if the caller is
the Device Owner or Profile Owner.
USES_POLICY_PROFILE_OWNER is confusing since internally in the
DevicePolicyManagerService, it implied a Device Owner is also a
Profile Owner, which is not always what the caller expected.
This is the first phase of the refactoring, removing external calles'
dependency on these constants. The next phase will remove them
internally completely in favour of an implementation that
accesses mOwners directly.
There are no functional changes in this CL.
Bug: 163028934
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Change-Id: I57c8465d190a3b4b130d57fd622cc93eaeb9c717
This CL is aimed to refine the AM/ATM API surface. The other
stack naming internally spread in AM and ATM will be covered
in later CLs.
Also Consolidate #removeStack() with #removeTask().
Bug: 157876448
Test: existing tests
Change-Id: I1254f972dab3bbe66a736a0402eebce9d0fb1496
Accpet the event time from RecentsAnimation#startRecentsActivity.
Also remove unused method of recents animation in activity manager.
Bug: 169221287
Test: Enable statsd log: "adb shell cmd stats print-logs"
Touch gesture navigation bar.
adb logcat | grep statsd | grep "(48)"
The line may contain 0x100000->4[I] 0x110000->20[I]
that means 4=by recents and 20=latency 20ms.
Change-Id: Ia188a6a3b0dab9edaa0052df3b18508f8cc895d3
Add PictureInPictureParams to RemoteAnimationTarget, which would allow
Launcher to determine whether the current app can auto enter PiP.
Bug: 143965596
Test: N/A
Change-Id: I5bc8dd29e9e4e7f3acfe9b841e64344211f57758
Refactor the DevicePolicyManagerService such that every method
that requires the ActiveAdmin associated with a profile owner on
an organization-owned device does the following:
* Checks if the caller is a profile owner on an org-owned device, or a
device owner.
* Get the ActiveAdmin associated with the profile owner or device owner.
This is instead of calling getActiveAdmin with the org_owned profile
owner policy, which is now removed.
For the most part, this change does not affect DPMS functionality.
The few methods that were specific to org-owned devices with a
managed profile are now properly restricted and cannot be called
by a device owner.
Bug: 163028934
Test: atest FrameworksServicesTests:DevicePolicyManagerTest
Test: atest com.android.cts.devicepolicy.OrgOwnedProfileOwnerTest com.android.cts.devicepolicy.MixedDeviceOwnerTest
Change-Id: I9463499d9e343b4e52d6f9cdbe1d618e58f59a49
New APIs are being exposed for use by SetUp Wizard, which requires
System APIs.
The APIs enable the calling app to determine the capabilities for /
config of the current user that affect time zone detection and then
alter them.
This commit also contains changes to the Shell package needed for the
CTS tests being added to test the new APIs. See the associated CTS
commit for details.
The primary usecase:
The rules for who can do what and when for time zone detection are
becoming more complicated, and device and user capabilities will be
affected by compile time constants, device config (resources) and device
hardware. By exposing this API, the complex logic can be encoded in one
place (the system server), rather than duplicating them in multiple
client apps.
These APIs are also intended for use by SettingsUI (and the various form
factor versions of that), but settings apps do not require them to be
marked with @SystemApi.
Bug: 159891384
Test: atest CtsTimeTestCases
Change-Id: I1eb6a68a74217106f81cb9525ad9370c805eecf2
This commit introduces the TimeManager API class. It is intended to
provide access to the time and time zone detector services, which
historically have had their own (internal) API classes to access them.
This commit contains various fixes to the listener handling logic
noticed while testing the APIs.
The first APIs on TimeManager are being exposed for use by SetUp Wizard,
which requires System APIs.
The APIs enable the calling app to determine the capabilities for /
config of the current user that affect time zone detection and then
alter them.
The primary usecase:
The rules for who can do what and when for time zone detection are
becoming more complicated, and device and user capabilities will be
affected by compile time constants, device config (resources) and device
hardware. By exposing this API, the complex logic can be encoded in one
place (the system server), rather than duplicating them in multiple
client apps.
These APIs are also intended for use by SettingsUI (and the various form
factor versions of that), but settings apps do not currently require
them to be marked with @SystemApi.
Bug: 159891384
Test: atest services/tests/servicestests/src/com/android/server/timezonedetector/
Test: atest android.app.time
Change-Id: I9b59099748e2391c180e124edf83fa521beb1b51
Any PI that needs to be used with inline reply or bubbles needs to keep
their PI mutable. This change updates the messaging around FLAG_MUTABLE
docs and logs at the mutability flag check to add this use
case.
Bug: 160794467
Test: docs change, green builds
Change-Id: I641b35f92de5843be2fad3ef4621ffc9c6456899
For future releases, we will require that either FLAG_IMMUTABLE or
FLAG_MUTABLE is defined when a PendingIntent is created.
The check only results in a log.e() for now while we notify, identify,
and update major PendingIntents. We will add a stricter
IllegalArgumentException soon.
- Define FLAG_MUTABLE
- Add a check and log.e that either FLAG_IMMUTABLE or FLAG_MUTABLE is
specified on creation for future releases
- Update api/current.txt and non-updatable-api/current.txt to include
FLAG_MUTABLE
Test: atest PendingIntentTest
Bug: 160794467
Change-Id: I18b21903c7cd0946dce5d7ca7860258612d9f98f
Retrieves the last interaction for a given conversation (provided
package, userId and shortcutId).
Test: atest DataManagerTest
Bug: 169412531
Change-Id: Ie6f6d87e9ade78b99a18deb2959d0c699579c5f2
Expose this method for module libraries. It's needed to support a public
method in TelephonyProvider that doesn't require any permissions.
Test: atest RoleManagerTest#smsRoleHolderAvailableWithoutObserveRoleHolders
Fixes: 169350676
Change-Id: Ia2725dc5aa0de74b2cf67ecd0666917ae27adda9
This API allows the test to create
contention on AM, PM and/or WM locks.
Test: a prototype lock contention test
Bug: 168630376
Change-Id: I656b6b412d517cb3b3b16367d8712f78ccbc33d8
Revert "Add a check for FLAG_MUTABLE and FLAG_IMMUTABLE being se..."
Revert submission 12627798-define-flag-mutable
Reason for revert: Makes wembley device unusable by killing UI, also kills Bluetooth repeatedly
Bug: 169241864, 169239341
Test: Locally reverted and wembley now has UI and no Bluetooth crashing messages
Reverted Changes:
I2ffbc6859:Add a check for FLAG_MUTABLE and FLAG_IMMUTABLE be...
I1f1f72c6c:Define FLAG_MUTABLE and add a compat change for ex...
Change-Id: I0b1f0eadce97a1f7bbd17768f5ee491b3871b10f
Tests sometimes fail due to a shell command failing, bet we don't get the
appropriate result from the command run itself, which leads to confusing
states and challenging troubleshooting.
E.g. jobscheduler reports its failure only via stderr.
This introduces a utility that fails with the relevant command output,
should something be printed to stderr.
Test: atest AutoRevokeTest
Bug: 168843991
Change-Id: I5e354c1b88ca3ceeeda2d5500b62c421174fd57c
This reverts commit e49aa726f0.
Reason for revert: We've decided not to have this in the QPR.
Bug: 164440539
Change-Id: I72ca946f1a5be937b3f3bed746e4251fa9257891
For future releases, we will require that either FLAG_IMMUTABLE or
FLAG_MUTABLE is defined when a PendingIntent is created.
The check only results in a log.wtf for now while we notify, identify,
and update major PendingIntents. We will add a stricter
IllegalArgumentException soon.
- Define FLAG_MUTABLE
- Add a check and log.wtf that either FLAG_IMMUTABLE or FLAG_MUTABLE is
specified on creation for future releases
- Update api/current.txt and non-updatable-api/current.txt to include
FLAG_MUTABLE
Test: atest PendingIntentTest
Bug: 160794467
Change-Id: I1f1f72c6ce22358e98e9f38be2fb98b27e60898c
* changes:
Revert "Give all non-package services the power to interact accr..."
Revert "Check cross-user interactions for permissions and app-op..."
Revert "Invalidate package/permission cache if cross-profile app..."
Revert "Add dedicated host side tests for permissions and appops"
Revert submission 12439864-PermAppOpsCrossUserCheck-Fixed
Reason for revert: Bug 169044600
Reverted Changes:
I95d015e01:Invalidate package/permission cache if cross-profi...
I2a8a84f57:Check cross-user interactions for permissions and ...
Ie8f0db231:Give all non-package services the power to interac...
I11af434a8:Test package/permission cache invalidation when IN...
Ib6d609a4d:Add dedicated host side tests for permissions and ...
Change-Id: Iea5eeded0ee5caf5383bb0e749133d4fef18d392
The application may get Resources instance from Resources.getSystem()
and context.getApplicationContext().getResources(). Since fixed
rotation is introduced that allows an activity to start in a different
rotation than the current display, when using getConfiguration() and
getDisplayMetrics() of these Resources instances, the orientation
and metrics need to be the same as current display is rotated.
Otherwise the app may show unexpected UI layout.
Although it is not recommended to use global resources/config for
activity. One of the goal of fixed rotation transform is to simulate
the app is started in a rotated environment, so this CL makes the
configuration and display metrics of system resources are consistent
with application and activity for compatibility.
About WindowProcessController and ActivityStackSupervisor:
The process configuration passed to LaunchActivityItem may be
associated from activity. if the sequence number of configuration
is overridden by activity, the configuration may be ignored when
launching the activity because the sequence number isn't larger
than the previous process configuration. Although there will be a
ConfigurationChangeItem later to update correct state, the app may
get the intermediate state with old configuration and metrics.
About ResourcesManager and DisplayAdjustments:
There are 2 new fields appWidth and appHeight added to
DisplayAdjustments#FixedRotationAdjustments because the display
metrics from Resources.getSystem() is independent from activity
configuration. Only window manager knows the rotated size, so
the values need to send to client and then ResourcesManager takes
the adjustment to change the global display metrics.
About WindowToken:
When fixed rotation is applied on the token, send the
FixedRotationAdjustmentsItem first so the later configuration
change can pick the adjustment at ActivityThread. And because the
registration of activity configuration only occurs on add/remove
activity, if it is only switching to another existing activity in
different orientation, the process configuration still needs to
be updated.
About ActivityThread:
The code flow for a rotated activity (DA = display adjustments):
- Launch new activity
handleLaunchActivity: override app DA
handleConfigurationChanged: adjust global display metrics by DA
performLaunchActivity
createBaseContextForActivity: override activity DA
- Resume existing activity
handleFixedRotationAdjustments: override app and activity DA
handleConfigurationChanged: adjust global display metrics by DA
handleResumeActivity
Also some minor corrections:
- Set missing rotated max bounds.
- Fix wrong display metrics adjustment that xdpi and ydpi should
not be swapped because they are physical attributes.
Bug: 167564038
Test: atest DisplayAdjustmentsTests
AppConfigurationTests#testRotatedInfoWithFixedRotationTransform
WindowProcessControllerTests#testProcessLevelConfiguration
DisplayContenTests#testApplyTopFixedRotationTransform
Change-Id: I60bedc7e09f54683d5e857ccc51402d5d144cd9e
* changes:
Invalidate package/permission cache if cross-profile app is is changed
Check cross-user interactions for permissions and app-ops operations
Give all non-package services the power to interact accross users
