...content provider and updating its oom adj
This introduces the concept of an "unstable" reference on a content
provider. When holding such a reference (and no normal stable ref),
the content provider dying will not cause the client process to be
killed.
This is used in ContentResolver.query(), .openAssetFileDescriptor(),
and .openTypedAssetFileDescriptor() to first access the provider
with an unstable reference, and if at the point of calling into the
provider we find it is dead then acquiring a new stable reference
and doing the operation again. Thus if the provider process dies
at any point until we get the result back, our own process will not
be killed and we can safely retry the operation.
Arguably there is still the potential for a race -- if somehow the
provider is killed way late by the OOM killer after the query or
open has returned -- but this should now be *extremely* unlikely.
We also continue to have the issue with the other calls, but these
are much less critical, and the same model can't be used there (we
wouldn't want to execute two insert operations for example).
The implementation of this required some significant changes to the
underlying plumbing of content providers, now keeping track of the
two different reference counts, and managing them appropriately. To
facilitate this, the activity manager now has a formal connection
object for a client reference on a content provider, which hands to
the application when opening the provider.
These changes have allowed a lot of the code to be cleaned up and
subtle issues closed. For example, when a process is crashing, we
now have a much better idea of the state of content provider clients
(olding a stable ref, unstable ref, or waiting for it to launch), so
that we can correctly handle each of these.
The client side code is also a fair amount cleaner, though in the
future there is more than should be done. In particular, the two
ProviderClientRecord and ProviderRefCount classes should be combined
into one, part of which is exposed to the ContentResolver internal
API as a reference on a content provider with methods for updating
reference counts and such. Some day we'll do that.
Change-Id: I87b10d1b67573ab899e09ca428f1b556fd669c8c
When we are in the middle of an app transition and need to change to a
new one we were not ending the old one in a clean state. Also,
wallpapers were defaulting to the wrong animation in certain
situations.
Remove ':' style iterators.
Fixes bug 6486708.
Change-Id: Ied17e8410486020295db380ff68df5dad08bc5cc
ActivityStack sets the mNextAppTransition value before moving the apps
to their proper position. This makes the test for mNextAppTransition
being TRANSITION_UNSET incorrect. Better to just look for animating.
Fixes bug 6565418.
Change-Id: I4651b7d3678e46fc712a8e901992fb01b94c415e
Use config_netowrkLocationProviderPackageName and
config_geocodeProviderPackageName as intial packages. If another
package exists (or is later installed) that also implements a
provider, and has the same signatures as the original providers,
and has a hgiher version number, then use that instead.
The old code used a funky fix of package name substring checks
and service checks that was broken and not upgradeable.
Bug: 6499445
Change-Id: Ic58f09cf85d31d9abf47707093e22f31dda25cf0
Send a message to all windows to redraw before notifying
PhoneWindowManager of screen on. This minimizes the delay in
screen update that causes the keyguard clock to display the old time
before displaying the current time.
Fixes bug 6381021.
Change-Id: Ida7071e7dac2284540f101c5d004511b52133b91
Logging exec time on startUsingNetworkFeature as we've had some reports suggesting it's
causing ANRs.
Remove some logging from NDC so it's local log is more useful.
bug:6492166
Change-Id: I258ff6c59bff2c65935242d50496d84720c5d493
* commit '0100625bb316ecbd99873b72756ffba8613c3456':
Fix bug #6522190 MountService should respond to configuration changes ("INTERNAL STORAGE" string should be translated dynamically)
Stop trying to keep track of the AppTokens that have been moved
to the top and bottom and then try and match the WindowStates when
transitions are goodToGo. Instead rebuild the WindowState order based
on the AppToken order when we are goodToGo.
When moving AppWindowTokens lower in mAppTokens create a new ArrayList
of AppWindowTokens to keep track of the apps in Z order while
animating.
Fixes bug 6481078.
Change-Id: I29b33a507b45752f15feb10a9f4b47a3f5eb9f0e
Do not create a StartingWindow for apps that show wallpaper.
Fix handling of obscure case where found wallpaper is hidden.
Fixes bug 6484034.
Change-Id: I07181c4aea56fa9e530df0c95d886fe8ad61ec9d
- use an ID instead of a String for StorageVolume description
- use this ID for getting the correct localized version of the description string
Change-Id: I30f3080fce2c889be38bfdf9f5121dffcf8a99e8
1. If a UI test automation accessibility service is connected to the
system we pospone state updates in the AccessibilityManagerService
for the moment the UI automations service dies or is disconnected.
bug:6540522
Change-Id: I48ddf603b53d2158a00edcf8ad05cfe2575d4d75
1. We are passing the interrogating process id in the remote
accessibility requests to catch the query from the same
thread. While all other methods were doing this correctly
somehow the perform action is using the incorrect process id.
bug:6534935
Change-Id: Icef50833903c562758d51ef316b60c53c7a336c0
Previous auto brightness policy was to only ratchet screen brightness
up and never return to dim levels until the device was turned off. This
caused the screen to be very bright in dim areas and reduced battery
life. This change allows the screen to dim down over the course of
a minute to the desired brightness level.
Fixes bug 6422464.
Change-Id: I5592c06a495650c6496ec2fc9846d7a10fac4b16
We should tell the app that it is inactive, before unbinding.
Otherwise when it is told to unbind it will see that it is still
supposed to be active and immediately re-bind.
Also change the calls to set the active state to go through the
message dispatch path, to ensure ordering is correct.
Change-Id: I246241eac8f7521f42c4c1eee7f46097337e7303
By moving the StrictModeViolation display onto the WindowManager
Handler we avoid potential deadlocks as found in the bug below.
Fixes bug 6537798.
Change-Id: Ia46a43d1f7f6e55256f770b9e196602092669b49
