summaryrefslogtreecommitdiff
path: root/packages/SystemUI/src/com/android/systemui/usb/UsbResolverActivity.java
Commit message (Collapse)AuthorAgeFilesLines
* Set flag to disallow non system window overlays to prevent tapjackingBadhri Jagan Sridharan2021-10-251-0/+3
| | | | | | Bug: 183609854 Test: manual Change-Id: I4e63a98c875742ef0068d381d5fd4ec38c267768
* Initialize intent to avoid nullpointer exceptionPhilip Junker2021-10-211-0/+1
| | | | | | Fix: 203586231 Test: Manually flashed, installed two apps that can handle USB devices, verified dialog opens as expected. Change-Id: I146301c24ca161d5f5ae68f9943120c8fa137a29
* Fix UsbResolverActivity SuperNotCalledException (pt2)Mark Renouf2021-10-041-4/+2
| | | | | | | | | | | | Instead of calling the normal path, this change creates a path to call Activity#onCreate directly and avoid initializing state when the activity is about to self finish() Bug: 201719995 Test: adb shell am start -n com.android.systemui/com.android.systemui.usb.UsbResolverActivity Change-Id: I40ee792e341b828a3e288b1fc713f6df13728b4a
* Fix UsbResolverActivity: SuperNotCalledExceptionMark Renouf2021-10-011-0/+4
| | | | | | | | | | | | | | | | Results in a quick crash of the systemui process when called with out args. (error path skips super.onCreate) Unfortunately, broadcast receivers are also registered in #onCreate, but unregistered in #onStop. Since the activity is created but not started, stop isn't called resulting in a leaked receiver. Calling onStop() here fixes this. Bug: 201719995 Test: adb shell am start -n com.android.systemui/com.android.systemui.usb.UsbResolverActivity Change-Id: Id76491fe4779df14e54969b9ab04ef2f772c293c
* Refactor USB permission and confirm dialogs.Philip Junker2021-09-291-1/+4
| | | | | | | | | | | | | | Avoid null description in dialog by falling back to UsbDevice#getDeviceName() and UsbAccessory#getManufacturer() and UsbAccessory#getModel(). Use config_usbConfirmActivity value instead of UsbConfirmActivity.class in UsbResolverActivity. Bug: 196780010 Test: Flashed pixel device with custom build containing the change Test: Open camera app that requests access to USB camera. Verify that TvUsbPermissionActivity is shown and verify functionality. Test: Have an app installed which registers for USB_DEVICE_ATTACHED broadcast in its AndroidManifest. Attach USB camera device and verify that TvUsbConfirmActivity is shown and verify functionality. Test: atest UsbPermissionActivityTest Change-Id: I89c4176ccd5852f5b11955d65cbf05caf5260946
* Disable tabbed view support for UsbResolverActivity.arangelov2020-02-181-0/+5
| | | | | | | | | UsbResolverActivity extends ResolverActivity, but it should never show a tabbed view if there is a work profile on the device. Test: none Fixes: 149749166 Change-Id: I4ea713a32d4b85820e42b4e3ab60c9da54814fdc
* Adding USB Recording warning message to UsbResolverActivity.Paul McLean2019-11-041-0/+4
| | | | | | | | | | Bug:136080195 Test: install UsbAccess and UsbPersistentPermissionsTestApp (both want to handle USB connection events). Notice the new warning message for the app(s) that haven't been granted record permission. Change-Id: I651ae5e6314a2d59ed4537aa7d7785e27e3b1a52
* Separate adapter logic from ChooserActivity and ResolverActivityarangelov2019-10-291-0/+1
| | | | | | | | Test: atest com.android.internal.app.ChooserActivityTest Test: atest com.android.internal.app.ResolverActivityTest Bug: 142537267 Bug: 142538125 Change-Id: Ia4a61e3dc7cbac5c31e0d5b126e033a043c81d90
* Fixes import ordering.Gus Prevas2018-11-141-2/+2
| | | | | Test: n/a Change-Id: I432e11b52deb7974e50f62076af3b7aa07e364b6
* Fix interaction w/ work profile & last chosenHakan Seyalioglu2017-02-131-2/+1
| | | | | | bug: 34677697 Test: New unit tests added Change-Id: Ibb5c804c16a758ff041ce7165fda561d903b5f31
* Make default USB handling apps per profile group.Philip P. Moltmann2016-09-151-11/+66
| | | | | | | | | | | | | If a USB device is plugged in a default app might be started. As the user does not indicate which profile he is interested in by pluggin in a USB device, all handling of this operation has to be per default group. To do this Split UsbUserSettingsManager into UsbUserSettingsManager and UsbProfileGroupSettingsManager and modify UsbProfileGroupSettingsManager. Bug: 29233186 Change-Id: I8e56b621eeb802966504360d372a8a0140106114
* Add alternate intents and refinement callbacks to ChooserActivityAdam Powell2015-05-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow a calling app to supply an array of additional Intents to the system ChooserActivity. The chooser will present a merged list of targets that can handle any of the Intents supplied, including both the standard EXTRA_INTENT as well as any of the intents supplied in EXTRA_ALTERNATE_INTENTS. These are treated as ordered; EXTRA_INTENT is considered the first/primary Intent and EXTRA_ALTERNATE_INTENTS are sorted most important first. Targets are queried for all supplied Intents. If the same component is returned for more than one Intent, the target is associated with the most important Intent that matched. This allows calling apps to supply several different payloads for an action depending on what the intended targets are able to support. For example, an app performing ACTION_SEND may supply image/jpeg data to compatible targets or a hosted web link to targets that only support text/plain. The user will have the opportunity to pick from a single merged list of choices using the best available payload, and will not be bothered with the implementation details of how the payload will be delivered to the recipient. If the calling app wishes to provide further disambiguation or refinement after the user makes a choice, for example to let the user choose which of the source intents to send from the primary or alternates, show a progress dialog as a full-resolution version of a photo is downloaded from the server before being sent along or while reticulating splines, the caller can supply an IntentSender to ACTION_CHOOSER including the extra EXTRA_REFINEMENT_INTENT_SENDER. This should be the IntentSender obtained from a PendingIntent pointing at an activity to launch to perform the refinement. The refinement activity should report that it is finished by obtaining the ResultReceiver from EXTRA_RESULT_RECEIVER. Available intents to send to the selected target will be contained in EXTRA_INTENT and EXTRA_ALTERNATE_INTENTS. To complete the refinement and send the result along to the chosen target, the refinement activity should select one of the supplied intents and send it to the ResultReceiver in a Bundle with the key EXTRA_INTENT and the result code RESULT_OK. To cancel the refinement, and let the user select another choice, send RESULT_CANCEL. While refinement activities cannot modify the filterEquals-affecting fields of the Intent they return, they may modify extras to provide additional or altered details to the final recipient. These extras will be filled into the Intent sent to the final target. Change-Id: I7ad4739eadd1a0e307675847ccf47ea948918a3a
* Implement ChooserTargetService querying for ChooserActivityAdam Powell2015-04-131-2/+3
| | | | | | | | | | | | First cut at querying services provided by apps that offer ChooserTargetServices. This first implementation provides no ranking. Bind to a limit of 5 ChooserTargetServices and offer the ChooserTargets they provide as options in the system ChooserActivity. The chooser now presents targets as a grid and displays the activity icon from the referrer activity. Change-Id: I45db829f184fc78d4f18d42b2a60b25bc301eba8
* Make USB services multi-user aware.Jeff Sharkey2012-10-021-8/+10
| | | | | | | | | | | | | | USB settings are now isolated per-user, since they revolve around installed packages. User-specific settings are returned based on calling user, or referenced by UserHandle passed to SystemUI. Each settings Context is wrapped as a specific user, so all broadcasts are sent correctly. Upgrades any existing USB settings to OWNER. Physical events, like new devices, are routed to the currently active user. Switch to using AtomicFile when persisting settings. Bug: 7244888 Change-Id: I8a723ad3d55ac1bff99276c5f3a3f5e8f013432f
* USB Manager string clean up:Mike Lockwood2011-03-151-0/+12
| | | | | | | | | | | - Use "Cancel" instead of "Ignore" - Customize the text for the "always use" checkbox for devices and accessories - Clean up strings for AccessoryChat test program Bug: 4074719 Change-Id: Ideec838e4c1f1a82ef4ae411c9124417ffb63165 Signed-off-by: Mike Lockwood <lockwood@android.com>
* Add a dialog to ask user to start an application for a USB device or accessoryMike Lockwood2011-03-131-5/+1
| | | | | | | | | | | This is used when there is only one application available and the user has not chosen to start it by default. If more than one application is available we continue to use UsbResolverActivity Bug: 4074719 Change-Id: Id61f2ccc6de5b9ac70fb4670006ff1fee2028d55 Signed-off-by: Mike Lockwood <lockwood@android.com>
* Close USB dialogs if their corresponding accessory or device has disconnectedMike Lockwood2011-03-081-12/+33
| | | | | | | BUG: 4060065 Change-Id: Ib517e5e4a5422f9f0c8fca601308cecf7743c5d1 Signed-off-by: Mike Lockwood <lockwood@android.com>
* USB: Add API and dialog for apps to request permissions for USB devices and ↵Mike Lockwood2011-03-081-0/+101
accessories New APIs: UsbManager.hasPermission returns true if the caller has permission for the given device or accessory UsbManager.requestPermission poses a dialog to allow the user to give the caller permission for the device or accessory. Result is returned via a PendingIntent. No dialog is displayed if the caller already has permission. Also moved UsbResolverActivity to SystemUI package BUG: 4069037 Change-Id: I93be769501a8776b49ac26e468af19f8fa2114c9
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-12 15:58:28 +0000