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
This change will affects 2 types of apps: autofill service implementations
and apps that use autofill APIs.
Since just the former is known to be used at the moment, we're not trying
to keep backward compatibility with the latter.
Bug: 35956626
Test: CtsAutoFillServiceTestCases pass
Test: android.provider.SettingsBackupTest pass
Change-Id: Ia720083508716deae9e887f9faa7ae7c5a82f471
But only when targeting O; if they're old apps then log and pass
a soft failure message to their callback.
Test: builds, boots
Bug: 35749102
Change-Id: I6c6b5a37c23669e7b1ed3c30207bca610821eb1f
Since splitting home stack into home and recents, some problems where
the home stack would appear above when home stack is not visible. This
would cause home stack to be below docked stack and think home is
visible when it is not. Then docking an app would minimize the docked
stack and go into a wierd state when recents is resumed/launched.
When docked stack is used, it will verify that recents is created and
avoids seeing home stack as visible when below docked stack with at
least 1 stack in between. Whenever an app is docked, this will make sure
home stack is below recents.
This will fix some parts of the cts tests that use
"adb shell am stack move-task <taskId> 3 true" and avoid glitches with
the docked stack.
The following scenarios were tested:
- Boot and dock and app without starting recents
- Dock after launching an app (when recents already created)
- Toggle dock with "adb shell am stack move-task <taskId> 3 true" and
undocking multiple times
- Dock with long press recents
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test
CtsServicesHostTestCases
android.server.cts.ActivityManagerDockedStackTests
Bug: 35351074, 35145587
Change-Id: I6ac25c64f7d1050ea2260631ff4c052fcca3f185
But only when targeting O; if they're old apps then log and pass
a soft failure message to their callback.
Test: builds, boots
Bug: 35749102
Change-Id: Ifecf7108397444e88763f404a4b5f3fdc48443bb
Fixes a bug where notifications with color spans would not show
the text properly because we inverted the background. Now we invert
the color spans the app put on the text for the ambient view.
Fixes: 35705172
Bug: 30876804
Test: receive gmail notification, observe that subject is visible on ambient display
Change-Id: I602335562346759d62d2a69a55f3ac9d1be735a9
Now that AutoFillType does have any logic (since the "subType" logic was moved
to AutoFillHint), it makes more sense to get rid of the type and use constants
directly.
This change creates the contants and "pseudo-deprecate" the old stuff: it's
still available because some clients are using it, but it will be removed once
they migrate.
Bug: 35956626
Test: CtsAutoFillServiceTestCases pass
Change-Id: I0efe7f0cc101c86164a18c85903bb871e1f13ba2
We simplified the way we track whether or not a dex file is used by
other apps. DexManager in the framework keeps track of the data and we
no longer need file markers on disk.
Test: device boots, foreign dex markers are not created anymore
Bug: 32871170
Change-Id: I3660e2f3913a73904181449c2d910af0a0477950
waitToFinish is called when the main thread enters the stopped state. At
this time we need to make sure to flush all shared preferences to the disk.
Usually this is not problem as they were asyncronously persisted. In
rare circumstances it can happen that the shared preferences are not
flushed yet.
Disk writes on main thread are quicker then waiting for the background
thread to do the write for this thread. Hence it is ok to write on the
main thread here.
Test: android.content.cts.SharedPreferencesTest
Change-Id: Ice8c0425a60005d1e4b150fa74e55e753dead6b8
We already only issue a warning if the xml cannot be parsed. So if the
xml could be parsed by the result could not be cast to a map, we should
also only issue a warning.
Also log the corrupted file as this is called on an async thread and it
is not clear what file is affected.
Bug: 29006064
Test: Just logging changes.
Change-Id: I503fd4ee9b905f72668136b4d98c819cd7f9021b
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
Bug 32758881
Bug 34264461
When destroying the LoaderManager, the host was not being cleared.
The host was being leaked and this leaked the Activity.
When a LoaderManager is reused, for example with an orientation
change, the host was updated, but it wasn't started. This
adds a test for that case to ensure that when a reused
LoaderManager is loaded that it is properly started.
Test: Ib90f14e16083916a21a25ce87a4dd29ab9a33878
Change-Id: Id4c8afab5db0a78bbff376d597be294a6e3dbcba
- Renamed deepcopy to deepCopy.
- Clarified docs about when a shallow vs. deep copy happens.
Test: booted and ran
Change-Id: I2b4400770d781ff51423cd1c860454742e1d3c9c
* Change name to InstantAppResolverService
* Left old service in place to handle existing client
[to be removed prior to O launch]
* When resolving phase II, return a list instead of a single item
Bug: 34763730
Test: Build and verify resolution occurs w/ legacy & new resolver service
Change-Id: Ieccaf91538bd91c04f4be4e35d8264619d7cd6d7
With this API, the system can determine whether a CA cert was
installed by the user or the user's DO/PO.
Bug: 32692748
Test: unit tests (see DevicePolicyManagerTest.java for invocation)
Test: cts-tradefed run cts-dev --module CtsDevicePolicyManagerTestCases
Change-Id: I3bcae5ac18ec2b110154184fc515df804fd73da6
