Keep track of how many clients are requesting scans and scan
continuously until all of them are gone then explicitly terminate the
scan instead of letting it time out as before.
Suspend wifi display scans while connecting or connected to a remote
display. This is handled by both the display manager and media router
since neither has complete information about what is happening.
Much of this code will no longer be needed once wifi display support
is integrated directly into the media router service.
Ensure that we don't attempt to scan or connect to wifi displays
while the wifi display feature is off.
Infer when a connection attempt fails and unselect the wifi display
route automatically so it doesn't appear to be connecting forever.
Fix issues around correctly canceling and retrying connection attempts.
Often we would cancel but not retry.
Improved connection reliability somewhat. It seems that discovery must
already be in progress in order for a connection attempt to succeed.
Ensure QuickSettings uses exactly the same logic as the MediaRouteButton
to determine when the remote display tile should be made visible.
Bug: 11717053
Change-Id: I18afc977b0e8c26204b8c96adaa79f05225f7b6e
Whoops persistent processes are, well, persistent. Don't remove
services from them. We'll be keeping that process record around.
Change-Id: I29e9fb6f704efdf0caad5e0307a7adbb416eed3b
The init & clear operations are particularly important to ensure
delivery when at all possible, so we retry those periodically
if the transport is unavailable when we first attempt them.
Now with 100% less build break.
Bug 11716868
Change-Id: I2af4e93788068cfac97c0a48d3568c561eefa23d
Activities that handle their own configuration get layout when hidden
and the configuration changes but not when the content insets change
if they are hidden. They need to get a fresh layout for both
situations.
Fixes bug 11544694.
Change-Id: Iff3a9adb72ea7dfc3e5cd38e1b9cd7cf2006f8f5
The init & clear operations are particularly important to ensure
delivery when at all possible, so we retry those periodically
if the transport is unavailable when we first attempt them.
Bug 11716868
Change-Id: I4860fe3d4e99618b2cd194c83162bd7cbd5a83a9
BatteryStatsImpl can reset its collected data, including
removing a BatteryStatsImpl$Uid$Proc object. If a ProcessRecord
has a direct reference, then the battery stats for a process
will be recorded in an old Proc object and prevent GC, causing
a memory leak.
bug:11087238
Change-Id: I19a9cd9d8361c10446a8ebdd5c0860b56c442209
There is still a flash of black when going to a non-wallpaper activity
from keyguard. This is not a regression from jb-mr2 and any fixes to
clean it up are too risky at this late date.
Fixes (partially) bug 11570753.
Change-Id: I17aaae4ab8be570f7e28276a7b8ac4b8685e7551
Only allow the system ui and settings to connect to a remote display.
To do this, we essentially hide the remote displays from applications
by using the ROUTE_TYPE_REMOTE_DISPLAY then add permission checks
around the operations that connect to them.
As a bonus, this may actually save power on devices since applications
that use MediaRouter will not longer be performing discover on
remote display routes at all.
Bug: 11257292
Change-Id: I9ea8c568df4df5a0f0cf3d0f11b39c87e2110795
It looks like we could add services to the restart list because
they end up left in the process's list of running services after
they have been removed from the main activity list, and we can
trip up on them there when the app is being force stopped.
Change-Id: I79805b67fcf5b593430dc5c856c97927e1a54a57
User removal or eviction inherently races with broadcast delivery. This
patch introduces a latest-possible recheck of the availbility of the
target application before attempting to send it a broadcast.
Once the process has actually been spun up the system is essentially
committed to presenting it as a running application, and there is no
later check of the availability of the app: the failure mode for
continuing to attempt delivery is a crash *in the app process*,
and is user-visible.
We now check the app+userid existence of the intended recipient
just prior to committing to launch its process for receipt, and
if it is no longer available we simply skip that receiver and
continue normally.
Bug 11652784
Bug 11272019
Bug 8263020
Change-Id: Ib19ba2af493250890db7371c1a9f853772db1af0
Bug:11559103
Added a new getCurrentSyncsCopy() that is public. The other version
is needed for internal SSE calls.
Change-Id: I0287f039a6f75abf04b65b85cb30f78353aeef4f
Adding validation for Global Proxy setting before it is
being set.
Proxy is validated at the boot time also to make sure
the value set is valid.
Signed-off-by: Raj Mamadgi <rmamadgi@sta.samsung.com>
bug:11598568
Change-Id: Idff5ae81119d8143da096b5291ecbfbc5875cbd4
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
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
