Major changes:
1. ConversationAction is now in top-level.
2. Removed TypeConfig, and repurposed TextClassifier.EntityConfig for
general use. It would be better to rename it to be something like
TypeConfig. But just a bad name is probably not worth to deprecate
the existing APIs.
3. Hints constants are moved to Request object.
4. Action constants are moved to ConversationAction object.
Test: atest TextClassifierTest.java
BUG: 120841922
Change-Id: Ia466aaf4c5050a9c7e404dcd3b295f5ef7e4ce6f
Test: atest, make sure missed call notifications are no
longer demoted by aosp notification assistant
Change-Id: I80728bae67501d64359e0dac02dca928c34a7e95
Fixes: 122657004
Let an activity show on top of the lock screen if the activity behind
this can be shown on top of the screen. This is pre-requisite for
showing permission dialog on top of the lock screen only when it makes
sence.
Bug: 109754623
Test: atest server.am.KeyguardTests
Change-Id: Ideaa2b77519649a70c682bc95277e451e149adad
The CL fixes TextView#setTextCursorDrawable, for the case when a zero
drawable resource id is passed. We want to set a null Drawable, but the
Context#getDrawable(0) call was throwing rather than returning null.
Bug: 122742983
Test: atest CtsWidgetTestCases:android.widget.cts.TextViewTest
Change-Id: I45bf57002043d7dbe541d76e61fce3f729959fc8
The added logging events are: blocking helper view displayed or
dismissed, any button click within the view, undo clicks and
system suggests of blocking helper.
* Move some of the getLogMaker logic of server's NotificationRecord
class to the common StatusBarNotification class.
* Use the StatusBarNotification.getLogMaker to produce blocking helper
logging.
* Add logging in the NotificationInfo for interaction and display of
the blocking helper view.
* Add logging in the NotificationBlockingHelperManager for system
suggests of blocking helper.
Bug: 112482290
Test: unittests and manual - viewed produced logs.
Change-Id: I3a5267d55faba21f6668d35ff8aa12deb0dc5921
Regular ...Manager-s connect to the system server hence there is no
problem establishing a permanent connection via
ServiceManager.getServiceOrThrow.
(1)
PermissionControllerManager connects to an app, hence the binding has to
be dynamic. This is done my using the local RemoteService class.
(2)
...Manager-s are per context. Hence when the context goes away all
service connection started for this service are supposed to also be
cleaned up. There is no callback when the context goes away.
(1) and (2) lead to RemoteService connection to still be bound while the
context goes away which causes a service connection leak.
This change emulates the behavior of regular managers by creating a
permanent RemoteService tied to the application context. Of course
interanlly RemoteService itself binds and unbinds dynamically. Still,
now the RemoteService is not bound to a context that goes away and no
connection is leaked.
Test: atest CtsAppSecurityHostTestCases:android.appsecurity.cts.PermissionsHostTest
(this test failed before as settings was crashing due to leaked
remote service connections)
Change-Id: I5b8a4c62070fcce6e390897d046c4b28998e3952
* changes:
Atom: initPortInfo when receive hotplug from tx for audiosystem device[1/3]
handle manual port switching
Claim Active Source during System Audio Mode init by AVR when the device also has playback type and can't get Active Source.
Switch away from ARC input when ARC is terminated.
Request Active Source when ARC is enabled in ArcInitiationActionFromAvr.
Refactor the Active Source updating logic in CEC devices.
Fix tests failure on com.android.server.hdmi
Making functions visible for testing com.android.server.hdmi
Back out unneeded ag/4808863. Standby has been handled in ag/4881453.
This change adds the names of the home and emergency roles, which will
be used by Settings.
Bug: 110557011
Test: build
Change-Id: I40bb0e021232acff62a32e0bdc24a04ff9ec6ba8
The API is mostly implemented; except for hooking up the listener
and handling an already running bugreport.
BugreportManager is the handle to the new API exposed to apps.
Generating bugreports requires root privileges. To limit the footprint
of the root access, the actual bugreport generation in Dumpstate binary,
is accessed as a oneshot service and dies after it finishes
running.
System server accesses Dumpstate via a binder interface since it does
not have root privileges.
Starting a oneshot service is done via setting a system property, which
needs to be done from system server. BugreportManagerService is the
new system server service that does this. BugreportManager calls into
BugreportManagerService via a binder interface, since the former is in
the app's process.
Both app to system server as well as system server to native service
calls are via implementations of IDumpstate binder interface.
Bug: 111441001
Test: builds. Flashed & verified it boots.
Test: wrote a test client (not included) and verified invoking
startBugreport works.
Change-Id: I4abeb753388c055c36ae0dd916af1ec8d40b7bf0
Merged-In: I4abeb753388c055c36ae0dd916af1ec8d40b7bf0
With this CL we add a new key-value pair to
smart_replies_in_notifications_flags to control whether smart
suggestions should be turned on for heads-up notifications. By default
the suggestions are turned ON.
Bug: 122351821
Test: atest SmartReplyConstantsTest
Test: Run "adb shell settings put global
smart_replies_in_notifications_flags show_in_heads_up=false" and ensure
heads-up notifications do not contain smart suggestions.
Change-Id: I84292c10a4545112b0e993af33bb01a8cc18ce23
