TalkBack is seeing crashes that I can only explain by our assumption
that window layer is unique in all cases. TalkBack reports that it
happens during animation, so I assume that the layer may repeat
transiently.
Reducing our dependence on this assumption by traversing the list of
windows sorted by layer without assuming that the list has the same
length as the list of unsorted windows.
Also documenting the undefined behavior of SparseArray when indexing
beyond its bounds. The undefined behavior itself is intentional for
performance reasons.
Bug: 28679528
Bug: 28815817
Change-Id: I0c9f90b0b458b4cde465f603ba204fe6691e5c2c
This method is a helper for internal use only.
+ Updated docs for QUOTA_OCCUPIED, QUOTA_TOTAL, and QUOTA_UNAVAILABLE.
Change-Id: Ib146926cd2bff50affe970a0123bcbec62ac3e70
Fixes:28842445
As pointed out here:
https://code.google.com/p/android/issues/detail?id=69834
registerApp() causes onClientRegistered() to happen before autoConnect
is set. This patch fixes that.
Bug: 28861330
Change-Id: Ie1174c0f224f5084178439420b383164d22d542c
Instead of in activity thread. That way, we can warm up (ie,
precompute cached values) this provider and AndroidBCWorkaroundProvider
(which are installed together) so that the computation doesn't
happen in the app. As a result, the time spent in the first call to
SSLSocketFactory.getDefault() decreases by ~5ms in angler userdebug.
Measured with an app calling SSLSocketFactory.getDefault in onCreate
and timed it with System.currentTimeMillis() .
Bug: 28545496
Change-Id: I73284eccdf6d51dbf55206335d759ccf795c5f41
If <uses-sdk> tag is below <application> in AndroidManifest.xml then,
when activity is parsed, targetSdkVersion param is not yet set correctly.
Because of that we're defaulting to RESIZE_MODE_FORCE_RESIZEABLE and the
param resizeableActivity will be ignored.
This CL checks if resizeableActivity was set explicitly when targetSdkVersion
is less than N (or not set).
Bug: 28020462
Change-Id: I099f6c00dd50547ddea873e47dbb447869d0be6f
We were requiring the time to show in order to show the chronomer
which didn't make any sense.
Change-Id: Ia6d00d0932d272a6c5e20e8b41e3acfb53b7987a
Fixes: 28848113
When the countdown was set to true and the chronometer was set to
count down it wasn't updating the time, which is now fixed.
Change-Id: I4887d9eb09193c5636070edee9ba1bd13b9a23b5
Fixes: 28829131
If present, the system property "ro.config.lock_wallpaper" provides a
filesystem path to a decodeable image file to use as the system's
out-of-the-box lock wallpaper imagery. In the absence of this
system property, or if the indicated file is absent or unreadable,
then the new framework resource
com.android.internal.R.drawable.default_lock_wallpaper is consulted to
locate a usable asset. This mechanism parallels the existing one for
the default system wallpaper.
By default there is no specific lock wallpaper asset; the resource is
defined to be @null in the standard config.xml file. A product that
wants to define such a factory-default lock-only wallpaper image
will provide the asset as part of its framework resource overlay.
Bug 27828056
Change-Id: Iebf3706222370d0a0a4baf88d71a59ead07a25c7
Preallocate storage lists and avoid TextUtils and its string
builder for a common code path.
Optimize list join helper to not have a check in the loop.
Bug: 28801010
Change-Id: Iafc582031f973d718252b34bcda6405a77425628
During the PiP animation, we have two basic requirements:
1. We need to scale windows to the pinned stack bounds.
2. We need to halt resize and movement notifications to the client.
As we end the animation, we need to disable these states at differing
times. First we need to deliver a final resize and movement notification
to the client for it's new position. However, Surfaces may not
immediately resize (in particular in the case of child windows,
it may be some time!), furthermore Surfaces may resize at different
times so we need to persist scaling on a Surface by Surface
basis after reenabling resize notifications.
Bug: 28559097
Change-Id: I6d52a3e213e08a34f4c0eea892b2a84cd4c20e18
- The home stack is still visible when a translucent activity (like
dialer) is on top, which caused us to use the logic path that just
tries to launch the next task. However, that path does not reload
the stack state (since the activity stack generally doesn’t change
while Recents is visible) so it was always launching the already top
activity. The new check ensures that we start the activity anew
as if it was coming from an occluding app.
Bug: 28767764
Change-Id: Iec0fdc0957e5070cec532c5de5cba3454c906a3b
Since LocaleList needs to depend on android.os.Parcelable, we cannot let
that class belong to "android.util" package, which causes layering
violation.
Bug: 28819696
Change-Id: Ia8de2ee9df3dd0a42b1fe84574439519b680fe18
Rename value of KEY_VVM_CELLULAR_DATA_REQUIRED_BOOL KEY_VVM_PREFETCH_BOOL
Change-Id: I13718333a8ddc38e8d2131b478562b76cf9aab64
Fixes:28819765
Fixes:28822093
