This just throws off alignment when the natural centering of this
layout will take care of things.
Bug 6369593
Change-Id: If0993091e0d47011f3bf5dd0b5a1fa649471f8e6
Bug #7275145
This change fixes ViewRoot and adds extra debug information. It does
not solve the problem entirely. Another CL will.
Change-Id: I7e604ba38aad7f421769783dcbd998d6905ab2d9
7267494 Calendar is not syncing
Check for whether a content provider is dead before returning
it. This is kind-of a band-aid, but probably the right thing
to do; I'm just not sure exactly the full details of why this
problem is happening. Hopefully this "fixes" it, though I don't
have a way to repro to tell.
7212347 System power off dialog is only visible to user 0
Make it visible. Also turn on some battery debugging stuff and
clean it up so we can just keep it.
Change-Id: I5add25bf2a763c8dfe1df23bc5c753a9ea5d157a
The reason for this is a bit subtle: we want to guarantee that
when a content observer is registered using the public API, it
is *always* bound to the host user's view of the data behind the
observed Uri, never the calling user's. Now, the reason it was
the calling user in the first place is that the Settings provider
(and potentially any singleton provider) needs the observers
underlying Cursors returned from query() to be tied to the caller's
user, not the provider's host user.
In order to accomplish that now that the public-facing behavior is
always tied to the host user, the concrete class that implements
the Cursor type handled by the Settings provider has been extended
with a new hidden API for setting a notification observer tied to
an arbitrary user; and then the provider explicitly downcasts the
query result's Cursor to that class in order to register the
notification observer. We can do this safely because this is platform
code; if we change the way that these underlying cursors are constructed,
we can just fix this point of call to follow along. If they get out
of sync in the future, the Settings provider will scream bloody
murder in the log and throw a crashing exception.
Bug 7231549
Change-Id: I0aaceebb8b4108c56f8b9964ca7f9e698ddd91c8
1. During a drag in touch exploration we have two pointers moving in the same
direction but inject only one of them. If the dragging pointer goes up we
send an up to the view system and wait for all pointers to go up to transition
to touch exploring state. At this point the dragging pointer id is cleared
and if a new pointer goes down we are trying to send up (rather do nothing)
for the dragging pointer which we already did and due to the invalid pointer
id we get an exception when splitting the motion event.
bug:7282053
Change-Id: I690bf8bdf6e2e5851ee46a322c4a1bb7d484b53a
1. If there is a non-speaking accessibility service installed and the
global gesture is performed an exception is thrown since an attempt
is made to modify the list with services returned by the accessibility
manager (to remove the non-speaking ones) but this list is immutable.
Now the returned services are put into a mutable list before removing
the non-speaking ones.
bug:7280996
Change-Id: I2852a3e169c1d34d942b50fb439e0961394c92bc
Ringer mode setting was moved from System to Global group
but a db upgrade cleanup step was missing.
Bug 7128886.
Change-Id: Id20994fe74575afa2b68154a620aa3c8807e8304
With the broadcom architecture, the p2p interface on a group
was dynamic that would just go away. Clearing addresses
was thus not important before.
It is good to clear up the addresses and reset connections
when the group is removed.
Bug: 7282358
Change-Id: Ia1a94fce90f86b54abcc2d1f78a33524ef8045fa
Bug 7150006
Single finger notification expansion.
If you liked these changes...
Change Ie4e79aa5
Change I8a6f8606
Change I824937e9
Change I957b6d50
You'll love this one!
Conflicts:
packages/SystemUI/res/values/config.xml
packages/SystemUI/res/values/dimens.xml
Fix notification gestures.
Broken by recent changes to ScaleGestureDetector, which we
were using incorrectly.
Conflicts:
packages/SystemUI/res/values/config.xml
packages/SystemUI/res/values/dimens.xml
Change-Id: Ie534c5b2d320296531a36a9b1c22f9dd6901e0b8
This fixes bug 6948776
android.graphics.cts.PaintFlagsDrawFilterTest#testPaintFlagsDrawFilter
failures on JO
When we moved the drawing of text decorations (underline, strikethrough)
from Skia to our own drawing (so we could take into account the metrics
computed by TextLayoutEngine), we just used the raw flags from the
paint, which ignored the overrides that a DrawFilter can effect.
The patch simply checks for the existence of a DrawFilter in the canvas,
and applies it to a copy of the paint where present. This will be one
extra paint copy where the filter exists, but that's expected to be rare
(other than running this CTS test, of course).
Change-Id: I664c478b73a3a1cc43599ee11bbc02c69b7a96c2
Previously dreams could not be started unless plugged in.
Now we allow them to start but they will eventually stop
if a user activity timeout occurs and no screen wakelocks
are held.
Bug: 7253639
Change-Id: I84703e144ca6d4aba1ef9437f04a201c3dde8a49
With this fix, when all users cancel installing an app they were warned about,
then the "Installing..." screen disappears, as desired.
Bug: 7255231
Change-Id: I2475fa790a5d09abbf94411c696682502fb1e8df
