As discussed in b/21429947 (commit
674019065bceb4150190bfb1aa63cda9de0a8560), MTP must always be
enabled, even if access to the underlying MTP data is disabled.
Otherwise, Android will not enumerate on the USB bus, and won't
receive notifications from the kernel about USB state changes. This
effectively prevents using MTP functionality on user builds, or
on userdebug/eng builds with adb turned off.
Always ensure that MTP is the default driver mode.
Get rid of one use of the persistent property. The persistent property
was already pulled from a number of devices, and as explained in
commit fcf10f7c12cb3107bdfedce6f76a8c866d154f3c, the intent was that
the persistent property would only hold the persistent adb state.
Bug: 22447614
Bug: 21429947
Change-Id: I8b3690a1bafb7cea0d5a69d73c1065c7fc64c653
When waiting for all the windows that belong to an activity, we
skipped the main window, in case it didn't had a surface yet. This
was a problem because with SurfaceViews: They set it's visibility
extremely early in the app visibility change cycle. Then, they don't
block with the callback to SurfaceHolder.Callback2.surfaceRedrawNeeded,
so window manager thinks it has drawn the first frame already. We don't
even have a surface for the main window yet, but we start the app
transition already because we think the only interesting window for this
app token is the SurfaceView, which has supposedly already drawn.
Bug: 22207948
Change-Id: I2ddb274000fa08866e193f4fd8db3788fc55e0f1
This updates the Android platform SDK documentation to list which
algorithms are supported by Android Keystore on which Android
platforms.
The list is similar in design to the one in SSLSocket and SSLEngine.
Bug: 22661043
Change-Id: I08fcf65ca58ead644100b673dceb93c67f34f507
Long clicking on settings gear in QS causes it to accelarate and
spin, when released it will open and enable the tuner. On first
opening there will be a warning dialog.
Also add way to disable tuner from tuner screen. This way it can
be removed from its former home in Developer Settings. All tuner
settings are reset when disabled to match developer settings
behavior.
Bug: 22462605
Change-Id: Ie700a6a15e6c3caccf7cd1885da73328e6fac6ab
Surface more details and commands for storage volumes to support
CTS testing. Fix user reconciliation bug that skipped user setup on
empty volumes.
Bug: 22658804, 22633097
Change-Id: I4221312d1cce24d1f5a2c108095cf3cf471598ed
In the scenario that you connect more than one device to android phone
with an usb hub, when you attach the second device,mNewConfigurationis
is still corresponded to the first device unless another
mNewConfiguration is created by a new operation. However,before another
mNewConfiguration is created,setInterfaces() in addUsbConfiguration()
has already been executed. Problem is that mNewInterfaces has already
been cleared when it finished endUsbDeviceAdded for the first device. As
a result,the UsbInterface descriptor in the first device's Configuration
descriptor is set to null.
Bug: 22657587
Change-Id: I0ba4f07c809d07ebebed633e43c3ee8e2e4c5060
- attempt to restart fingerprintd on the next request
- inform clients that the hardware isn't available and cancel
listeners.
Fixes bug 22492148
Change-Id: Ib27eaf7f197c6a4e6ed9b085602882904d6b794d
We currently go through the list of existing activities to find
a match for the launching intent so we can re-use the activity
record if one already exist. However, we exit the search early
once we run across an activity record that doesn't belong to the
current foreground user. This will cause us to create duplicate
activity records if the launching intent is for a backround
user and an activity record already exist.
Based on https://android-review.googlesource.com/#/c/159131
Bug: 22564256
Change-Id: I4b6d94059c11fd2e621e65c8ec2c99427c15b246
...disabled after toggling them off
Keep track of whether a permission that has been declared by an app
was able to actually be installed in the system, along with an API
to find this information so that system UI can tell whether that
permission is of interest.
Also clean up some of the permission debug output.
Change-Id: If4541bedb857789b255bb18f03cad155dcda0b95
Previously we tried to read /d/wakeup_sources to gather kernel wakelock data. If that
fails we used the older sys file /proc/wakelocks.
N7 has both /proc/wakelocks and /d/wakeup_sources, but /proc/wakelocks
has the actual data we need. All other devices are using /d/wakeup_sources, so
only N7 experienced a loss of kernel wakelock data.
The original regression was introduced here: ag/659258
Bug:22556242
Change-Id: I51ec68e957f587bc1466e24f0a1dbc8cd7753ac6
