The decision whether to show or hide the "Usb supplying power.."
notification is based on two different broadcasts
1. USB_DEVICE_ATTACHED/DETACHED
2. USB_PORT_CHANGED
Depending on how long the port takes to enumerate, the required
intents might arrive in different order. Previously, it was assumed
that the ATTACHED broadcast would arrive before the PORT_CHANGED
broadcast and the code was aggressive to reduce the number of
times the decision to display/hide the notification is made.
This might cause the notification to be displayed in some instances
when it is not supposed to be displayed. This CL makes the usb service
to always reevaluate whenever USB_DEVICE_ATTACHED/DETACHED is
received.
Also, adding logs to print whenever the notification in enqueued/
dequeued.
Bug: 63785369
Test: Verified that the notification is displayed when connecting
to another pixel device and hidden when mouse or headset is
connected.
Change-Id: I30650a2d9923d01a1fce4b9450e65ec7f4e6557b
Accessory connects / disconnects can occur before
boot complete, so don't broadcast intents if that
is the case.
Bug: 63114621
Test: connect/disconnect an accessory
Change-Id: Ib8f9eb97ce1630004511fcc1fb84594ccc812c06
We got a report from a user in which ptp was set in the
persistent config, likely from a previous version.
This causes errors in the usb state and is not removed
by an ota. To fix, remove ptp in the same place that mtp
is removed from the persistent config.
Bug: 62202885
Test: Add ptp to persistent config, verify removed.
Change-Id: I5ebd93b9c8a49bcaca5a3362e49ed1e1acf50a9b
Clients (viz. Tethering) use UsbManager@setCurrentFunction(null, ..)
to make the device switch to default functions. While in OemMode,
this gets set to the last enabled functions list. Instead,
enable MTP or ADB depending on whether ADB is enabled or not.
This is the expected behavior for normal boot as well.
Bug: 37491031
Test: Verified that the device falls back to either mtp or adb while
in OemOverride mode.
Change-Id: I1c26d1d0ee3c015b597d40771cd765b783cd91bb
Some users depended on adbd continuing to run after disconnect
in order to use scripts with nohup. This change allows this
use case to keep working since only mtp has to be force
set.
Bug: 38227228
Test: adb shell "nohup sh /sdcard/script" where script contains
"sleep 5; touch /sdcard/done" and verified file still appears even if
disconnected during sleep.
Test: am force-stop com.android.providers.media, still connects
Change-Id: I25ae2b922fa4d06109ac8cf5e43e1c47a33c46a6
A forward match is a intent-target (aka. match) that switches between the
personal and work profile's intent resolver.
This can be unnecessary if there are no work profile matches.
We need to remove these unnecessary matches early as the default activity
resolution code considers a system app as default _only_ if it is the only
match. Before there could still the an unnecessary forward match under
consideration.
Test: Connected USB accessory that only matches a system app on the personal
profile.
Before we showed a confirm-dialog, now we consider the system app
as default and automatically launch it.
Fixes: 37530439
Change-Id: I7bc9b969fc0b9abae4d15dd3f268783d05b91f9a
Once a user plugs in a USB device (or accessory) the user can decide
which app should be started by default once the device is plugged in.
I.e. this app becomes the "default" for this USB device. If the user has
a work profile the default app is set for all profiles of the current
profile group (i.e. personal and work profile) as at any point in time
one profile group is visible on the screen.
There were some issues in the code:
- fix small obvious bugs
- use userPackage (==packageName + user) everywhere instead of only
packageName as we have to distinguish between apps of different
profiles.
- Stop accessing userPackage.packageName whereever possible to avoid
mistakenly ignoring the user
- Monitor packages of all users and deal only with users of the current
profile group.
- Do not react to package changes/updates/modifications. While it is
possible that an app gained the ability to deal with new USB devices on
update, we should not clear the default app for a default device. This
is because (1) this situation is exceedingly rare and (2) we do not
easily know when an app gained the ability to deal with a device. The
user can still manually clear the USB default app via Settings.
- The old DeviceFilter.matches code did not make sense. An app that
wanted to replace the previous default app would have needed to know
the serial number of the device.
Test: - Searched for access to UserPackage.packageName and we only use it
directly three times now. I checked these occurances and it is save
to use.
- Ran the following test
- Install app that can handle a USB device in personal profile
- make this app the default for this USB device
- Install same app in work profile -> default was be cleared as
it is not clear if the user
might prefer the other app
- make the work app the default for this USB device
- update non-work app -> default should not be cleared as the the
update is usually not triggered by the
user and we should just keep the
selection the user made before
- update work app -> App is already default
- uninstall work app -> default should be cleared as the default
app was removed
Fixes: 36610004
Change-Id: I294b582c36228169ac12a02d8007a4541e386d57
Functionfs no_disconnect mode will close the function on
disconnect so the current handling won't suffice for cases
where the mtp process is killed while MtpService is running.
This can happen when anything in Media/DownloadProvider ANRs
or similar.
Solve this by always setting the config at disconnect time.
Bug: 38010151
Test: Connect with MTP, am force-stop com.android.providers.media,
reconnect
Change-Id: Iaf012f6e2f11151f34d834efe08777dd02c0aec5
This CL pops up a notification to the user when the device does not
support Analog Type-C headphones but the user connects one.
i.e when the Usb port status reports currentMode=audio_acc, but
audio_acc is not present in the supportedModes list.
Bug: 36604276
Test: Manually test inserting an Audio accessory
Change-Id: If514b9f238da196a7157e1aacb6d7690fde66f21
Replace public by private or package access in field declarations,
and add getters and setters as needed.
Test: compiles OK
Change-Id: Ief3fffb6a21d2e4d05153839f444617ea5e70846
This CL adapts Usb service to V1_1 hal.
V1_1 hal supports reporting audio_adapter accessory
and debug accessory.
Bug: 36604276
Test: Manually test inserting an Audio accessory.
Also tested to made sure that change is compatible with V1_0
implementations
Change-Id: I8e44f5e9ae14b0e41965e8d355c99ac42af93f23
Because of flag INTENT.ACTION_REPLACE_PENDING, intents
sent in rapid succession could replace previous intents
that have not been processed, and it is unreliable when
or whether this happens. Since CONFIG_CHANGED cannot afford
to be lost, make sure it is sent last, so it is always
processed.
Bug: 34873000
Test: lots of unplugging/plugging
Change-Id: I9264d5129139cf3f433bbcd068e8b292fec6cd31
Since we are adding ffs.mtp.ready to the init
scripts, we can no longer skip intents that cause
that property to be set.
This fixes the case where device is disconnected
and adb is repeatedly enabled/disabled.
Test: enable/disable adb, usb mtp
Bug: 33220530
Change-Id: I48e687c1af3f9da9e522ebe879285877c0168da8
Because of flag INTENT.ACTION_REPLACE_PENDING, intents
sent in rapid succession could replace previous intents
that have not been processed, and it is unreliable when
or whether this happens. Since CONFIG_CHANGED cannot afford
to be lost, make sure it is sent last, so it is always
processed.
Bug: 34873000
Test: lots of unplugging/plugging
Change-Id: I9264d5129139cf3f433bbcd068e8b292fec6cd31
Previously HOST_STATE update intents would broadcast if the
device was in gadget mode but not configured. This would
override the sticky intent, causing MtpReceiver to fail.
This is fixed by only updating host state if host is connected
or if host is being disconnected (was connected before).
Bug: 34873000
Test: set up lockscreen, reboot device while plugged in, unplug before
unlocking, verify usb works.
Change-Id: Ic424e678ba72401ee8ec975e915727272edf3767
Bug: 37266276
Test: Manually tested the language of active notifications after
switching language.
Change-Id: I0cef61fbd155e0c9789f52a140561c71969fbab7
This CL makes logic for resetting the default package for handling USB
intents less agressive (added in ag/101452). First, instead of listening
for package changed events, we now listen for package replaced
broadcasts. Second, we don't reset the default package if the app being
added/updated is already the default package.
Bug: 35491880
Test: Manually tested with a work profile
Change-Id: Id1992239b5d8ace87fefeb4acd6ca1031c3c1085
This CL prevents the USB Dialog to show for peripherals such as
keyboard, mouse, flash drives etc. Usb Dialog is redundant in these
cases as the Type-C stack is expected to manage power automatically
as these devices are most likely SNK devices.
Bug: 36141499
Test: Manually tested that USB dialog doesnt show up when
a keyboard or mouse is connected.
Change-Id: I3ee45f137817425bf9acd675b044a97d1cb91d7d
The CL prevents the "Supplying power to the attached device"
notification from showing up when USB digital headphones are
connected. Although, the phone is actually powering the headphones
here, there seems to be an opinion that this might confuse the users.
So, disabling the notification for better user experience.
Also, the mode chooser activity might not be applicable here as
the headphones are not expected to be a dual role device in the
near future. When connected through a hub, the power management
of the Type-c link is expected to be managed by the Type-C stack
in the hub and phone's kernel. So user might not have to manage
the direction of power flow.
Bug: 36141499
Test: Manually tested that USB dialog doesnt show up when
digital usb headphones are connected but shows up otherwise.
Change-Id: I187da9c77e294cbbceb633365adbb4623fc14a3d
