Avoid potential race condition between FRP wipe and write operations
during factory reset by making the FRP partition unwritable after
wipe.
Bug: 30352311
Test: manual
Change-Id: If3f024a1611366c0677a996705724458094fcfad
Introduce a new internal flag MATCH_ANY_USER for genuine uses
of searching through all apps on the device.
Some temporary accommodations for Launchers that reach across
to the work profile until we have a new LauncherApps API to do
that officially.
Bug: 31000380
Test: CTS tests added
Change-Id: I2e43dc49d6c2e11814a8f8d1eb07ef557f31af34
(snooze indeterminately and unsnooze)
Test: runtest systemui-notification and cts tests in same topic.
Change-Id: I5ce74638f55ed796bc6b26af167b32b0040f4222
Not only if fixes warning about outgoing transactions from system_server
not having the FLAG, but it fixes system crashes when the service
doesn't behave well (for example, if it does not call super.onCreate()
on onCreate().
BUG: 31001899
Test: manually built and ran it
Change-Id: I829ee501edb84bd02a60e8df92f9a0e0d2157887
So far AutoFillService only received the assist data from framework; in
this CL, it also offers a method where the auto-fill provider can send
the auto-fill data back to framework.
The workflow is:
- AFMSI calls a new AM method (requestAutoFillData(), instead
of requestAssistContextExtras()).
- The assist receiver is located in the app, not on system service.
- AM uses a new request type (ASSIST_CONTEXT_AUTOFILL) to request the
assist data to the activity.
- ViewStructure has a new setAutoFillId() method which is used to set an
unique id for the view.
- View uses the accessibility id to implement the auto-fill id.
- When the activity fullfills the request, it creates an IAutoFillCallback
remote object - that will be used to set the auto-fill fields - and
returns it in the assist bundle (using the
VoiceInteractionSession.KEY_AUTO_FILL_CALLBACK key).
- The app-visible AutoFillService class offers an onFillRequest() method,
which contains the assist data and a FillCallback used to handle it.
BUG: 31001899
Test: manually built and ran it
Change-Id: I3d208c14e81022dc96dd03f38bbe25a778b24a67
Rename ranker to assistant and make some of the methods public.
Delete the ext services ranker and restore the listener-type
lifecycle to the assistant.
Test: manual. add a notification assistant and verify it gets
assistant and listener callbacks.
Change-Id: Ia3406c8c14d923426c1b8a6d8b5187efe64c31c3
This CL provides the initial, skeleton implementation of the Auto-Fill
Framework classes:
- Defines the system service and app-based
AIDL (IAutoFillManagerService.aidl and IAutoFillService.aidl respectively).
- Defines the 'adb shell cmd' interface.
- Defines the permission required to access the service.
- Registers the service on SystemServer.
- Adds the code to bind the app-specified service to system_server.
- Defines the service class (AutoFillService) required by providers.
- Implements the initial startSession() method.
This is still a very early, "work-in-progress" change:
- It has many TODOs.
- It does not have unit or CTS tests yet.
- It does not provide a callback method to auto-fill the fields.
- In fact, it has a lot of TODOs.
Despite these adversities, it can be tested by following the steps
below:
1.Create an app with a service extending AutoFillService
2.Implement the onNewSession() method
3.In the manifest:
- Listen to android.service.autofill.AutoFillService intents.
- Require the android.permission.BIND_AUTO_FILL permission.
4.Explicitly set the app as an autofill-service by running:
adb shell settings put secure auto_fill_service MY_APP/.MY_SERVICE
5.Start a session against the top activity:
adb shell cmd autofill start session
BUG: 31001899
Test: manually built and ran it
Change-Id: I00f4822159b31ddddba8f513e57c4474bc74eb89
- Apps cannot update their channel settings after creation.
- Importance is required when creating a channel.
- Some method name changes.
- Ranker can't modify fields a user has changed.
- High and Max importance mean the same thing.
- The default channel adopts app wide settings on creation.
- The default channel is limited to importance low once target api is post n mr1
unless the user changed it.
Test: runtest --path frameworks/base/services/tests/servicestests/src/com/android/server/notification
Change-Id: I73c449a6abe6d709046de79c5c54339cb2edf0b8
Test: runtest systemui, and post and dismiss notifications, checking that they
are grouped (or not) appropriately.
Change-Id: I8f3ec497cebcb14a7853fac98b844a3fd4503141
To a notification listener, snoozing will appear as a cancel
(with reason snoozed) followed by a post (when the snooze period
ends).
Apps can repost a snoozed notification, but the updates will not be shown
to the user until the snooze period ends.
Snoozing is canceled if the posting app or a notification listener
cancels the notification.
Any notification listener can snooze a notification. Technically apps
can snooze their own notifications also, though that's not public.
In this iteration snoozed notifications will be lost on device reboot.
Test: included. Also, various post, snooze, update, cancel tests with
a listener.
Bug: 30997603
Change-Id: I568a6448196f0992a17d20a4dac296321ec5092b
Fixes a crash that would happen in all dreams
that did not have permission to acquire wake locks.
Instead moves the wake lock logic into the system
process. Also fixes a bug in DozeService where the
wake lock was not held until dozing was actually
properly initialized.
Fixes: 31612287
Bug: 31044352
Related-CL: I85955a2b7d6bad5171accbc336117a9660b1b198
Test: adb shell settings put secure screensaver_components com.android.dreams.basic/.Colors; adb shell service call dreams 1
Change-Id: Idb3f921ee71b6da6c2ab0c44c332ef91f93ddbc0
In this iteration:
-Every app gets a default channel that notifications will be posted
to if they don't specify a channel themselves. The default channel
inherits app-wide settings on upgrade.
-Apps can create new channels without user approval, but apps
cannot change the name of a channel once created, nor can they ever
set the importance.
- When a notification is posted:
- If the channel is marked as 'vibrates', vibration will be
applied to notifications that lack a vibration. unlike the default
notification flag, notifications will retain their custom vibration
if given
- Same with sound and lights
- A notification's importance is the min of the app and channel
importance
- A notification can bypass dnd if: either the app or channel settings
say it can
- A notification's show on lockscreen setting comes from the app first,
and the channel second if the app has no preference
Tests: in cl. also there's a cl for cts and a test app.
Change-Id: I630f99df655800b00586dcfab538d320d04fe0f0
Fixes a bug where DozeService would not properly initialize
because the CPU went to sleep before onDreamingStarted completed,
causing the pickup gesture to not work.
Change-Id: I85955a2b7d6bad5171accbc336117a9660b1b198
Fixes: 31044352
Evidently some apps redirect/obscure tiles in a way that makes
creating a ComponentName from the TileService useless. Instead
generate a token which will be a much more stable way of identifying
tiles henceforth.
Change-Id: Id68550bcdcdc3e3987f09380f258610e7a5aca85
Fixes: 29121793
