Handle the case where the kernel driver is in accessory mode but we failed
to initialize it at the framework level. On disconnnect, check to see if the
accessory kernel driver is enabled rather than checking mCurrentAccessory.
That way we will restore the USB state in the kernel even if mCurrentAccessory
is null.
Change-Id: I35d458f21a8b21611946da523d0f53723cab0540
Signed-off-by: Mike Lockwood <lockwood@android.com>
If you deleted the host routes (started a secondary network like mms, supl
of hipri and then ended it) you would lose the host route to the default
gateway. Then if you needed to re-add the default gateway route (lost
the connection and removed the default route and then re-established)
you couldn't - can't add a gateway that isn't routable apparently.
This happens if you are in a video chat and lose your connection without
losing the interface (PPP keeps it up for a bit).
Fixed it by having addDefaultRoute first add a hsot route for the gateway
before adding the default route. This allows the default add to succeed.
bug:3490353
Change-Id: I415e7319832e6456f8757b14c4f79f098a08839b
o Update the copyright date on InputDispatcher_test.cpp and InputReader_test.cpp
because these two files were moved from other places to the current location,
and were actually created in 2010.
bug - 4119349
Change-Id: Ic93b81ddafb58e9e72a2e9e02ca3d9f173d6dca7
In PackageManagerService, intent with ACTION_PACKAGE_FIRST_LAUNCH was
being sent to wrong package. It was being sent to the installed
package with installer package in the URI, whereas it should be sent
to installer package with installed package in the URI.
Comment in Intent.java:1417 seems to support that intent with this
action should be sent to the installer package, not installed.
Bug: 3426299
Change-Id: Iadec4ae7a1af6bab434716f8fcdb7d0b099d1ee1
Bug: 3473532
Reverting: Ie3f5b484b5574e10a4
Depends on Bug: 3511230
This must be fixed before submitting this CL.
Change-Id: I435a294a818bec5675f0ada00d81c1b3e37d1dce
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>
If a USB accessory is attached and we have no application that supports it,
display a dialog offering the user the option to visit the accessory's website
if the accessory has a URI.
Bug: 4073248
Change-Id: I30e2a802493fb6e203532a7f79402379c40bc3b8
Signed-off-by: Mike Lockwood <lockwood@android.com>
This is a first step toward adding USB accessory URI support
BUG: 4073248
Modified USB accessory matching logic to look only at manufacturer, model and version
(description and URI are not considered when matching apps to accessories)
Also added test for USB accessory protocol version to accessorytest
BUG: 4080288
Change-Id: I992a3433c74efa7a7db37bf030f02c1f0c92f9e2
Signed-off-by: Mike Lockwood <lockwood@android.com>
* changes:
MTP: Convert date created and modified values from seconds to milliseconds
Update USB accessory compatibility library to support new requestPermission API
UsbService: Don't require permissions for UsbManager.getCurrentAccessory()
Permission check should only happen in openAccessory()
Otherwise an application will not be able to check for the current accessory
and ask for permissions (if it is a suitable match for the application)
BUG: 4069037
Change-Id: If5b44ebda2e8077598d96629163cc74aa336589e
Signed-off-by: Mike Lockwood <lockwood@android.com>
If the user approves an application to access a USB device or accessory
without choosing it as the default application, then permission is granted
only until the device or accessory is disconnected.
Only applications chosen as the default choice have permissions assigned persistently.
BUG: 4061035
Change-Id: Ic4f6271a91b2fc56bbeef82c579e26d88c63ae56
Signed-off-by: Mike Lockwood <lockwood@android.com>
* changes:
Close USB dialogs if their corresponding accessory or device has disconnected
USB: Add API and dialog for apps to request permissions for USB devices and accessories
UsbService: Automatically use system apps by default if it is the only choice
Persist the setting of wifi override in airplane mode
so that it can be restored on reboot
Bug: 3250824
Change-Id: I2af38c282ba55fc150fd9ef783d43600f0d4260f
This fix ensures captured thumbnails in portrait mode have the
same resolution as those in landscape by fixing the horizontal
resolution and vertical resolution of the target image.
The returned image is now always the same size and matches
the landscape screen exactly. In portrait mode, it grabs
the upper portion of the screen based on the vertical dimension
of the target image.
Change-Id: I203c39843f2f21ca28f6ef0dffec308ce5cb39fb
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
If only one app is installed that supports a USB device or accessory
and that app is in the system partition, then use that activity by default
and rather than displaying the USB app chooser dialog.
BUG: 4060064
Change-Id: I49bf22a439e9676039b6f612c9bb622ab426066c
Signed-off-by: Mike Lockwood <lockwood@android.com>
This fixes a bug where we would capture the statusbar region in
thumbnails because the wallpaper was used in the bounds calculation.
Change-Id: I572221e83c4c363afe90e59bece9a291ce694a15
Like, um, it needs to be given the Activity since this is called before
the activity is attached.
And it was called after the entire fragment and its *view* was created
when being restored from saved state.
And the documentation was whacked.
Also fix the IME selector to dismiss when you tap outside of it.
Change-Id: Icbcafe7558965a570bdef9cda3441b1f0f7a317c
bug:3511123
Now the core settins are stored in the ActivityThread
instad in the AppBindData of the currently bound app.
Also the settings are pushed to the system process on
init.
Change-Id: I100bb7dc80d0d4548def22c328427bbef1694eb7
If a restore set lookup took a long time, the client's restore
session could be declared timed out even though the client was
not at fault. Handle this properly by resetting the timeout clock
when control of the session is returned to the client.
Bug 3477324
Change-Id: I43afaf1063e8e706ef16b70be77f9eeeea6a321f
