On some devices, the USB "set configuration" command is propogated to the framework
after the "start accessory" event is received. However, on other devices like
the 2011 ADK board, no "set configuration" command is sent at all until we have
reenumerated in acccessory mode. To fix the original problem without breaking other
devices, we can simply remove assumptions about if or when "set configuration"
will be received. Now we simply remain switch USB configuration to accessory mode
when we receive the "start accessory" command, and remain there until the existing
10 second timeout expires.
Bug: 13393825
Change-Id: I4c9e3423185bd7252a907e4568d9e3ff06044b7d
This reverts commit fbd5521fb5.
This change broke support for the 2011 ADK board, which never sends a "set configuration"
command before "accessory start". So we revert this change and will replace it with a better fix.
Bug: 13535051
Bug: 13393825
Change-Id: Icd870d7ff6daff1567e04d93907f70f5d7e37884
When switching USB modes there are often spurious connect and disconnect events
that occur before reenumeration is complete. There is currently a 1000ms timer
to "debounce" the disconnect events. But with some USB accessories, this timeout
is not long enough, which results in an endless cycle of attempts to enter
USB accessory mode when the phone is connected.
To fix this, we now wait up to 10 seconds for the host to successfully configure
the device when entering USB accessory mode before giving up.
This is separate from the existing debounce timer, so the behavior of the
USB state change broadcasts are not affected.
Bug: 12877769
Change-Id: I7aa61f8a618546d749a7ddfc97bf103029a73d03
The UsbDeviceManager is using a Scanner to identify
the ALSA card/device numbers to use for USB Gadget
audio, with a FileInputStream as its input.
Since FileInputStream implements the Closeable interface
it provides a close() method that should be explictly
called in order to close the stream source and release
any system resources that it might hold.
Change-Id: Ia0ff86d1f3cdf8916becec9c8603915dcbf4d2c8
This introduces four generic thread that services can
use in the system process:
- Background: part of the framework for all processes, for
work that is purely background (no timing constraint).
- UI: for time-critical display of UI.
- Foreground: normal foreground work.
- IO: performing IO operations.
I went through and moved services into these threads in the
places I felt relatively comfortable about understanding what
they are doing. There are still a bunch more we need to look
at -- lots of networking stuff left, 3 or so different native
daemon connectors which I didn't know how much would block,
audio stuff, etc.
Also updated Watchdog to be aware of and check these new
threads, with a new API for other threads to also participate
in this checking.
Change-Id: Ie2f11061cebde5f018d7383b3a910fbbd11d5e11
This is called from Settings that has a button to clear secure
adb public keys installed on the device.
Change-Id: I63ef499c049766ef13ea6cb0594ed6719f35e5f3
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
Fixed one setting that was migrated but not marked deprecated.
Removed a hidden setting that is no longer used by the new
power manager service.
Bug: 7231172
Change-Id: I332f020f876a18d519a1a20598a172f1c98036f7
Also fix a bunch of system services that should be doing this. And
while doing that, found I needed to fix PendingIntent to evaluate
USER_CURRENT at the point of sending, not creation.
Note that this may end up with us having some notification shown to
non-primary users that lead to settings UI that should only be for
the primary user (such as the vpn notification). I'm not sure what
to do about this, maybe we need a different UI to come up there or
something, but showing the actual notification for those users at
least seems less broken than not telling them at all.
Change-Id: Iffc51e2d7c847e3d05064d292ab93937646a1ab7
The current MTP kernel driver at /dev/mtp_usb is exclusive, meaning
only one process can have it open. In addition, each MTP session
with a desktop requires unique object IDs, which doesn't hold true
across users on the device.
To solve these two issues, when switching users we cycle the USB host
stack to disconnect both local and remote MTP connections, giving the
new user's media process a chance to claim /dev/mtp_usb, and causing
the desktop to initiate a new MTP session.
This change also allows BroadcastReceivers to registerReceiver()
allow retrieval of a current sticky broadcast. Adds a system property
to override maximum users. Removes MOUNTED broadcasts for secondary
users. Allows INTERACT_ACROSS_USERS to getCurrentUser().
Bug: 6925114
Change-Id: I02b4a1b535af95fb2142655887b6d15a8068d18a
When building external storage paths, always include user in path
to enable cross-user paths and aid debugging.
Each Zygote process continues to only have access to the appropriate
user-specific emulated storage through bind mounts. A second set of
mounts continue supporting legacy /sdcard-style paths. For example,
a process running as owner has these mount points:
/storage/emulated_legacy
/storage/emulated_legacy/Android/obb
/storage/emulated/0
/storage/emulated/obb
Since Environment is created before Zygote forks, we need to update
its internal paths after each process launches.
Bug: 7131382
Change-Id: I6f8c6971f2a8edfb415c14cb4ed05ff97e587a21
You can now use ALL and CURRENT when sending broadcasts, to specify
where the broadcast goes.
Sticky broadcasts are now correctly separated per user, and registered
receivers are filtered based on the requested target user.
New Context APIs for more kinds of sending broadcasts as users.
Updating a bunch of system code that sends broadcasts to explicitly
specify which user the broadcast goes to.
Made a single version of the code for interpreting the requested
target user ID that all entries to activity manager (start activity,
send broadcast, start service) use.
Change-Id: Ie29f02dd5242ef8c8fa56c54593a315cd2574e1c
The UsbDebuggingManager listens to adbd requests and displays a dialog
when the public key authentification fails, for the user to confirm if it
wants to allow USB debugging from the attached host. If the user chooses
to always allow USB debugging, the UsbDebuggingManager writes the public
key to adbd's config file so that the public key authenfication succeeds
next time.
Change-Id: I115c828331d8e326c380844ee33915d5dff22260
In this change, only the USB audio accessory support is implemented.
Change-Id: Id9b411319b07a96dc56649ca74cc5f3f89a55a7c
Signed-off-by: Mike Lockwood <lockwood@google.com>
Two parts to this:
1. Stop treating FLAG_ONGOING_EVENT notifications specially
(in particular, ordering them at the top of the panel).
2. Set the priority bits on the system UI notifications
appropriately (low).
Change-Id: I3bde7e573654c5aad5e1c5d29e6a21ba94edcc5b
If you cleared the last usb mode it would fail (and so would setting
it if you started with none). This fixes it to set and unset the
last property correctly.
Change-Id: Ice5be6e57b6ca6b8c9241b0ac62071a3bc72606a
This patch is adding a capability so that OEM can override USB mode
in case the device is boot up with OEM specific mode. (i.e. modem
debug, factory test etc.)
Bug:5964042
Change-Id: Ic8e23d302563ce71eedb74ce94cca8c65838a4f7
We now use Intent.makeRestartActivityTask() to build the notification
PendingIntent objects, so that when tapped they restart the activity
in the desired state.
Fixes bug 5011926
Change-Id: Ie1ec3543cc0f49d1bd407622a617316cf53a078c
to avoid ID collisions with other system services.
Bug: 5161005
Change-Id: I069fbc40a8764bc85cceeacd04264abd32b62668
Signed-off-by: Mike Lockwood <lockwood@android.com>
since USB tethering already has a notification.
Bug: 4988511
Change-Id: I928cb1e1d191c77340f7f05edfa80a74cdabe6ed
Signed-off-by: Mike Lockwood <lockwood@android.com>
Also defer anything that could start an activity from "system ready"
to "boot completed" time.
Bug: 5051683
Change-Id: I69db751cb991dd247bd0ac3c70a0d84c0d71f365
Signed-off-by: Mike Lockwood <lockwood@android.com>
This makes it more robust when recovering from runtime restarts
Bug: 4986841
Change-Id: I54b94213447130ca881c66da2d0ce490242f0c96
Signed-off-by: Mike Lockwood <lockwood@android.com>
This will allow us to recover if we crash while changing USB configurations
Change-Id: I22ba9a1ff0a8bcbfd4a0f18af0c95a3b66b99060
Signed-off-by: Mike Lockwood <lockwood@android.com>
We now have different strings depending on the current USB mode.
Change-Id: Icc6392d5700a6fee008b75287d8eb0f06db1d880
Signed-off-by: Mike Lockwood <lockwood@android.com>
Due to the property trigger on persist.sys.usb.config,
setting the default function also sets the current function.
Now we combine both of these methods into setCurrentFunction, which has
a "makeDefault" option to make the new function the default.
This change should eliminate some problems with setting properties due to
multiple property triggers happening at the same time.
Change-Id: I9851299e9c2ee20475eada1a8104c0d50bf5a9e1
Signed-off-by: Mike Lockwood <lockwood@android.com>
This change adds a notification when USB is connected.
Selecting the notification brings up a dialog to allow switching between
MTP and PTP modes, and also allows mounting a CD image for installing AFT.
The UI design is not final - this is a temporary implementation of the UI.
Change-Id: Idd678537aba595fd4cb183ea755bf437f372d826
Signed-off-by: Mike Lockwood <lockwood@android.com>
