See accompanying frameworks/native commit
"SurfaceFlinger: Add parent-less relative layering" for a full explanation.
Test: Manual of bug repro steps. Plus tests for new SurfaceControl functionality included in frameworks/native.
Bug: 36693738
Change-Id: Ic54598117c1f44a206d33f03d0cc463fbef43fcc
* changes:
Fix broken CTS tests.
Draw a default focus highlight if needed.
Add a public API defaultFocusHighlightEnabled.
Detect unhandled keyboard focused state.
FontsContract.fetchFonts provides a low level font access with fonts
provider.
This CL also includes:
- Introduce new class FontFamilyResult/Font as the inner static class
of FontsContract which are used to for result value of fetchFont..
- Introduce a functionality to FontsContract to be able to create
Typeface from an array of FontResult.
- Expose URI of each file entries to be able to register ContentObserver
Bug: 36494487
Bug: 36085028
Test: android.provider.FontsContract passes
Test: android.graphics.cts.TypefaceTest passes
Test: android.graphics.fonts.cts.FontResultTest passes
Change-Id: Id6f85039d0e86be063ef099d7ec6bfd97e4424c5
A more targeted version of "ViewRootImpl: Fix child lifetime".
In this version we avoid hijacking the window visibility callback
and introduce a new path.
Our contract has been that at any time after returning from
onStop, the WindowManager may destroy the clients Surface. We
see in setWindowStopped, we set the stopped state on the hardware
renderer in order to prevent further use of the Surface. However
there is nothing synchronously dispatching this change to child views
and so SurfaceView is not necessarily informed to release it's Surface
in time. Typically SurfaceView will be informed through the
onWindowVisibilityChanged callback. The signal producing this
is emitted from SystemServer prior to onStop but has to pass
through the clients handler thread. It seems this has always been
broken, and we have always had intermittent reports of EGL_BAD_ALLOC
scenarios. I speculate that elevation of WindowManager scheduling during
app close scenarios is perhaps making this more severe, as it seems to
ensure the WindowManger will win the race to destroy the Surface before
the client handler thread process onWindowVisibilityChanged (unless
the FIFO timeout is surpassed).
Test: Put Chrome in PiP. Turn screen off. No Crash!
Bug: 36561071
Change-Id: I9233ba8151c7f577b1d1044afc0c2ac3a65be4b4
The default focus highlight should be necessary when the view is
attached to window.
Test: cts-tradefed run singleCommand cts --skip-device-info
--skip-preconditions --abi armeabi-v7a -m CtsViewTestCases -t
android.view.cts.ViewTest
Test: cts-tradefed run singleCommand cts --skip-device-info
--skip-preconditions --abi armeabi-v7a -m CtsWidgetTestCases -t
android.widget.cts.MediaControllerTest
Bug: 37082416
Change-Id: I5d6b0c00b5ba03c8f62e4f71be9336823a73134b
This commit draws a default highlight for a focused
View if it's detected to have no state_focused defined
and its useDefaultFocusHighlight attribute is true.
When we detect a default highlight is needed, we show it
on top of the view to. Once we detect that it's no longer
needed, we remove it.
Test: Check that views without a focused_state in its
state spec have a default highlight when they get focused.
Bug: 35096940
Change-Id: Ifbe4bb9e1297d98845314e24d8b758f14e5987a9
This commit adds a public API to turn on/off default
focus highlights. When a focused View is detected to
have no state_focused defined, we can use this API to
decide wether we should show a default highlight for it.
Test: cts-tradefed run singleCommand cts --skip-device-info
--skip-preconditions --abi armeabi-v7a -m CtsViewTestCases
-t android.view.cts.View_DefaultFocusHighlightTest
Bug: 35096940
Change-Id: I76b45d6bf5761641a0ed7f4d0b04cb325ed72b52
We now have a software feature for autofill which can be used
by partners to disable it on low-end devices or form factors
for which autofill doesn't make sense.
bug:35956220
Test: manual (requires a custom build)
Change-Id: I6c06462ed9ca3ae93331700dce38a8c08dfd0722
Effectively reverting 89927b3cd9, which
allowed direct-boot aware activities in the work profile to show before
the profile was unlocked. This causes problems with key eviction
introduced in O. Specifically, many system activities (e.g.
ChooserActivity, activities in Settings, etc.) are marked direct-boot
aware, and therefore can be started while the work profile is locked
with key evicted. Currently they either bypass the keyguard when they
should not, or simply crash due to profile still being locked.
In the future, we need to create a new mechanism to allow activities
such as video calls, alarm clocks, etc. to bypass the work keyguard. It
probably involves checking for something like FLAG_SHOW_WHEN_LOCKED.
Bug: 36961785
Bug: 35708183
Bug: 30296144
Test: manual, by following the steps in the bugs quoted
Test: runtest -c com.android.server.am.ActivityManagerServiceTest frameworks-services
Change-Id: I5ccaaf963f3dd96e4abb785a10aa258b15363178
A single TTC font or variation font can be used for multiple entry
of FontResult. To share the file contents, assign same URI for those.
Bug: 36494487
Test: android.provider.FontsContractTest passes
Change-Id: Ibf24f216179a6481dee1801cd2dfb68c4bb38fac
Renames the instant apps setting to reflect what it is for.
Adds the SystemApi annotation to make this field visible
to the resolver and installer.
Test: existing tests
Change-Id: I1651bb101d69bdfdaa63c004435025c68a33cd8e
Bug: 37197930
Test: runtest -x cts/tests/app/src/android/app/cts/FragmentReceiveResultTest.java
This verified existing startActivity* public APIs are still working
Test: The new hidden API is used/verified by the CLs under the same topic.
Change-Id: I2aca2823ecf26dc8a9318b3783b6041796c02582
ACTION_UPGRADE_SETUP exists as an SdkConstant and is now additionally
tagged as a SystemApi. ACTION_DEVICE_INITIALIZATION_WIZARD is added
as a deprecated SystemApi to appease CTS requirements. Both APIs are
hidden.
Test: cts-tradefed run cts-dev -m CtsSignatureTestCases \
-t android.signature.cts.IntentTest#shouldNotFindUnexpectedIntents
Bug: 33663899
Change-Id: Ib45afbfcbb9a3d3020f11c8b63fc2bcf6fc447a1
(cherry picked from commit 4cd32e5395)
(cherry picked from commit 8143fa57ad)
There is no longer a name size limit to the properties, remove
illegalArgumentException if tag length is too large.
Test: build
Bug: 36696208
Change-Id: I4b4329c8c951082ed0d777cdd70ee3e773bed16c
This gives semantics similar to the start command
queue of services.
The implementation is currently lacking in URI permission
grant handling of the work intents; that will be coming
in a follow-up change.
This includes a first step of adjusting/fixing locking
within JobSchedulerService. The JobServiceContext class
has a bunch of stuff it does that assumes it doesn't need
locking because it schedules the work on a handler. However,
to be able to correctly implement the work finish flow (that
takes care of stopping the job when there is no more work),
we can't dispatch these asynchronously so need to get rid of
that and just do explicit locking.
The switch to explicit locking is half-way there (again the
remaining part will be a follow-on CL). Right now we have
the locking, but still also the handler. But it turns out
there were a number of things we were doing without a lock
held where we actually should have been holding a lock, so
this is better anyway.
Test: new tests added
Change-Id: Iebd098046209b28e60fd2f4d855d7f91cd3a8b03
We now use ICU's new functionality for casing edits to preserve
the spans while applying AllCapsTransformationMethod.
Test: Manual
Test: CTS tests added and pass
Bug: 7198872
Bug: 19047649
Bug: 19713814
Bug: 34853618
Bug: https://code.google.com/p/android/issues/detail?id=67509
Change-Id: I0df388e79894961efb272d497f1dcc0570a6c085
