Noted affected users for versions prior to Android O.
Staged at: go/dac-stage/reference/android/os/UserManager.html#ENSURE_VERIFY_APPS
Test: make ds-docs and output staged
Bug: 38024373
Change-Id: Ida80c2134bdd4013c7adabee778e8296039747a2
SurfaceControl.
In a recent CL we introduced a call to Surface#createFrom, in order to
recreate the Surface object from the underlying SurfaceControl, as a
workaround to emulate when it was parcelled over binder in the past.
However this is causing BufferQueue abandoned errors when stopping and
resuming some applications. To understand them, we need to revisit the
SurfaceView destruction process when handling onStop.
First mWindowStopped will be set to true (SurfaceView#windowStopped),
and we should then enter updateSurface. Our requested visibility will
now be false and so we emit the Surface destroyed callbacks. Notice in
the finally block in mUpdateSurface, we will release mSurface, but we
will NOT null mSurfaceControl. Inline documentation explains why.
In the case that the activity is not actually being destroyed, it's
possible that we may not get a dispatchDetachedFromWindow. This means
that we will not null mSurfaceControl. Now if the activity is
un-stopped and we re-enter updateSurface we encounter a problem
state. "creating" will be set to false since mSurfaceControl != null,
however mSurfaceControl will not point to a valid surface.
Prior to the introduction of the #createFrom call, this unwanted state
didn't cause any problems. Because mSurface was released back in the
finally block as we were stopping we now fall out of the
mSurface.isValid() block in updateSurface. As we reach the finally
block again, we would now set mSurfaceControl=null since the app was
no longer stopped. Later when we reach updateSurface again (which
tends to happen quite often) it will now be null and we will correctly
set creating=true, create a valid SurfaceControl, and move along
happily. However following, the introduction of this
Surface#createFrom call we will now reinitialize the Surface from an
invalid underlying SurfaceControl. This means we will enter the
mSurface.isValid block, but will proceed to emit an invalid Surface to
the client in the callbacks.
We avoid this state by making creating=true even if
SurfaceControl=non-null when the calculated visibility changes from
invisible to visible.
Bug: 63251745
Test: Manual of app from bug and apps from previous related bugs. go/wm-smoke. Additional manual testing of many SV apps.
Change-Id: Icc32a34cac239d65267da705cc23feb23e1ceb67
Per feedback from DevRel, devs should avoid ProgressDialog because
using a modal dialog to show progress is a bad user experience.
Updating the ProgressDialog javadocs to say this; there's a separate
CL (http://cr/160568896) to make a similar note in the Dialogs API
guide.
Doc is staged to:
http://go/dac-stage/reference/android/app/ProgressDialog.html
Test: make ds-docs
Bug: 37565313
Change-Id: I189732fdda4532f248861e3f3d077f743f6387de
The attributes for View, paddingHorizontal and paddingVertical,
were added in the O release and are documented in R.attr. But they
should also be referenced in View itself, alongside the other
padding parameters.
Similarly, the new layout_MarginHorizontal and
layout_marginVertical should be referenced in
ViewGroup.MarginLayoutParams.
Bug: 63128350 Add docs about new padding/margin params
Test: built docs, checked the result
Change-Id: I3021df5ea83c469811b4a6ec6ecd3ab2966ec384
The description for `AutofillManager.isAutofillSupported` doesn't make
clear that either the device or the user can make autofill unsupported.
Bug: 62604325
Test: Ran 'make ds-docs -j16' and staged content to
go/dac-stage/reference/android/view/autofill/AutofillManager.html#isAutofillSupported()
Change-Id: I298b9f535e23dc3cb54fabed36642523753c13a5
As there is no caller for the SystemAPI convertToTranslucent, there is no situation
where requestVisibleBehind will actually result in the activity becoming
visible behind. However we have bugs in the requestVisibleBehind code-path,
so rather than fix them...it seems better to just prevent ourselves from
running in to them. Full deletion of the code-path is scheduled for post-O
branches.
Change-Id: I6e7c79e036986564d2d443a603e63c341de23057
Fixes: 62512584
Test: Repro from bug. go/wm-smoke.
Previously, we were returning START_SUCCESS when ActivityStarter
aborted launching the activity. This hides this activity and makes it
harder to debug.
This CL adds a new start result type to capture this internally.
Bug: 38121026
Test: manual
Test: go/wm-smoke
Change-Id: I97699b22b1eff476724c48db0c29daa0566ad280
Since CONTEXT_RESTRICTED is not a default flag of createPackageContext,
we can't rely on it for preventing unexpected font injections.
To protect developers and existing apps from a risk of font injection,
stop loading font from other package's resouce unless the developer
explicitly set CONTEXT_IGNORE_SECURITY.
This CL contains Iac2a6fb3d82ef23d5ca6ee33f4aaa9ed28455271 by manual
merging to handle repository split.
Bug: 62813533
Bug: 62879353
Test: Manually done
Merged-In: I4442ddc48dadb5c968b444be86038b602074d301
Change-Id: I4442ddc48dadb5c968b444be86038b602074d301
While a negative height is pretty silly, crashing apps on
the new version of android makes them sad.
Test: Existing CTS passes.
Bug: 62434804
Change-Id: I5fc3fc50fb6ccfa9e96f38ded4fb8e338f263f09
Make it clear in BluetoothLeScanner on how to get results
when starting a scan for a PendingIntent.
Bug: 38365430
Test: make offline-sdk-docs
Change-Id: I0bf88d751c89a8a478db985713357e153ac08595
The AutofillSession.getFillEventHistory() method returns only the event history
for the last onFillRequest(). In the scenario where the user switches
activities and the server has multiple sessions open, only the events for the
last session should be recorded.
Test: existing CtsAutoFillServiceTestCases pass
Test: LoginActivityTest.checkFillSelectionFromPreviousSessionIsDiscarded
Fixes: 62802026
Change-Id: I447ed77c2167095867b35d616b5cf2ae43aa28db
There is an issue (seemingly preexisting) with getPositionInWindow
after toggling view visibility. We see it when showing a view,
hiding it, and then showing it again. At this point we end up
with this call-stack:
SurfaceView#setVisibility->SurfaceView#updateSurface
->View#getPositionInWindow
and getPositionInWindow fills in the wrong values. This newly discovered
bug is tracked as 62839113.
In a second bug, introduced in the SurfaceView refactoring,
we are not appropriately clearing the last RenderThread reported
position when toggling visibility. This means that even after the
setVisibility call when getPositionInWindow begins returning
the correct values, we don't update the position. This CL fixes
that and fixes 62653411 as a result. However we still have a flicker
as we did in N as the initial position is wrong.
Test: Manual from bug, go/wm-smoke
Change-Id: I1037b8dfdb343f9ce8c8616eb9197c6d039ed133
Fixes: 62653411
Bug: 62839113
Add the shared libs that are APKs to the native library
path when creating application class loaders. Also don't
allow shared libraries hosting native libs to request
extraction of the native libs out of the APK. Lastly,
shared libraries hosting native libs must be declared
as multi-architecture.
Test: CTS tests in this topic
bug:62720360
Change-Id: I0a398593ebe41b2976cb706ca8a388005f5aec83
Creating the surface for every change (such as creation and
visibility) can lead to issues swapping buffers. This
changelist limits the action to only when the size changes.
Change-Id: Ic549d244613a93a43a9f4ddf284bbfb0c13300fa
Fixes: 62801621
Test: follow repro steps in bug, verified no crash.
Test: go/wm-smoke
Causes too many GCs and related slowdowns.
Verified that assistant launch from holding down home button is now
faster than N.
Test: make and flash
Bug: 62769566
Change-Id: Ib0c1f7a45831b241d3376d1e56db3c6937913b1b
Fixes: 62678460
Test: Tap recents while the dialog is shown and ensure it's not in a
separate task
Change-Id: I0572ddc84d76643ac8a373939273c221ff20676f
onCreate might be called with a state not produced by
onSaveInstanceState. In this case the last autofill ID is not set, so we
incorrectly restore it to NO_ID instead of LAST_APP_AUTOFILL_ID
Change-Id: Id40c06bf223c0e3c6235b2d50779e3f4532898b5
Fixes: 62296699
Test: cts-tradefed run cts-dev -m CtsAutoFillServiceTestCases
(cherry picked from commit 1266d08be5)
Override dispatchTouchEvent for the root FrameLayout
of NavigationBar to process ACTION_OUTSIDE MotionEvents
and dispatch directly to DeadZone to keep track of the
most recent outside tap.
Clarified documentation of ACTION_OUTSIDE behaviour.
Bug: 37552674
Test: open IME, tap any key, then quickly tap on top half
of the home button. The home button tap is ignored
and device does not go to homescreen.
Change-Id: Icb5cf6c76959f3514b8b94c09e38cc5434f31b23
