Sadly MediaProvider makes a ton of assumptions about storage paths
not changing. To ensure that it picks up radical storage changes,
kill it and let it restart to pick up new paths.
Also give ourselves a longer timeout when benchmarking.
Bug: 20275423
Change-Id: I9971c4667dabdc685cb23528443f085f152c461d
It ends up that MediaProvider is persisting MTP storage IDs in its
database, so we need to make sure we generate stable IDs over time,
otherwise we can end up looking into a black hole.
Bug: 22256092
Change-Id: I6a75c239aac1b71fd5f6df0df69b24971079a086
This mode splits processing quality based on stream resolution, to
enable ZSL operation where low-resolution (preview/recording) streams
require more processing since they are immediately user-visible, while
the high-resolution intermediate ZSL stream should have minimal/no
processing since it will be reprocessed into final quality when
necessary
Bug: 22266686
Change-Id: Ib41102b66b07d61a099f021f8c6251f28c62686f
App movement now has three distinct stages: copying, scanning, and
cleanup. Previously, a battery pull late in the move process would
end up with packages.xml pointing at the old location which had been
torn down. Now, we update packages.xml to point at the new location
as the "source of truth" before we start deleting the old location.
Bug: 21831336
Change-Id: I6f57f37a8cb335127db9ebb7c6b6cfe5755ada99
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 use
another thread to draw content. Thus, they have drawn their first
frame pretty fast, where the main thread might still be in the
activity lifecycle phases. Then, 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 already drawn.
Bug: 22207948
Change-Id: I708add3aab00575ae1707b25622b9b4614472892
Take into account the value of persist.sys.usb.config when updating
sys.usb.config. The persistent prop can hold information regarding
additional enumerations required for the device.
Bug: 21929369
Change-Id: Ic11ebf62ce114f2d0a097ad4405de71173b23139
AbsListView has special handling of header and footer views that avoids
full attachment; however, we still need to fully detach and reattach
non-header/footer views that cannot be recycled.
Bug: 22239425
Bug: 22238597
Bug: 22214485
Change-Id: Iae5f954fc76522c0a52d0c25e19985ae0196efa2
Per communication from Ben, READ_EXTERNAL_STORAGE was incorrectly
marked as a 'normal' permission in preview 1, and is properly
changed to 'dangerous' for preview 2. Updating the docs accordingly.
See first comment for doc stage location.
Change-Id: I0f824fb9689d2e7323e505b0200fda23eaa71eed
bug:22234438
Updating the displaylist is invalid since this debug method isn't
called on the UI thread, and it defeats the purpose of seeing what
the hierarchy is currently rendering.
Change-Id: I10c5cc6dbae8d304559dfc6e863b0ede158d554f
Previous logic led to several edge cases which fixes sometimes broke
other edge cases. New logic uses the clip rect provided by the
transformation as-is and doesn't try to adjust it based on window
flags. Correct clip rect is set in
WindowManagerService#applyAnimationLock using the content insets
before the animation is loaded.
Bug: 21727851
Bug: 20652683
Bug: 19523205
Bug: 15046646
https://code.google.com/p/android/issues/detail?id=161362
Change-Id: I2d4ed6196edb8ee8c401fe9a242aec70d3494574
This reverts commit d6b404c72da7e2475508c7d5948494b2e9b1a262.
This CL seems to have broken the build, causing GMSCore to continuously
crash.
Bug: 22313634
Bug: 22312938
Bug: 22314605
Bug: 22308392
Bug: 22307889
Call handleConfigurationChanged() at the end of
PhoneStatusBar#onConfigurationChanged to update statusbar configs.
BUG: 22215928
Change-Id: I7329d4949a8a47717ea037cf007ef0baa63507bd
This reverts commit 001d51496d062789355a91ce9365cd0cfeac6925.
Background: To just inherit AlertDialog, the content view should include
a title as we do in support library (AlertDialog uses NO_TITLE feature),
but up-streaming support library implementation to the framework at this
point might cause more issues. Verified that the narrow dialog issue
(b/22044600) does not happen in the framework implementation regardless of
whether it uses AlertDialog or not.
Bug: 22286869
Change-Id: Ic2554cc9e683beff29d1deee91945c1dace83ab1
In certain cases, the keyguard affordances could not be launched
due to a bug. This was because the targetedView was not properly
reset sometimes.
Bug: 22013726
Change-Id: I4525dc5adf07f4d023ef8553d3db0b16c8f754c4
