Having a hidden abstract method for a class that can be extended
means that public implementors cannot implement these hidden methods
posing a risk that custom implementations will not have required
abstract methods resulting in an exception.
Bug: 151134792
Test: make update-api
Change-Id: I758d12465fabc671be19bedeeceb16885de23c87
Merged-In: I758d12465fabc671be19bedeeceb16885de23c87
Exempt-From-Owner-Approval: large scale suppression of existing issues,
no-op in terms of behavior
@SuppressLint("Doclava125") is a legacy way of suppressing
RequiresPermission check. Updating to the new style of suppression
so metalava no longer has to support the legacy mode.
sed -i "s/@SuppressLint(\"Doclava125/@SuppressLint(\"RequiresPermission/" \
core/java/android/app/admin/DevicePolicyManager.java \
core/java/android/hardware/hdmi/HdmiControlManager.java \
core/java/android/hardware/location/ContextHubManager.java \
core/java/android/hardware/usb/UsbDeviceConnection.java \
core/java/android/net/TrafficStats.java \
core/java/android/os/RecoverySystem.java \
core/java/android/os/storage/StorageManager.java \
core/java/android/service/persistentdata/PersistentDataBlockManager.java \
location/java/android/location/LocationManager.java \
media/java/android/media/AudioManager.java \
telecomm/java/android/telecom/TelecomManager.java \
telephony/java/android/telephony/CarrierConfigManager.java \
telephony/java/android/telephony/TelephonyManager.java \
wifi/java/android/net/wifi/RttManager.java \
wifi/java/android/net/wifi/WifiScanner.java
Test: make
Exempt-From-Owner-Approval: No-op change
Merged-In: I6d5df95cfca2950ea86872d2f0afc1ba828841dc
Change-Id: I6d5df95cfca2950ea86872d2f0afc1ba828841dc
- CarrierMessagingServiceWrapper is now a final class with only
APIs of direct actions on messaging.
- The original abstract parts of the class are now interfaces:
interface CarrierMessagingServiceConnectionCallback
and Runnable callback.
- CarrierMessagingCallbackWrapper is renamed to
CarrierMessagingCallback
Bug: 172087216
Test: build and manual
Change-Id: I1760623543b929a51ce26dc7dcc5f8ebe7fd9732
Merged-In: I1760623543b929a51ce26dc7dcc5f8ebe7fd9732
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Merged-In: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
Change-Id: I54e5ecd11e76ca1de3c5893e3a98b0108e735413
* For the case where the pinned inline suggestion triggers an
pending intent through the auth flow, and it returns a dataset
to be autofilled, previously we would replace the existing
dataset with the returned dataset. However, this is causing
several potential issues:
1. if the returned dataset doesn't contain inline presentation
the the pinned icon will not show again
2. if the returned dataset contains inline presentation but not
the pending intent, then the pinned icon will show up again
but tapping on it will not launch the pending intent
3. if the returned dataset contains the inline presentaion and
the pending intent, then when we "autofill" it, it'll fire
the pending intent directly as opposed to filling in the
value
* We fix the issue by not replacing the old dataset if the dataset
is a pinned inline suggestion.
* One caveat of the approach is that: a dataset can potentially
have multiple fields, and it's possible that some of the fields'
has inline presentation and some don't. It's also possible that
some of the fields' inline presentation is pinned and some isn't.
So the concept of whether a Dataset is pinned or not is
ill-defined. Here we say a dataset is pinned if any of the field
has a pinned inline presentation in the dataset. It's not ideal
but hopefully it is sufficient for most of the cases.
* An alternative approach is to have the autofill provider telling
whether they want to replace the old dataset or not, through
a new field in the returned Bundle. But that requres an API change
so is infeasible at this time.
Test: atest android.autofillservice.cts.inline
Test: atest android.autofillservice.cts.augmented
Test: atest android.autofillservice.cts.LoginActivityTest
Test: atest android.autofillservice.cts.AuthenticationTest
Bug: 159367101
Change-Id: I6d162aeb88a4655989c1aa315df8304c0980ac60
* Attach to each inline suggestion remote view the user id
and session id, which together identify a session. Then when
the session is destroyed, we release all the remote views
associated with the it.
* Worst scenario is that the IME is still showing the UI when
the remote view is released due to session destroy, in which
case the suggestion will disappear from the IME window. But
we also make sure we send an empty response to IME before
releasing the views, so it should be bad. Plus when a session
is destroyed, interacting with the suggestion UI doesn't do
anything, so it's not very helpful to show them.
* Also add a dump method to the InlineSuggestionRenderService
to help with debugging
Test: atest android.autofillservice.cts.inline
Bug: 154683107
Change-Id: I488fd9d9af08d0df3ffd3c851f96c567d07eed5a
Add possible conditions under which SystemUI may not prompt the user to
add a control.
Test: no test
Fixes: 159728016
Change-Id: I143e50cc15397d85b4212d9fb29d64df7c2de80c
* SurfaceControlViewHost#setView() method will post a task to the
main thread to draw the view. We want to callback the surface
package to the remote process after the view is drawn and ready
to be shown, to avoid the flicker when the remote process attaches
it to their window when it's not drawn.
Test: atest android.autofillservice.cts.inline
Bug: 157515522
Change-Id: Ia75baaf9d6a4770a783dfc75ebb01b4b6e62e180
It is hard to reproduce this issue, it would better add try-catch
for the augmented autofill UI as regular autofill UI did.
Bug: 149744098
Test: atest CtsAutoFillServiceTestCases
Change-Id: I808ac48476ef96b8944e762dd5c41413da3a2c2e
After 9118c9b the surface can be destroy after the window state become
invisible, since WallpaperService copy the surface from WMS and it is
not implement with ViewRootImpl, WallpaperService#Engine should call
relayout to get new surface when client need to redraw it.
Bug: 158955956
Test: verify the wallpaper can show by launch LiveWallpaperChange with
live wallpaper and push/pull it from recents several times.
Test: atest WallpaperServiceTest ImageWallpaperTest
Change-Id: I79f97df61696eea325183e9b9057cbb10ce8cc66
* The bug was introduced in ag/11784240 causing the existing CTS test to
fail: android.autofillservice.cts.augmented.AugmentedLoginActivityTest
#testCancellationSignalCalled_retriggerAugmentedAutofill
* Basically when the dropdown fill window is displayed, we should not mark
the augmented autofill request as complete
Test: atest android.autofillservice.cts.augmented
Test: atest android.autofillservice.cts.inline
Bug: 158864213
Bug: 158038231
Change-Id: Ifb75189c1ba3183c99516bfb9a7053524f4bbddc
Allow single taps as well as long press to launch the detail panel
when no template is specified.
Fixes: 158773087
Test: ControlsMockApp, any default type
Change-Id: I4d5451f6a5968d8dd223eb5b10d931ad60aad951
* The augmented autofill may dynamically request an autofill request
which will "invalidate" the old suggestions. In case the new request
doesn't return any suggestions, we need to make sure the old
suggestions are removed from the IME.
* See the scenario in https://b.corp.google.com/issues/158038231#comment14
Test: manual
Test: atest android.autofillservice.cts.inline
Bug: 157515522
Bug: 158038231
Change-Id: If85592395ad918197566a5ca556fba8ccc971071
Show a more informative error to the user on touch/long press about
how to handle this situation. Properly animate status changes.
Fixes: 154737944
Test: TYPE_DISPLAY in mock app simulates not found error
Change-Id: I15ce2d2621ea29c97936f9d9022d917637693288
* if the user taps quickly such that there is only ACTION_DOWN and
ACTION_UP, without ACTION_MOVE, it'd be possible that the
isSecure check is not respected. This patch fixes that case.
Test: atest android.autofillservice.cts.inline
Bug: 157772682
Bug: 158038231
Change-Id: Icd21bf2f88259673bb9b20e46e63672648495eac
The camera API, MediaStore.ACTION_IMAGE_CAPTURE requires apps to pass
a content:// URI with write permissions to the camera. Unfortunately,
apps haven't been doing this and we only started hitting problems in R
for two reasons:
1. The FileUriExposedException that should crash apps when they try to
share file:// URIs acroos binder is skipped. This is because, the
image_capture intent is passed across binder as a field in a
ChooserActivity Intent and the child intents are not checked for
file URI exposed
2. Prior to R, when camera gets a file:// URI, camera issues a file
open(2) in its process. This open(2) succeeds because the camera had
write_external_storage permission which gave it write access to all
files on external storage
Now, camera targets R and (2) fails because camera does not have write
access to files owned by other apps. To workaround, we do the
following in the apps process when it targets < R:
a. When we detect a file:// URI for the camera in an Intent, we create
the file on disk if it is not already created.
b. Scan the file to insert it in the database and retrieve a
content:// URI
c. Replace the file:// URI with the content URI in the image_capture
intent
This works because, the system will ensure the camera is granted write
access to the content URI.
Test: Manual
Bug: 156336269
Change-Id: I4849ff5e806a8207650ff7534846c36ecdc6d3c0
The finish() method is used to clear hard references after
the data copy has ended. This fixes a bug where the references are cleared before onError() is attempted to be called.
Test: CTS tests in followup CL
Bug: 157136368
Fixes: 157136368
Change-Id: If924fe388762831af90579e6b00bdf223230e203
