The check misclassifies processes as apps (it only checks lower bound,
whereas there's also an upper bound of 20000-1).
At the same time it is redundant. It was originally introduced to
quickly filter out processes that were known to AM, but nowadays we
explicitly remove these from the set of processes to scan.
Bug: 158470048
Test: manual test, android.cts.statsd.atom.UidAtomTests#testProcessMemorySnapshot, 'android.cts.statsd.atom.UidAtomTests#testProcessMemoryHighWaterMark
Change-Id: Ie24107ccea31efae40277d8d46fa36f978f2481e
When adbd restarts while wireless debugging is enabled, the port number
may change.
Bug: 158219145
Test: Manual.
1) Enable wireless debugging in Settings and validate port in UI via
> adb shell su 0 netstat -plnt | grep LISTEN
2) Restart adbd: > adb root
3) validate port again (may have changed)
Change-Id: I2b646a61eff417f6bc53018ffbe1f7243981d745
slice permissions.
There are three call-sites of SliceClientPermissions#createFrom:
1) SlicePermissionManager#writeBackup and
SlicePermissionManager#readRestore ensures the client tag exists before
calling SliceClientPermissions#createFrom.
2) SlicePermissionManager#getClient is expecting Exception from
SliceClientPermissions#createFrom when it fails to parse the xml, and
creates clean permission object accordingly. This CL ensures an
exception was thrown when the xml parsing cannot be completed.
Bug: 121144871
Test: run test suite in forrest
frameworks/base/services/tests/uiservicestests/src/com/android/server/slice
Change-Id: Id7a239f16b95d16ba17bf651d474dec86492ef47
* if no apps are suspended by the DO prior to migration, nothing
changes
* if some apps were suspended by the DO and the DPC targets R+
via DPM.setPackagesSuspended(), this will result in personal
apps suspended explicitly by the PO DPC as if it called
DPM.setPersonalAppsSuspended(). The apps will stay suspended.
* if the DPC target SDK is below R, the apps will be unsuspended
because the DPC won't have a way to unsuspend them. And the
user will be stuck with suspended apps.
+ when unsuspending apps, don't collect the list of apps subject
to suspension, but rather unsuspend all that is suspended. It
is more robust, e.g. when some app stops meeting the
conditions, e.g. not SMS app anymore.
Bug: 157270093
Test: com.android.server.devicepolicy.DevicePolicyManagerServiceMigrationTest
Test: Manual, with TestDPC, also patching it to target R
Change-Id: I1eba7216dd557c94bef822b77d25b484dfcd6f63
Include all notifications that appear in the conversation
space, not just messaging style ones
And then I decided to fix a user vs uid issue in the tests
which means many of them have been touched
Test: atest
Fixes: 158610806
Change-Id: I0bb3f0415845b44ae3e3f9d7b2af836be00ceb24
This broke in P. Basic support was broken by a simple negation
issue with the logic that checks for the original package.
That, along with the suggestion in the bug to fix the renamed
package association means this should now work as expected,
carrying data over from a previous installed, differently named
package.
Bug: 131355130
Bug: 132749720
Bug: 111967720
Test: atest PackageManagerServiceHostTests
Change-Id: Ifc4c7af47c4b633cd27ba4a40b6baa0e27960d71
WindowManager calls ATMS#notifySingleTaskDisplayEmpty to notify that the
last task is removed from a single task display.
Originally it was called from ActivityStack when Tsak is removed, but
while merging ActivityStack and Task, CL[1] moved the call to Task. As a
result, the lister gets notification when ActivityRecord is removed,
instead of a last Task is removed, which causes unexpected bubble
closure.
[1]: Ifb167129c89a3aba11796daa21a9dee7200913ca
Bug: 157067689
Test: atest TaskStackChangedListnerTest
Change-Id: I93b745ba7fd1bb2fbef7915ddff2316100813187
Introduce FixedSizeQueue, a simple wrapper of ArrayDeque that only has
a limited size. This avoids the situation that TCMS caches a lot of
pending request in the queue while it is not going to bind to a TCS
anytime soon. When the request is removed from the queue, we notify
the client that the request is failed.
Also, we now limit the max amount of sessions in the cache.
We already have two measures to avoid the leak of sessions, i.e. Cleaner
and linkToDeath, but just in case.
Also, fixed an issue that onDestoryTcSession() is called on the
wrong TC if the TCS is not bound yet. This is an example of the
problematic running sequence:
1. TCS is not bound
2. onCreateTextClassificationSession is called
3. onDestory() is called. TCMS finds out which TC to call by looking
at session cache.
However, sessionCache does not contains the record that we need
because we do not update it until the service is bound.
4. TCS is now bound.
5. onCreateTextClassificationSession is forwared to the right TC.
6. onDestory is forwared to the default TC, which is the default
if we don't know which TC to call on.
The solution is just to update sessionCache as soon as
onCreateTextClassificationSession is invoked.
BUG: 156683847
Test: atest FixedSizeQueueTest
Test: Revert ag/11734845. Send a lot of messages that won't trigger
suggestConversationActions. Check the output of
"dumpsys textclassification", make sure the pending queue size
is always <= the limit.
Test: m mts && mts-tradefed run mts-extservices
Change-Id: Ib2e3e0d553e703ea759144bc9b38fec0d87de719
When we notify insets changed, legacy behavior forces us to force
a new measure on the entire hierarchy. However, this can cause
jank in various scenarios.
Make sure that we don't report an insets change if non-observable
state changes.
Test: InsetsStateTest
Test: Swipe up to home while IME open
Bug: 157123435
Change-Id: I9c51066c6489888720b307240d03054cc18c4172
The route ID of a bluetooth route was its hardware address and
SettingsLib depended on that to get BluetoothDevice.
We can't use the address as ID for a pair of hearing devices,
which has their own address but should have the same route ID.
Instead, this CL adds "address" field explictly to be used for bluetooth
routes.
Maybe it can be used by other devices as well.
Bug: 157708273
Test: make -j42 RunSettingsLibRoboTests && cts test
Change-Id: Ib940da9975fc8d68ec3fb7cf2c4a85c0d1a195f3