java.lang.SecurityException: Neither user 1209 nor current process
has android.permission.WAKE_LOCK.
Change-Id: I465972ab91b007e04b2ac62550f78583956a4048
bug:3505060
Since we want to have some settings that are used very frequently
by many applications (long-press timeout is one example) these should
be managed efficiently to reduce lookups from different processes
because in the case of a cache miss a disk I/O is performed. Now
the system manages such core settings and propagates them to the
application processes.
Change-Id: Ie793211baf8770f2181ac8ba9d7c2609dfaa32a7
The package manager now keeps track of whether an application is
stopped. There are new intent flags to control whether intent
filters in a stopped application will match the intent. This is
currently used in one place, sending broadcasts, so that stopped
apps can not be launched due to background processes.
The package manager during first init makes sure no applications
are in the stopped state. When new applications are installed,
that begin in the stopped state. When the activity manager is
launching a component of an application, it ensures the application
is taken out of the stopped state.
The "force stop" button in manage applications will now put an
application back in to the stopped state; it can't go back out
of the stopped state until one of its components is launched by
the activity manager.
There will probably be a few more places where we need to filter
stopped applications out of intent matches, but doing this for
broadcast is a very big first step.
This also introduces a new broadcast that is sent to an application
after it is replaced with a new .apk. But only if the app is not
in the stopped state. This makes it a lot easier for developers to
implement code to get their application back in proper running shape
after an upgrade.
Finally another new broadcast is added that is sent to a package's
installer at the first time it is launched. This allows the installer
to tell the package about it being installed only when it is first
actually used.
Change-Id: I589c53ff0e0ece868fe734ace4439c0d202dca2d
Thumbnails are now requested separately, so we don't exceed the
IPC buffer size limit.
Also implement issue #3349553: Please provide a hook to intercept
fragment-breadcrumb clicks
And maybe fix issue #3439199: Music Notification does not turn on
when app switching out of Music app
Change-Id: Ie939e78cc8ded07b18112760e053185947549f61
Or at least make it better. Now if we get a failure locking the surface,
we mark to do a full relayout pass later to try to get a new good surface.
Also fix some bugs in how activity manager was classifying processes for
their OOM adjustment to make better choices in what to kill.
Change-Id: I8e4aa86744211ba7693f9828291d8bbf2698274f
The owner isn't kept track it URI's writeOwners when
grantUriPermissionUncheckedLocked is invoked to provide both
read and write access to the URI. Fix is to check for both
read and write permissions and add owner to appropriate lists.
Change-Id: Id23688b96aefeb0a4911ee52ad47124bc5904fa0
This is a band-aid over the existing kludgy stopping mechanism
where the semantics of stop are different in the activity manager
than in the clients.
This change is intended to be as unobtrusive as possible, only
impacting the sleep case. I have a different change that
completely reworks how we stop activities to simply this all
a lot by unifying the semantics between the server and client.
However, it is too late in HC for such an extensive change. Later
I'll revert this one and put in the better solution.
Change-Id: Id77f2db1ec83469cdd888acb8fbc4679daa7766e
We no longer enforce permissions for applications that are accessing
their own components. This allows an application to require a permission
on one of its components that it does not itself have. This is useful
for example with the new advanced widgets, which require a system-only
permission on the implementing service to ensure the app's data stays
private but it is nice to allow the application to still touch its own
widget service.
Change-Id: I5d61930a083816919545870039ad191314ed48c6
Fixed a race condition during startup. We need to wait for the input
devices to actually be ready before trying to detect safe mode.
Fixed a problem during safe mode activation where we would try to add
the overlay window but the display was not initialized. Now we do it
after the system is ready.
Bug: 3134825
Change-Id: I4c043c142ae6bf0d865c79d266d36154eaf00709
...when the device's physical orientation is portrait.
We now hold off on computing app token orientation while preparing
to open or close app tokens.
Also clean up a few other little issues.
Change-Id: Iae125a975c7706fb4d068c872fd172e69854ff15
...to throttle contentobserver-based requeries
Why yes, I guess it could.
This also reworks AsyncTaskLoader to not generate multiple
concurrent tasks if it is getting change notifications before
the last background task is complete.
And removes some of the old APIs that had been deprecated but
need to be gone for final release.
And fixes a few little problems with applying the wrong theme
in system code.
Change-Id: Ic7a665b666d0fb9d348e5f23595532191065884f
Cyclic references can occur between a Service object held by an
application and a ServiceRecord object held by the system server.
A part of the problem is that binders are leaked and since many binders
are implemented by inner classes of services these services are also leaked.
This causes low memory problems. The solution is: When a Service is beeing
destroyed, go through the ServiceRecord's all IntentBindRecord and set its
binder references to null. This allows the binder and the service object to
be garbage collected.
Change-Id: I5a257521964851f34c08ffb3908feaad96b1bafe
When using sendOrderedBroadcast(..) with a BroadcastReceiver the
BroadcastReceiver instance was not released. The reason for this was that
the resultTo field in the BroadcastRecord kept a reference until it was pushed
out of the mBroadcastHistory. This reference in turn kept a reference to the
process side IIntentReceiver (implemented in ReceiverDispatcher$InnerReceiver).
This in turn had a strong reference (through mStrongRef) to the Context.
In order to keep the debug output the resultTo is also kept as a String in the
new resultToString variable.
Change-Id: I4382a22a541c27b3694fb2b78a04ee820b235f8f
Cyclic references can occur between a Service object held by an
application and a ServiceRecord object held by the system server.
A part of the problem is that binders are leaked and since many binders
are implemented by inner classes of services these services are also leaked.
This causes low memory problems. The solution is: When a Service is beeing
destroyed, go through the ServiceRecord's all IntentBindRecord and set its
binder references to null. This allows the binder and the service object to
be garbage collected.
Change-Id: I5a257521964851f34c08ffb3908feaad96b1bafe
When using sendOrderedBroadcast(..) with a BroadcastReceiver the
BroadcastReceiver instance was not released. The reason for this was that
the resultTo field in the BroadcastRecord kept a reference until it was pushed
out of the mBroadcastHistory. This reference in turn kept a reference to the
process side IIntentReceiver (implemented in ReceiverDispatcher$InnerReceiver).
This in turn had a strong reference (through mStrongRef) to the Context.
In order to keep the debug output the resultTo is also kept as a String in the
new resultToString variable.
Change-Id: I4382a22a541c27b3694fb2b78a04ee820b235f8f
Special cases persistent processes to not allow their services to be
force stopped if the processes is crashing multiple times. Avoid the
annoying issue with the system bar going away if it is sometimes crashing.
Change-Id: Icf421f45e389827d612d70638030da755a8d3344
ServiceRecord's bindings is a hashmap to keep track of all active
bindings to the service. This is not cleared when the service is
brought down by activity manager. This adds up the references to
IntentBindRecords and its references to ServiceRecord. Fix is to
clear the bindings.
ServiceRecord's restarter is a reference to the service and is not
cleared when the service is brought down by activity manager. This
adds up the references to ServiceRecord. Fix is to set the reference
to null when the service is brought down by activity manager.
Change-Id: Ica448cd5f60192c8adb23209b5d0e2cf0c04e446
ServiceRecord's bindings is a hashmap to keep track of all active
bindings to the service. This is not cleared when the service is
brought down by activity manager. This adds up the references to
IntentBindRecords and its references to ServiceRecord. Fix is to
clear the bindings.
ServiceRecord's restarter is a reference to the service and is not
cleared when the service is brought down by activity manager. This
adds up the references to ServiceRecord. Fix is to set the reference
to null when the service is brought down by activity manager.
Change-Id: Ica448cd5f60192c8adb23209b5d0e2cf0c04e446
