Rather than require an a-priori Notification be supplied in order to
start a service directly into the foreground state, we adopt a two-stage
compound operation for undertaking ongoing service work even from a
background execution state. Context#startForegroundService() is not
subject to background restrictions, with the requirement that the
service formally enter the foreground state via startForeground() within
5 seconds. If the service does not do so, it is stopped by the OS and
the app is blamed with a service ANR.
We also introduce a new flavor of PendingIntent that starts a service
into this two-stage "promises to call startForeground()" sequence, so
that deferred and second-party launches can take advantage of it.
Bug 36130212
Test: CTS
Change-Id: I96d6b23fcfc27d8fa606827b7d48a093611b2345
(cherry picked from commit 79047c62b5)
Adds an exception to touchscreenBlocksFocus ViewGroups which
are also keyboardNavigationClusters. The behavior we want is
that cluster navigation can jump into touchscreenBlocksFocus
clusters but normal keyboard navigation can't. Once focus is
in a touchscreenBlocksFocus cluster; however, we allow focus
navigation to move freely within that cluster. It remains in
that cluster until a subsequent cluster navigation brings it
back out.
Adds back the touchscreenBlocksFocus attributes to Toolbar
and actionbar so that they behave like they did before.
Bug: 34363323
Test: Added CTS test. Verified desired behavior in a test app
Change-Id: I555bf5570b16a57f0d4c8a020ae509a1e1b33910
(cherry picked from commit aee802f3bc)
Prior to SurfaceView bypassing the WM, the WM would see that
the app had multiple windows and wait for them all
to finish drawing before beginning any animation, or similar operations.
Now that SurfaceView is invisible to the WM we have to replicate this
two-way latching in ViewRootImpl.
Bug: 36492285
Test: Launch Chrome over and over.
Change-Id: Ie72c2d394f1bb0eb8551e6f63bb1c19a5df43afd
To be consistent with other multi-window callbacks adding
Configuration param to the onMovedToDisplay, so that app
developer can handle configuration change at the same time
when it receives a notification about move.
Bug: 36649499
Test: android.server.ActivityManagerDisplayTests
Test: #testOnMovedToDisplayCallback
Change-Id: I80c765473bfc09ea1fb7aa4e2e77baf3b21606b8
(cherry picked from commit 2c32a11a71)
No functional change.
Fixes: 35737935
Test: run cts test and confirmed all tests passed
cts-tradefed run singleCommand cts-dev -m CtsInputMethodTestCases
Change-Id: I44e5e91b6462c3c7d023f50365b30da9cf98c509
Test: cts-tradefed run cts-dev -m CtsViewTestCases -t android.view.textclassifier.cts.TextClassificationManagerTest
Tests have been written on the native side.
Bug: 35416389
Change-Id: If2de73391e1a343e0dc7698039ad1464cedfbf08
- Increase the size of the text sent as context to the classifier
- Pass regex match hints to the classifer
Test: Build still works. Regex hints logged correctly. The hints won't
matter until we've actually passed in this values to native code. Native
library test will be written and I've got a tracker bug to write more robust Java tests.
Bug: 35416389
Bug: 36584397
Change-Id: I29e56189b388b36dc0cc7a8bb13ef237ff55be7b
Allows for selecting a single accessibility service or feature
to be triggered by the accessibility button in the navigation bar
Bug: 34720082
Test: Manual
Change-Id: I320febede0398b1eff38a87d4db31fd7dfc53062
Now the autofill UI tracks the movement of the anchor view,
both real and virtual and while still preventing the filled
app from accessing the chooser UI. This was achieved by using
a popup window in the app process to determine the window
location and adding a window presenter interface to popup
window that controls the actual window addition, removal, and
update which is implemented by the system server.
Test: all autofill CTS tests pass
bug: 36392498
bug: 35708258
bug: 34943932
fixes: 36039182
fixes: 36493078
Change-Id: I0321913b2e2e759f4b17003bf85cb873e63a467c
There are two separate overrides for display metrics in DisplayManager
and WindowManager:
- In DM - LogicalDisplay#mOverrideDisplayInfo, in most cases not null.
- In WM - DisplayContent#mBaseDisplayWidth/Height/Density, different
from #mInitialDisplayWidth/Height/Density values when some metrics are
forced.
When display was resized its windows weren't updated because of
two problems: old LogicaDisplay#mOverrideDisplayInfo was preventing
WM from detecting the change and override (base) display metrics were
never updated by resize.
When display size changes:
- Before this CL:
DM receives DISPLAY_CHANGED event, it updates internal values.
In most cases there is an override obtained from WM and WM doesn't
get new values from LogicalDisplay#getDisplayInfoLocked().
- With this CL:
DM receives DISPLAY_CHANGED event, it updates internal values and
resets the override received from WM. WM will receive updated values
and will decide whether to apply them or not: if there is no override
in WM - it will apply values from WM, otherwise it will keep the
override. In both cases WM will eventually update its own override
and will update the override in DM.
Bug: 35258051
Bug: 34164473
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testDisplayResize
Test: #testForceDisplayMetrics
Change-Id: I80795434a6a35adb0577fbce334d76fabd2fa03d
We simply weren't destroying the old Surface (though the finalizer
would have eventually caught it). As we destroy it we need to use
a Window preservation scheme similar to what the WindowManager
provided.
Bug: 36447956
Test: Manual
Change-Id: I8b4210eb76cec364522cc0a40014517e42ebbe68
We were throwing relatively harmless NPEs here
and catching them below. The log message when
catching exceptions also needed some updating.
Not assosciated with a particular bug just
noticed in logcat.
Test: Manual
Change-Id: I5f07e6fc8ff3a34318682bf7b6c309fbba4097e4
Added setIdEntry() on ViewStructure and documented how WebView can map HTML
tags and attributes into ViewStructure.
Test: VirtualContainerActivityTest pass
Test: m update-api
Bug: 36056207
Change-Id: Idaee9612d2c1b1adac99f354c8f87137ee9ef877
- Removed overloaded newChild() methods.
- Added a setAutofillId(parent, virtualId).
- Changed view so AutofillId is set on all relevant methods.
Test: VirtualContainerActivityTest (with new tests) pass
Bug: 36056207
Change-Id: Ia11344f95c2756e83307c54052878e9dbe471873
This is useful in the cases where the virtual children hierarchy is rendered
by a different process.
Test: VirtualContainerActivityTest pass
Bug: 36056207
Change-Id: Id9bf3a9e9366b616dc2a6e0a204e238a2bee3a20
