...if the process is killed and restarted
Try to ensure that in all cases we deliver an activity result if one
was requested.
Change-Id: Id43e830d2ee782f98ed1e3b68e5e16f3258d4ad8
My previous change to speed up the time the IME is dismissed was
fundamentally flawed. That change basically switched the order
the application called the input method manager service from doing
startInput() and then windowGainedFocus(), to first windowGainedFocus()
and then startInput().
The problem is that the service relies on startInput() being done
first, since this is the mechanism to set up the new input focus,
and windowGainedFocus() is just updating the IME visibility state
after that is done. However, by doing the startInput() first, that
means in the case where we are going to hide the IME we must first
wait for the IME to re-initialize editing on whatever input has
focus in the new window.
To address this, the change here tries to find a half-way point
between the two. We now do startInput() after windowGainedFocus()
only when this will result in the window being hidden.
It is not as easy as that, though, because these are calls on to
the system service from the application. So being able to do that
meant a fair amount of re-arranging of this part of the protocol
with the service. Now windowGainedFocus() is called with all of
the information also needed for startInput(), and takes care of
performing both operations. The client-side code is correspondingly
rearranged so that the guts of it where startInput() is called can
instead call the windowGainedFocus() entry if appropriate.
So... in theory this is safer than the previous change, since it
should not be impacting the behavior as much. In practice, however,
we are touching and re-arranging a lot more code, and "should" is
not a promise.
Change-Id: Icb58bef75ef4bf9979f3e2ba88cea20db2e2c3fb
Two things: (1) make sure the boot message is always positioned within
the entire unrestricted display, and (2) allow the dim background to go
on top of the nav bar when being used for the boot message (this latter
is really a hack that should be more generally fixed in the future).
Change-Id: I7261b044eb802a39cadff931b50a679ff18781d6
Backported from master, including a bug fix and a cdma enhancement.
Even if other people are sharing the connection (ie, carrier wants
default and tethered traffic on the same APN) stop using a carrier-
described APN when the tethering stops.
bug:5972599
Change-Id: I25e4831855e6b62c0c3ab3a6f4d4846aaee6ac50
This patch is adding a capability so that OEM can override USB mode
in case the device is boot up with OEM specific mode. (i.e. modem
debug, factory test etc.)
Bug:5964042
Change-Id: Ic8e23d302563ce71eedb74ce94cca8c65838a4f7
This is between the two previous attempts. I returned the part from the
original that was breaking gallery, but have some new code to detect when
something about the window params has changed that would require a
layout pass to make sure we still do a layout then, even if the window is
not currently visible.
Change-Id: I07745e1f66022583e3076b84cc8bbe8bd2acd48f
This fixes a complaint from carriers (that we used 8.8.8.8), but also
fixes the case where there is only room for one live radio
connection: the secondary connection (tethering) doesn't have a
default route to prevent on-device traffic from slipping out on the
tethering connection, but tethered dns is proxied through dnsmasq, so
it is appearing as on-device traffic and is unroutable. By switching
to the carrier-indicated dns servers we can use the host-routes
already set for those and kill two bugs with one fix.
bug:5898904
Change-Id: Ida8777687994f353b2d4f2c7db5d6ea4b6ac3882
This increases lock screen's thread priority from THREAD_PRIORITY_FOREGROUND
to THREAD_PRIORITY_DISPLAY to ensure it runs before other activities that
might stall lock screen when the screen turns on.
Change-Id: I14cf9f3f5c092817bc6cf2d0a254001a5d34f744
Don't consider a window as a candidate for the top fullscreen window
if it is not going to be a candiate for layout.
This fix does not include the change to ignore app tokens that are
hidden. This causes problems in some dialogs that stay hidden until
their app is ready to display, but need to perform a series of relayouts
during that time to get to the right size. Dropping this part of
the change still (mostly?) seems to allow us to avoid the bad states.
Change-Id: Ic052cb1499d3287f47e9ffeac5cd2470ee5a308c
This fixes a bug where the device fails to lock when DevicePolicyManagerService
requests the device to be locked and the screen was off because the user hit
the power button.
The change allows DPMS to directly invoke screen lock, bypasssing the screen state.
Change-Id: Iecdda6fc61e9c519119de495be23c69c3b983921
In particular, don't do O(asec_apps * installed_apps) work during the
broadcast receiver's operation. On devices with many installed apps
and a large number of them moved to ASECs, this was causing the system
process to become unresponsive and the watchdog to fire -- which in turn
would initiate a restart loop, as the same package-installed broadcast
would then be issued again once the package manager rescanned the ASEC
containers, ad infinitum. With this change, the expensive call to the
package manager is only made once rather than asec_apps times.
Bug 5850283
Change-Id: I14e280ea1fa6af19cebc58869a20fbb599c92c8c
This patch fixes the update of the extras Bundle in the Location object
each time the platform derives a new GPS location and passes it to
listening applications via LocationListener.onLocationChanged().
Sometime between Android 1.6 and 2.1 a bug was introduced that stopped
any extras calculated by the platform from being added into the Location
object, which means they were never passed up to any LocationListeners
for the GPS Provider. This manifested as an issue where the number of
satellites used to derive a fix always reported “0” when retrieved from
Location.getExtras() (Issue 4810 on the Android Issues page -
http://code.google.com/p/android/issues/detail?id=4810).
Sample code to be used within
LocationListener.onLocationChanged(Location location) which demonstrates
this problem:
Bundle extras = location.getExtras();
Int numSats = extras.getInt("satellites"); //This always reports “0”
//post 1.5, although in 1.5
//it properly reported the
//number of satellites used
//to derive this location
The “satellites” extra key/value pair for Locations is defined in
http://developer.android.com/reference/android/location/Location.html#getExtras()
This patch modifies GPSLocationProvider.java to properly update the
Location object with the extras Bundle before the Location object is
passed to any listening applications, and therefore the number of
satellites used to derive a fix can now be retrieved properly through
location.getExtras() (as shown in sample code above). Therefore, this
patch fixes Issue 4810.
Change-Id: Ief21056a3623269bb3149ec78ab92738a234f57f
Signed-off-by: Sean Barbeau <sjbarbeau@gmail.com>
Don't consider a window as a candidate for the top fullscreen window
if it is not going to be a candiate for layout.
Also don't consider windows a candidate for layout if their app token
is hidden. This fixes a transient state where we are preparing to
unhide the window but have not done so yet.
Change-Id: Ife5299ffa003c1df1a4f787b7a2809cbf614ec16
Fix 5783857: Device Policy Manager doesn't allow Face Unlock
This makes it so that if face unlock is enabled and then a device policy
manager that requires something more secure than face unlock is installed,
the user will be forced to choose a new acceptable lock type.
This was previously fixed for the case where the device had been reset, or
the shell was restarted after setting face unlock, but not for the case where the
device remained on between setting face unlock and setting up a device policy
manager.
Also changed the function ordering of saveLockPattern() so that the overloaded
wrapper function is next to the main function.
Change-Id: Ibed8c4ab137ebbc07fb143faef6f047bc6dc4474
- Add wimax related code in handleSetMobileData to disable wimax when Moblie data is disabled (Settings -> Wireless & Networks - More -> Mobile Networks ->Data Enabled)
Change-Id: Ibf2d9da2eb90d161128005f26ac4b3e991526af4
Signed-off-by: tk.mun <tk.mun@samsung.com>
-------------------------------------------------------
MCC detection fixes for CountryDetector
- Don't get and cache phone tpe at the initialization time. At this point
TelephonyManager is probably not ready yet.
- Refresh MCC whenever we get the service state changed callback, even when
the state hasn't actually changed, in order to make sure we get refresh
country properly when MCC changes.
- Also remove the initialization of mPhoneStateListener, which prevented us from
registering phone state listener properly.
- Also fix tests which were already failing.
Bug 5670680
-------------------------------------------------------
Add logging to country detector logic
This is for debugging purposes to verify the effects of
change Id45abeba1b1e843053ac2c946861b439ca568de4.
Bug: 5670680
Change-Id: I238d953484e2c8135f7dac70fce8662c8300a286
We need to work more like before in determining whether the menu
key is needed -- in some cases look back in the window list to
determine this if we don't know the value from the current window.
This requires adding a new private flag indicating whether the
compat menu state is known for a window, which is set by
PhoneWindow as part of its existing process of computing the flag
for its own windows.
Now we can have a new API on WindowState to determine the value
of this flag for a window, which if needed walks back in the window list
to find a window the value is known for (or stops at what the policy
has determined is the top full-screen window, so we stop like we used
to at things like the lock screen or the bottom of an application).
Change-Id: I829de6d629b5af8bcb422cb85249ee4041c7205e
... a different app opens
In some cases when reparenting activities we could end up with a reply
chain that crosses task boundaries, so if an activity below that needs
to be reparented we pull that and the activities above it up into the
new task.
Change-Id: Ia4fa041ab7069e39dac162ddbf5b8e1de98675b9
New API to let you build an Intent whose base configuration is correct,
but has an additional "selector" to pick out the specific app that you
would like launched.
Change-Id: Ide9db6dc60e2844b7696cfe09b28337fe7dd63db
