Previously, CameraManager handled a disabled camera service
implicitly, the same as it handles a temporarily-crashed camera
service.
However, the error reporting for the those cases isn't really the
same, so switch to being explicit - check for the disabled camera
service system property, and if it's set, short-circuit calls.
Test: Camera CTS continues to pass, Watch device with no camera
service also now passes camera CTS.
Bug: 62269118
Change-Id: I65a97f8c1b0f101999b2c04d4f1096b7f3aee858
(cherry picked from commit 19d96a197f)
Add note for VPN developers that VPN apps started in the background must transition to the foreground in Android O to avoid the system stopping them.
Staged at: go/dac-stage/reference/android/net/VpnService.html
Test: make ds-docs
Bug: 38023983
Change-Id: I33c7ca1717c332ffab495eb51c4c6b9c5c304cef
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
Java doc was left out when addressing API reviewer comments.
This CL fix the discrepancy between the actual logic and java doc.
Bug: 36550285
Test: compiles
Change-Id: I6406892ecdcc5d02f11966fa3fb0b81ed8d3b285
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
This functionality will only be available for signed system applications.
A disable call will cause a file descriptor to the input device
driver to be closed, which in turn may cause the input device
to switch into a low-power mode.
An enable call will reopen the input device.
Bug: 30143923
Test: developed a custom apk with signature permission that
calls disable/enable on touchscreen device. Verified that
touchscreen stops working when disable is called and starts
working again when enable is called. Verified that the file
handle to the driver is closed and reopened. Verified that
the notification onInputDeviceChanged is received in the app.
CTS test - android.view.cts.InputDeviceEnabledTest
Change-Id: Ia352deb548b73559f821afd586893393d39a0696
