Earlier patch reversed a few lines of code that allowed deselection of
the currently selected item in CHOICE_MODE_SINGLE. Put it back the way
it was.
Bug 7289436
Change-Id: Ia1c5f3238d2faa3dd79e474851333fda90978d3c
Add a new call to the activity manager for the input dispatcher
to report about any pid having an ANR. This has a new feature
where it can also tell the activity manager that it is above the
system alert layer, so the activity manager can pop its ANR dialog
on top of everything if it needs to. (Normally we don't want
these dialogs appearing on top of the lock screen.)
Also fixed some debugging stuff here and there that was useful
as I was working on this -- windows now very clearly include
their uid, various system dialogs now have titles so you know
what they are in the window manager, etc.
Change-Id: Ib8f5d29a5572542cc506e6d338599ab64088ce4e
There is now only a single config value pointing
at a list of packages to get certs from. The old
system was a bit confusing.
The fused location provider also now builds
against SDK 17, and the meta data service version
tag was renamed from the overly generic "version"
to "serviceVersion".
Bug: 7242814
Change-Id: I00d27c9cbd5cc31a37bb4a98160435d15a72e19e
Bug: 7283782
Since ResolverActivity now runs in the correct user, it doesn't need to explicitly
pass in the calling userId. In fact, for the Home case, since ActivityManager is
the one requesting resolution of Home activity, Resolver is running as user 0
instead of the current user.
Removing explicit calls based on the launchingUid fixes the problem.
Change-Id: I4676c155aafaa0dd5cefb1acefa0e7e9c1e20f25
This particular layout didn't have layout_height specified, which
is undefined. However, the undefined behavior seems to have changed
on the platform to one where this layout no longer works. Not
specifying layout_height causes the security area view to be 0 pixels
wide, effectively ignoring layout_weight.
Fixes bug 7283261
Change-Id: I0e3d156e9b2d7ef1492dec9791f0e241e8cd7fe6
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
* commit '33c36895a294c7b731fd59017a7ea0f06ac2a356':
Fix bug #7282594 EditText does not allow to move the cursor when typing RTL text and if gravity is set to LEFT
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
