Reduces jank in multiuser lock from QuickSettings. The launcher and
wallpaper were being hidden as soon as the surface for the keyguard
was created. Now they are not hidden until the keyguard has been
drawn. This still leaves a short time where there is a black screen
but it is considerably shorter than it was. Comparable to jb now.
Fixes bug 11046339.
Change-Id: I349d95dba72da27e5c05a7a64c95a2774d17a34e
Extend wifi display connection timeout.
Show a notification while connecting to wifi display.
Ensure that remote display providers are really trusted before
connecting to them.
Bug: 11257292
Change-Id: Iad0caaa30d7946df818bc75ade071f2e377f8a53
Could occur when requestRouteToHostAddress is called on a network
with no associated tracker. Code later in the method handles
this case gracefully but code introduced in JB throws an exception.
Change-Id: I6c8a0e313ecbcca120aeb5dd0802a72114749aa1
Both requests are made using same id; and there is a chance that
stopResolve() is not fully completed when getAddrInfo() is issued. That
results getAddrInfo() failure, because both are using same requestId.
This change fixes this problem by creating a new unique id to call
getAddrInfo() with.
Bug: 11597153
Change-Id: I56bd78740e8a40bd31c52705dc797486aff53a50
If a window claims to handle its own configuration change then we
won't destroy and recreate its window on a configuration change.
Normally that recreation triggers the first layout following
orientation change because mHaveFrame is false. Windows that handle
their own configuration changes never got a relayout pass following a
change in orientation.
This change passes the configuration changes that an application
handles into the AppWindowToken. If the app says it handles
orientation or screen size changes then a relayout will occur when the
configuration has changed.
Fixes bug 11647107.
Change-Id: Ie8d49fd050442ebbdcf0b805087894e3a2fc4be9
Also use the existing full PreferredActivity match machinery instead
of the existing direct comparison now that the intent filters can
be more flexible.
Bug 11482259
Change-Id: Icb649ca60ecfbdb9ee3c256ee512d3f3f989e05f
Hide disabled routes from the chooser.
Fix layout of chooser dialog when the settings button is visible and
the list is very long to prevent truncation of the settings button.
Fix an issue when we fake the route connecting status when a route
is selected. The route changed notification needs to be propagated
to apps. Fake it better.
Immediately disconnect from a route when the connection is lost or
a connection attempt fails. Added a few new test displays for this
case.
Bug: 11257292
Change-Id: I360ab5dc937ad60d97592eab54b19f034519645e
Tighten up some flows to try to avoid any chance of leaving
a restarting service on the list, add a log to the only remaining
place I could find that we could get in to trouble for some
reason.
Change-Id: Iffb9be9d97deefc6cf0c5790eedfeb6e4e8a36bc
Current AccountManager code for getAuthToken checks if the account
in the request exists. If the account does not exist then it throws
an exception which leads to a runtime exception being thrown by
AccountManager in the client. In perticular, Checkin client code
hits this issue when accounts are deleted by user. As the exception
is thrown from the getAuthToken method call and is a RuntimeException
it is not caught by the client. Futhermore, Checkin runs in one of the
important processes and this exception makes the process crash.
This cl, does the following:
1) Delegates the account exists check to Authentictor which in turn
would cause an AuthenticatorException which is a checked exception.
2) Replaces some of the runtime exceptions thrown by AccountManagerService
with calling AccountManagerResponse.onError() which causes more graceful
failure on the client.
3) Correctly passes on the error returned by Authenticator to
AccountManager. Earlier if Authenticator returned an error code to
the AccountManager, it ignored the error and returned null token to the
client which was incorrect.
Bug: 10856295
Change-Id: Ie250fec601d46f6dfecd74677b478bfd4e9dcfad
When a device admin goes away due to a package change, only one of two lists
was being updated, causing an inconsistency in the query for active admins
depending on which API was being called.
This makes sure that mAdminMap stays in sync with mAdminList so that
isActiveAdmin() and getActiveAdmins() returns the same results.
Bug: 11588094
Change-Id: I232608738249492d9fca7e4d7aa7566d96fccf46
This happened:
android.util.Log$TerribleFailure: Adding dependent process ProcessRecord{43c7a120 0:com.google.android.gms/u0a7} not on LRU list: service connection ConnectionRecord{437c16e0 u0 CR ACT com.google.android.gms/.icing.impl.IndexService:@436ba7f8} from ProcessRecord{43c64208 4908:com.google.android.googlequicksearchbox:search/u0a19}
at android.util.Log.wtf(Log.java:290)
at android.util.Slog.wtf(Slog.java:82)
at com.android.server.am.ActivityManagerService.updateLruProcessInternalLocked(ActivityManagerService.java:2290)
at com.android.server.am.ActivityManagerService.updateLruProcessLocked(ActivityManagerService.java:2508)
at com.android.server.am.ActiveServices.updateServiceClientActivitiesLocked(ActiveServices.java:636)
at com.android.server.am.ActiveServices.removeConnectionLocked(ActiveServices.java:1656)
at com.android.server.am.ActiveServices.unbindServiceLocked(ActiveServices.java:860)
at com.android.server.am.ActivityManagerService.unbindService(ActivityManagerService.java:12773)
at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:869)
at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:2071)
at android.os.Binder.execTransact(Binder.java:404)
at dalvik.system.NativeStart.run(Native Method)
Because of this earlier:
11-09 18:02:19.126 W/ActivityManager( 809): Exception when starting service com.google.android.gms/.icing.impl.IndexService
11-09 18:02:19.126 W/ActivityManager( 809): android.os.DeadObjectException
11-09 18:02:19.126 W/ActivityManager( 809): at android.os.BinderProxy.transact(Native Method)
11-09 18:02:19.126 W/ActivityManager( 809): at android.app.ApplicationThreadProxy.scheduleCreateService(ApplicationThreadNative.java:850)
11-09 18:02:19.126 W/ActivityManager( 809): at com.android.server.am.ActiveServices.realStartServiceLocked(ActiveServices.java:1384)
11-09 18:02:19.126 W/ActivityManager( 809): at com.android.server.am.ActiveServices.bringUpServiceLocked(ActiveServices.java:1294)
11-09 18:02:19.126 W/ActivityManager( 809): at com.android.server.am.ActiveServices.bindServiceLocked(ActiveServices.java:755)
11-09 18:02:19.126 W/ActivityManager( 809): at com.android.server.am.ActivityManagerService.bindService(ActivityManagerService.java:12766)
11-09 18:02:19.126 W/ActivityManager( 809): at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:859)
11-09 18:02:19.126 W/ActivityManager( 809): at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:2071)
11-09 18:02:19.126 W/ActivityManager( 809): at android.os.Binder.execTransact(Binder.java:404)
11-09 18:02:19.126 W/ActivityManager( 809): at dalvik.system.NativeStart.run(Native Method)
Not clearing the service's app pointer.
Also fix this wtf where we were not clearing the started state of
a ServiceTracker when its process goes away. (This was like this
because we used to want to leave the started state so that we can
know the process is trying to restart. But now that have a new
explicit restarting strate, there is no need to leave it.)
android.util.Log$TerribleFailure: Service owner ServiceRecord{436f5168 u0 com.dirtywaterlabs.uberhype/com.dirtywaterlabs.musichype.MDService} cleared while started: pkg=com.dirtywaterlabs.uberhype service=com.dirtywaterlabs.musichype.MDService proc=ProcessState{42bf4bb8 com.dirtywaterlabs.uberhype:remote/10115 pkg=com.dirtywaterlabs.uberhype}
at android.util.Log.wtf(Log.java:290)
at android.util.Slog.wtfStack(Slog.java:86)
at com.android.internal.app.ProcessStats$ServiceState.clearCurrentOwner(ProcessStats.java:2989)
at com.android.server.am.ActiveServices.serviceDoneExecutingLocked(ActiveServices.java:1821)
at com.android.server.am.ActiveServices.serviceProcessGoneLocked(ActiveServices.java:1779)
at com.android.server.am.ActiveServices.removeConnectionLocked(ActiveServices.java:1693)
at com.android.server.am.ActiveServices.killServicesLocked(ActiveServices.java:2028)
at com.android.server.am.ActivityManagerService.cleanUpApplicationRecordLocked(ActivityManagerService.java:12424)
at com.android.server.am.ActivityManagerService.handleAppDiedLocked(ActivityManagerService.java:3605)
at com.android.server.am.ActivityManagerService.appDiedLocked(ActivityManagerService.java:3750)
at com.android.server.am.ActivityManagerService$AppDeathRecipient.binderDied(ActivityManagerService.java:1026)
at android.os.BinderProxy.sendDeathNotice(Binder.java:493)
at dalvik.system.NativeStart.run(Native Method)
Change-Id: I25a3fb678b5365254490cd5509b558348655b589
Fixed the Preference ordering code to consider the case where
two preferences might have the same order. In that case, it
falls back on the title to disambiguate. Previous behavior was
undefined (and technically not stable).
Expose the wifi display device address.
Perform wifi display scans every 10 seconds instead of every 15
to improve reponsiveness.
Make sure to define routes for wifi displays that we are connecting
to even if they are not yet paired. Simplified the logic for
adding and removing these routes to avoid possibly getting out
of sync and leaving stale routes behind.
Fix wifi display notification icon.
Bug: 11257292
Change-Id: I8ac15fb17d83758c0bdce80399e12723c367b83c
