This is a fix for http://code.google.com/p/android/issues/detail?id=907. Note that
that issue was declined without comment, but the bug (while incredibly minor)
does exist. This can be seen on the facebook app, as well as many third party apps.
Change-Id: I8f1449c47228f5f757a5baf389656e51c817b150
This is a quick and dirty solution to re-assign permissions after booting
from a platform update. It is not great, because it means that an app
can have permissions that the user didn't get to see when they originally
installed it. Unfortunately it's not clear what else to do here, nor is
there time to do anything significant.
Change-Id: I82faba141b5883c87212afa7febecf9860a413e3
Bug #2549649
If the window had a different size than its content but the content had already
been measured with the appropriate size, the window would not be resized. This
happens in wrap_content windows (dialogs.) This change simply adds a new codition
to window resizing: if the window is wrap_content, not as big as it can be and
not as big as its content, it gets resized.
Change-Id: I1d82d03af5a15c9ad8dffa0511d5f6d522578285
Tethering should be disabled when
airplane mode is enabled. Additionally,
we should restore Wifi (if it was on
before tethering was enabled) when
airplane mode is disabled.
Bug: 2567099
Change-Id: Iba2031f5ecb207954fd155c47134b39ed0167fa0
Don't rely on the ActivityManager's reported status about killing the
storage user process since the process might have gone away in between.
Change-Id: Ia7fa43eb34553329e7ff611ab6b99375b5ae673a
When airplane mode is disabled, Mobile connection may be bring up
before connecting to a known wifi.
Change-Id: I92e395aefd141c8bc4b8b2e497a71e5fd131eec2
Also fix another crash I just saw in the package manager, when a
permission got left around from a previous install but as no
longer defined.
Change-Id: I33b87420f0c59e24b8b77fab8b0316461d99e048
This fixes a number of screens in Settings (see the bug for examples).
Though it seems like a scary change, it should be safe since
the added line doesn't affect layout unless it's used, in which
case the view is slightly taller.
Change-Id: I13d04efadee19b407febabfae7825aedf66e8744
The old updater ran in the system process, so only that UID can delete
its downloads. Do this on startup in case we've just upgraded from
something before froyo and need to clean up those packages.
b/2571619 - eclair -> froyo update package not deleted
Change-Id: I0a5e7834c3ecd2cc2f6fd73052b3a38e1294b5d5
There was a new behavior that starting "Select text" would allow you to
swipe from beginning to end and immediately copy that. This change
reverts to the previous behavior that "Select text" will start where
your cursor is currently and any tap will extend the selection from that
origin to the point of the tap.
Change-Id: Ib955cc8d62a652f518435953da2f54e810d9dfb0
This is probably the real fix for the original bug. The last line was probably not
well formed and resulted in an overrun in the native code.
Bug: 2564824
Change-Id: I8a9cc267f8045a61eff4b5d532258afa32a8b837
In setActive(), the WebViewCore instance may
have already been destroyed before the settings
object can be read.
Change-Id: I46b2a57b2d92fc7216b1c984f7044fea1fc2409e
http://b/2570700
The problem turns out to have been a deep weirdness in the way that keyguard
and incall interact. Incall gets relaunched when the keyboard is opened/closed,
which transiently exposes keyguard with its nosensor orientation demands, and
that plus the long keyguard-hide animation was leaving incall in a bad state
from which the window manager didn't try to recover.
We now disregard animating-towards-hidden windows [i.e. keyguard] when running
through the app tokens to determine what orientation should be, and do not do
configuration calculations at all while the display is frozen. There can still
be a transient state in which incall is drawn in landscape, but things proceed
from there to relaunch it back into the proper portrait orientation, and it
ends up in the right state in the end.
Change-Id: I0d74ee19064b6d7f65600976f1b5b16b7ec36f31
