Enable proto reading on the Android Framework with a memory efficient
pull parser.
Fixes: 112269636
Test: atest CtsProtoTestCases
Change-Id: If8331edb1ec393acd724ffb5d27d6efad1a42a80
We created this API to make it easy to pass a given UserHandle into
all Managers obtained from a given Context, which works great for
"normal" users, but we should also support special users like ALL
and CURRENT.
Also add an AutoCloseable marker to make try-with-resources easier.
Bug: 112153259
Test: atest android.content.cts.ContextTest
Change-Id: I261dfcc5cfdfc76bda5d70181785e11c2715a558
The CL adds Magnifier#setZoom(float), which allows dynamically changing
the initial zoom applied to the content that will be magnified and
displayed in the magnifier.
Bug: 72211470
Test: manual testing
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I1dd01085ef5a1589a3602aefd03223d1451564f5
The CL adds public getters around magnifier properties. The properties
mostly correspond to the ones that can be specified using the magnifier
builder class.
Bug: 72211470
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I84c827bed039cb46b19c2dfb5123bd2d97374eca
Apply some rules about what notifications are automatically
silenced.
Test: make ExtServicesUnitTests &&
adb install -r $OUT/testcases/ExtServicesUnitTests/ExtServicesUnitTests.apk &&
adb shell am instrument -w android.ext.services.tests.unit/android.support.test.runner.AndroidJUnitRunner
Bug: 111475013
Change-Id: Idf0434c0688b3249a9fc2d5aa655665e71e53249
CtsViewTestCases tests were using @hide APIs. This change makes some
of these APIs @TestApi, so CtsViewTestCases can just link againts test_current.
Test: make -j
Bug: 37778825
Change-Id: I685ab5f0d1d5fcb5557ce4d93fe4f55cc695ed3d
Allow the notification assistant to block or silence
incoming notifications, or demote notifications after they
are posted
Also temporarily silence everything by default
Plus: bonus refactoring of the cancel notification runnable so I could
write just one of those tests :)
Bug: 111475013
Test: manual, runtest systemui-notification
Change-Id: Ifa04a21919f60d06080cd63e7d7747180b641308
1) Use @TestApis for verify AM related functions to replace using command.
2) Remove "development" protection level for some @TestApis permissions.
Bug: 77988683
Bug: 80415658
Test: atest CtsActivityManagerDeviceTestCases
Change-Id: I4bb10b45a2269c9e871f38f219d3e92cb45eeb9d
This method is being used the Android Things instrumentation test apk.
Bug: 111654175
Test: tests pass
Change-Id: Id3fcd2d89789868e50048542fd1dfe25d9986103
If the apps has provided their own choices, they will be used, as opposed
to the "smart replies" from NAS.
Otherwise, smart replies will be applied to the notifications
with a freeform RemoteInput but without choices.
The smart reply model is not ready yet, so canned response is hardcoded
and it is disabled by default. To test it out, run
adb shell setprop persist.sys.smart_replies_experiment true
Also, to get rid of the target >= P SDK requirement, you may want to run:
adb shell settings put global smart_replies_in_notifications_flags enabled=true,max_squeeze_remeasure_attempts=3,requires_targeting_p=false
Test: atest SystemUITests
Test: atest frameworks/base/services/tests/uiservicestests/src/com/android/server/notification/NotificationListenerServiceTest.java
Test:
1. adb shell setprop persist.sys.smart_replies_experiment true
2. adb shell settings put global smart_replies_in_notifications_flags enabled=true,max_squeeze_remeasure_attempts=3,requires_targeting_p=false
3. Send a message to myself, observe the hardcoded smart replies.
Bug: 111674540
Change-Id: Ia61a77faef7c4dcba0501abfec80e3e8cc7274e4
This splits the
- review permissions
- individually control permissions
- consent to manage wireleess (wifi + bluetooth)
properties.
Almost all code cares only for the first and it is now always true.
Hence a lot of code can be simplified.
Bug: 110431654
Test: atest PermissionsHostTest
started pre-M app
Change-Id: I733cd476ccd0bf5eaa59e9a9506db34f57c6baee
Here is the flow:
NAS generates Adjustment -> NMS convert this to RankingUpdate ->
SystemUI.NotificationListener receives the RankingUpdate in either
onNotificationPosted / onNotificationRankingUpdate (Depend on does NAS
provides the adjustment before the notification is en-queued) ->
NotificationEntryManager determines the need of reinflation ->
NotificationInflater inflates / reinflates the view with these
extra bits like smart actions.
Note: We do re-inflation here as simply adding a button to the existing
notification view seems problematic. For example, if the original
notification does not have any action, we will need to inflate the
template with the action container.
Screenshot:
https://hsv.googleplex.com/5731489463402496
Test: atest SystemUITests
Test: atest com.android.server.notification.NotificationAdjustmentExtractorTest
Test: Modify ExtServices to provide adjustment in
createEnqueuedNotificationAdjustment, post a notification with
a entity in a sample app, observed the notification is updated.
(Testing the onNotificationPosted flow)
Test: Modify ExtServices to provide adjustment in onNotificationPosted
by calling adjustNotification. Post a notification with
a entity in a sample app, observed the notification is updated.
(Testing the onRankingUpdated flow)
Test: Repeat the above test, but explicitly make the RowInflaterTask
slow by inserting Thread.sleep. This can test the onRankingUpdated
flow when the row is not yet inflated.
BUG: 110527159
Change-Id: I98aee3ac62f60b189ea92ac9fc000127325dfead
For testing we often need to run shell commands. This can be done
today via running a shell command from an instrumentation test
started from the shell. However, this requires adding shell commands
which are not in the API contract, involve boilerplate code, require
string parsing, etc.
This change allows an instrumentation started from the shell to
adopt the shell UID permission state. As a result one can call APIs
protected by permissions normal apps cannot get by are granted to
the shell. This enables adding dedicated test APIs protected by
signatures permissions granted to the shell.
Test: cts-tradefed run cts-dev -m CtsUiAutomationTestCases
-t android.app.uiautomation.cts.UiAutomationTest#testAdoptShellPermissions
bug:80415658
Change-Id: I4bfd4b475225125512abf80ea98cd8fcacb6a1be
Combination of moving to existing public API, tagging things as
@TestApi, and bringing utility methods into tests.
Bug: 13282254
Test: atest cts/tests/tests/os/
Change-Id: Ifd24c0d048d200e8595e194890cc1dc53ddc2b3e
We're almost out of bits, and we don't really need to smash both
thread and VM policy into the same 32-bit value, so use the lower
16-bits for each policy type and the upper 16-bits for penalty.
ActivityManager is only consulting the penalty bits, so we can
remove getViolationBit() and switch CTS over to doing instanceof
checks.
Bug: 110413274
Test: atest cts/tests/tests/os/src/android/os/cts/StrictModeTest.java
Change-Id: I760e6a28f56da66dc75b7df9daf2167ff5bdff50
When an app starts becoming Direct Boot aware, it can be difficult
to track down all the places they're implicitly relying on
PackageManager filtering behavior.
For example, if the current Launcher isn't Direct Boot aware, we
hide it until the user is unlocked, which could confuse other Direct
Boot aware apps into thinking it had been uninstalled, which could
cause data loss.
This change helps apps track down places where they're implicitly
relying on the automatic filtering; they should instead carefully
choose a combination of MATCH_DIRECT_BOOT flags to decide on the
explicit matching behavior they want.
To implement this, we partially migrate the updateFlags() methods
out into ApplicationPackageManager, since the checking needs to
happen on the client side to correctly report StrictMode
violations. We don't currently mutate the flags, but we retain
the naming to keep that door open in the future.
Test: manual
Bug: 110413274
Change-Id: Iff6feba19da81ea1b4eeb3af821c3bdfbd9bf17c
Some permissions are getting split into foreground and background
variants. If an app only has the foreground version it can only access
the protected resource while the user is using it. Once the background
permission is added to the foreground permission the app can always
access the resource protected by the permission.
- Only having the background permission does grant anything.
- Mutliple foreground permission can share a single background permission,
but a foreground permission can not have multiple background
permissions.
- As the implementation of background permissions is based on AppOps
only the system can declare such foreground/background permissions
- A CTS test enforce that the background is in the same group as the
matching foreground permission.
Bug: 78788390
Test: Checked declared permission after boot and found new attributes
Change-Id: Ica7ba77b24345607c7467c41c982a58c39199024
First step in unifying the window hierarchy that is currently split
within AM and WM packages. We separate the interfaces and service dealing
with activities and their containers (tasks, stack, display) from the
rest of AM interfaces and services. This will allow us to move the new
interfaces and services to WM when the internal states are cleaned-up.
Test: Existing tests pass
Test: go/wm-smoke-auto
Bug: 80414790
Change-Id: Ide9b3f89123b768cdbd3e3878113c7a8021187f3
This gives them a way to collect all included values without
resorting to manual probing of each newly added value.
Cherry-pick of ag/4052941 with minor conflicts in the imports.
Bug: 16207332
Test: atest com.android.cts.net.HostsideVpnTests
Change-Id: Ia764b3412bf834890612378e0c3846913f4e0a06
Merged-In: Ie5cd22cfa2b6a60510fd1e31d7ebcd8f6cc890a0
Merged-In: If07e77c92046807235229a4f67ee087bdd7bccf1
There's an escape clause that passes the cross user permissions
if the caller UID is identical to the target user ID [eg. we're not
operating across users]. However, the method getInstalledPackagesList()
uses android.permission.INTERACT_ACROSS_USERS to filter the results and
a calling UID check is not sufficient. Ensuure the permission is
actually held, regardless of the calling UID or target user.
Change-Id: Iebf88668766d387a15246d6eea6420610665105a
Fixes: 80435086
Test: atest CtsAppSecurityHostTestCases:ApplicationVisibilityTest
