Gracefully handles situations where a default app cannot be found
to handle the intent.
1. If we can not find any app to handle the intent,
do not include an "assist" menu item entry to fire the intent.
Also, do not linkify the entry.
2. If we do not have a default app to handle the intent,
show a generic title for apps that will handle the intent
and do not include an icon.
In the ideal case where we find a default app to include the intent,
show the app's (preferably activity's) title and icon.
Test: Manually tested. There's an AI to write more automated tests.
Bug: 34777322
Bug: 34927631
Change-Id: Ia94efbbdda3da8f181fac9228cd2d3a76cb727d3
- Introduced TYPE_APPLICATION_OVERLAY window type. Can be used by apps
to display windows on top of other app windows, but below critical
system windows.
- Deprecate alert window types TYPE_PHONE, TYPE_SYSTEM_ALERT,
TYPE_SYSTEM_OVERLAY, TYPE_PRIORITY_PHONE, and TYPE_SYSTEM_ERROR.
Apps should now use TYPE_APP_OVERLAY for this.
- Apps targetting O or greater are not allowed to add the old alert
window types.
Apps targetting less than O can still add the old types.
Apps with permission INTERNAL_SYSTEM_WINDOW (system signature apps) can
still add the old types.
- Z-order old alert windows types below TYPE_APPLICATION_OVERLAY if
they are added by an app without the INTERNAL_SYSTEM_WINDOW permission.
Test: android.server.cts.AlertWindowsTests
Bug: 33256752
Change-Id: I12170955a7a333151d3387c169b51c53c32164fc
This is a preparation CL for fixing Bug 32343335, where we aim to
avoid unnecessary reconstruction of InputMethodInfo objects by caching
immutable part of those metadata by APK revisions.
The reason why we have had to pass additional subtypes not just as
List<InputMethodSubtype> but as Map<String, List<InputMethodSubtype>>
to create an instance of InputMethodInfo is that how to compute
so-called IME ID is not exposed from InputMethodInfo even as @hide
method.
In practice it has been calculated as
new ComponentName(packageName, serviceName).flattenToShortString()
and those IDs are already stored here and there including secure
settings. It is almost impossible to change the rule anymore hence
we should consider them to be a kind of public API.
This CL adds a @hide static method InputMethodInfo#computeId() to
make it clear. This also enables us to simplify the constructor
of InputMethodInfo finally, because we have used IME IDs as keys
in subtypes.xml, where additional subtypes are stored.
Test: Manually verified that addtional subtypes still work
Test: checkbuild
Bug: 32343335
Change-Id: I1deaa470e042eac749e7a847933d14448a0d9e03
When EXTRA_QUICK_VIEW_PLAIN is passed, then plain UI should be shown.
This is just a hint for third party apps, whic may ignore it.
Test: Not testable, as it's just a hint.
Bug: 32161075
Change-Id: Ie244d28d552f6c654be93a5749ac164d2a77d25f
This static method returns a NetworkCapabilities instance with
transports and capabilities set according to the given legacy type.
Also:
- add NetworkRequest.Builder.setCapabilities(), to be able to use
the NetworkCapabilities instances returned from the above
- update UpstreamNetworkMonitor to make immediate use of this
Test: as follows
- build (bullhead)
- flashed
- booted
- runtest frameworks-net passes
- WiFi to DUN upstream tethering works
Bug: 32163131
Change-Id: Idfe1ddd2815c355cbf27cf29eb0e3de177de84e9
This CL hides warning and info log messages from
InputMethodManagerService (IMMS) and InputMethodService (IMS) behind
DEBUG flag like other logs unless the state is certainly unusual.
Of course the definition of "unusual" is still an open question, but
basically that we should not see any suspicious message from IMMS/IMS
just by turning on a new phone, launching some applications, typing
something, and turning off the device. IMMS and IMS should expect all
events that can (easily) occur in that scenario, and no log is
necessary for such things.
Note that warnings suppressed with TODO comments will be tracked
under Bug 34851776 (and Bug 34886274).
Test: adb logcat -s InputMethodManagerService:* InputMethodService:*
to monitor log in the following scenario:
1. Boot the device.
2. Complete the setup wizard.
3. Launch Dialer and type something on it.
4. Launch Contacts app and type something on it.
5. Try some special modes:
- Turn on/off display
- Recents screen
- Split-window mode
- Guest user
- Multi user
- Direct-boot (setup a device password and reboot)
except for logs about actual IPC calls from a background user.
Bug: 34838583
Bug: 34851776
Bug: 34886274
Change-Id: I3fcdeb919bb2f2940da9ff45e17ac00baa1253f4
Currently, the onProvideAutoFillStructure() methods can be called
twice: to auto-fill an activity and to save the activity's data
in the service.
The problem with this approach is that when the save workflow is
called, the activity might have been gone. Hence, a proper approach
is to keep the initial AssistStructure data in the system_service
memory, watch for view changes, and then passed the new structure
back to the AutoFillService.
A side effect of this change is that we need another way to determine
if the view is sanitized or not. For "standard" views, that will be
defined based on whether the view content come from a resource or not,
but that logic is not implemented yet (for now, all views will be
considered sanitized, except for TextView passwords). For "custom"
views (such as WebView), this logic is responsibility of the view
implementation, through the newChild() method, which now takes a
flag (whose value could be AUTO_FILL_FLAG_SANITIZED for sanitized
views).
The SaveCallback.onSuccess() method was simplified: it does
not need a list of saved ids anymore the auto-fill UI will not use it
anymore.
Another side effect is that the Save notification is gone - until
it's attached again, it can be test by using:
adb shell cmd autofill save
Finally, hook AutoFillUI on ACTION_CLOSE_SYSTEM_DIALOGS events.
BUG: 33269702
BUG: 31001899
Test: manual verification
Test: CtsAutoFillServiceTestCases passes
Change-Id: I907a7e21d1b3cd1ab6dec3a08d144a52655da46f
Mentioned that in the documentation, cleaned up the code
a bit and added unit tests
Bug: 34614754
Test: runtest -c com.android.server.devicepolicy.DevicePolicyManagerTest frameworks-services
Change-Id: I91232bbe494398015094ab977c6a2adce339811f
And move references to the deprecated fields to
NotificationRecord for testability.
Test: runtest systemui-notification
Change-Id: If3910dc78297ad66679b1efa380315127261a018
Using a WebView package targeting a release before O as WebView provider
on O will cause crashes (because of incompatibility issues), this CL
makes us interpret a package targeting a pre-O release as being invalid
on O.
Also remove the code that lets us fall back to loading the old
WebViewChromiumFactoryProvider (pre-O) class.
Bug: 34773740
Bug: 34180497
Test: Ensure WebView provider with targetSdkVersion="O" shows up in the
WebView Implementation Dev Setting, ensure targetSdkVersion=25 doesn't
show up.
Test: Add WVUS unit test to ensure a packages with targetSdkVersion < 26
are considered invalid, and > 26 are valid. Run WVUS unit tests.
Change-Id: I4d80d46019e2522bc3fc6068712d28eedb31fcce
