Merge commit '39792d2262352ae775091876d5488d2412a2ff92' into gingerbread-plus-aosp
* commit '39792d2262352ae775091876d5488d2412a2ff92':
Fix bugs with granting permissions through onNewIntent().
It would grant the permission to the temporary ActivityRecord,
not the real one, so it never got cleaned up.
Also allow granting of permissions to services because... well,
it would be really really useful. And it introduces some
refactoring that we'll need to support cut/paste.
Change-Id: If521f509042e7baad7f5dc9bec84b6ba0d90ba09
Merge commit 'cf6d2a1de274e9a4156b12be811a180eb36412ab' into gingerbread-plus-aosp
* commit 'cf6d2a1de274e9a4156b12be811a180eb36412ab':
Fix issue #2845673: android:exported="false" is not obeyed
Merge commit '567722eee190f7cf88dc7ea95167db76d5514842' into gingerbread-plus-aosp
* commit '567722eee190f7cf88dc7ea95167db76d5514842':
Fix problems with determining when to kill apps for wake usage.
Merge commit 'a8d9291d7f93d1aa0d24d71d65c7de2894812177' into gingerbread-plus-aosp
* commit 'a8d9291d7f93d1aa0d24d71d65c7de2894812177':
Various battery info things:
- Now track wake locks in battery history.
- Now track sensors in battery history.
- Some filtering of sensory data.
- Fixes to some data that wasn't cleared when resetting battery stats.
- Print amount discharged since last charge.
And the big part -- keep track of wake locks held per process,
and kill processes that hold wake locks too much while they are in
the background. This includes information in the battery stats
about the process being killed, which will be available to the
developer if the app is reported.
Change-Id: I97202e94d00aafe0526ba2db74a03212e7539c54
Merge commit 'bd1c082cf90d07e3ccb017b72e59b5ccad81dd07' into gingerbread-plus-aosp
* commit 'bd1c082cf90d07e3ccb017b72e59b5ccad81dd07':
New system property "sys.boot_completed" set to 1 when boot completed.
The NotificationManager tries to crash the calling app, but
in the case of a service calling startForeground, the caller
is the ActivityManager, so system_server goes down.
NotificationManagerService#enqueueNotificationInternal is a
new internal-only method that accepts a UID/PID to use when
punishing bogus notifications (such as the one in
http://b/2869787).
Change-Id: I84a9854bae630bc90288cebb94f174809d5dac8c
I was seeing lots of stack traces of people hung for noticeable
amounts of time when switching between activities.
e.g. On of the common gmail stacks showing this pause was:
android.os.StrictMode$StrictModeDiskWriteViolation: policy=391 violation=1
at android.os.StrictMode$AndroidBlockGuardPolicy.startHandlingViolationException(StrictMode.java:272)
at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:243)
at dalvik.system.BlockGuard$WrappedFileSystem.open(BlockGuard.java:238)
at java.io.FileOutputStream.<init>(FileOutputStream.java:97)
at java.io.FileOutputStream.<init>(FileOutputStream.java:69)
at com.android.server.am.UsageStatsService.writeStatsFLOCK(UsageStatsService.java:424)
at com.android.server.am.UsageStatsService.writeStatsToFile(UsageStatsService.java:398)
at com.android.server.am.UsageStatsService.notePauseComponent(UsageStatsService.java:539)
at com.android.server.am.ActivityManagerService.updateUsageStats(ActivityManagerService.java:1856)
at com.android.server.am.ActivityStack.startPausingLocked(ActivityStack.java:667)
at com.android.server.am.ActivityStack.finishActivityLocked(ActivityStack.java:2925)
at com.android.server.am.ActivityStack.requestFinishActivityLocked(ActivityStack.java:2836)
at com.android.server.am.ActivityManagerService.finishActivity(ActivityManagerService.java:2276)
at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:237)
at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1415)
at android.os.Binder.execTransact(Binder.java:320)
at dalvik.system.NativeStart.run(Native Method)
at android.app.ActivityManagerProxy.finishActivity(ActivityManagerNative.java:1454)
at android.app.Activity.finish(Activity.java:3260)
at android.app.Activity.onBackPressed(Activity.java:1929)
at android.app.Activity.onKeyUp(Activity.java:1907)
at android.view.KeyEvent.dispatch(KeyEvent.java:1088)
at android.app.Activity.dispatchKeyEvent(Activity.java:2087)
at com.android.internal.policy.impl.PhoneWindow$DecorView.dispatchKeyEvent(PhoneWindow.java:1661)
at android.view.ViewRoot.deliverKeyEventToViewHierarchy(ViewRoot.java:2543)
at android.view.ViewRoot.handleFinishedEvent(ViewRoot.java:2516)
at android.view.ViewRoot.handleMessage(ViewRoot.java:1866)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:123)
at android.app.ActivityThread.main(ActivityThread.java:3609)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:521)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)
at dalvik.system.NativeStart.main(Native Method)
Change-Id: Id49157bc635017292eaefddc5e22d73f5f4ab05e
Merge commit 'd2165cfce7911dac66d1195ed9123e79b086d22b' into gingerbread-plus-aosp
* commit 'd2165cfce7911dac66d1195ed9123e79b086d22b':
StrictMode: time violations in Binder calls
Merge commit 'a4fd0078d138b433d2250a74833ee3cc6424143a' into gingerbread-plus-aosp
* commit 'a4fd0078d138b433d2250a74833ee3cc6424143a':
Clear preferred activities when home process crashes
If the "default" Home application has been replaced with
a third-party app that is repeatedly crashing at start-up,
there is no way for the user to clear the preferred activities
or uninstall the bad application. If we clear the package
preferred activities when the application crashes, the user
will be prompted with the ResolverActivity at the next boot
and can try using the app again or choose to use another
Home application.
Change-Id: I8ba8e95e6752916d50515d96c117d3084fa980fd
Merge commit 'b73045935cd8ec5d1a1c5e7a7ca800448b5789ea' into gingerbread-plus-aosp
* commit 'b73045935cd8ec5d1a1c5e7a7ca800448b5789ea':
Cap the size of StrictMode buffering we do before calling DropBox.
Merge commit '14bfa398a4e8697ce5822861a684b7d1245e4a85' into gingerbread-plus-aosp
* commit '14bfa398a4e8697ce5822861a684b7d1245e4a85':
Infrastructure to report running services to developer.
The guard is compiled out by default because it adds overhead to
android.os.Process.setPriority().
Change-Id: Ibb2a648c6349b381abb7ae62a358888b04fba871
This was originally written as an in-case-we-need-it facility, but was
never actually used in production. It also soaked up a surprising amount
of cpu on occasion, as well as doing sketchy things like demoting the
system_server's primary looper thread to the background cgroup at times.
Change-Id: I9a81a8d1e9caea9e0a1277d97785fe96add438d7
Introdude a new ActivityStack class that holds all of the
state and management of a stack of activities. Paves the way
for having multiple activity stacks, though at this point
there should be no change in functionality and the activity
manager is still assuming there is only one stack.
Change-Id: Iea4859a24c9269061043755ec58a615028d4183b
Implement notification manager handling of bad notifications, to
call a new activity manager to have the owner's process crashed
(if there is one).
Change-Id: Ib15e8d0c598756f3b39c99cc2045c18e054daf6b
- Move PackageInfo out of ActivityThread, renaming to LoadedApk.
- Rename some of the other PacakgeInfo inner classes to better
represent what they are.
- Rename HistoryRecord to ActivityRecord.
- Introduce AppGlobals, to eventually let ActivityThread become
package scoped.
Change-Id: Ib714c54ceb3cdbb525dce3db9505f31042e88cf0
An Activity can declare itself to be "immersive" either by
setting android:immersive="true" in AndroidManifest or by
calling setImmersive(true).
Immersive activities "should" not be interrupted, for
example by Notifications with an associated
fullScreenIntent. (In the future we may even prevent any
non-system application from successfully calling
startActivity() if the foreground activity is immersive.)
Notifications with FLAG_HIGH_PRIORITY set will be shown to
the user in some less-obtrusive way if the frontmost
activity is immersive.
Change-Id: I8d0c25cc4e22371c27cbf2bb6372d2c95d57b2d7
We now clear the battery stats when unplugging after the
battery is full. This allows us to use the "total" stats as
a new "since last charged" stat. Total is gone. I never used
it, it was worthless. Since last charged is a lot more
interesting.
The battery history now collects a lot more stats, and keeps
control over how much it can collect. Printing is now more
descriptive.
The kinds of stats have been renamed to SINCE_UNPLUGGED and
SINCE_DISCHARGED. The other two stats are still there, but
no longer printed; a future change will eliminate them
completely along with all of their state.
Change-Id: I4e9fcfcf8c30510092c76a8594f6021e9502fbc1
Modify OOM adj classes a bit, to take into account the new
heavy weight app type, and give "foreground services" their
own category to have a bettery chance to manager them when
things go wrong.
Also add some new code to battery stats to keep a history
of changes to the battery level.
Change-Id: I29f5ab6938777e1a7eafd7d8c38b5e564cc9f96a
This is a new public API for developers to opt-in to strict rules
about what they're allowed to do on certain threads. (this is the
public face of the @hide dalvik.system.BlockGuard, added recently...)
In practice this will be used for developers to opt-in to declaring
that they don't want to be allowed to do various operations (such as
disk I/O or network operations) on their main UI threads. (these
operations are often accidental, or even when they are fast come with
a good chance of being slow or very slow in some cases....)
Implementation wise, this is just a thread-local integer that has a
bitmask of the things that aren't allowed, and more bits for saying
what the violation penalty is. The penalties, of which multiple can
be chosen, include:
* logging
* dropbox uploading for analysis/reporting
* annoying dialog
* full-on crashing
These are all only very roughly implemented at this point, but all
parts now minimally work end-to-end now, so this is a good checkpoint
commit before this gets too large.
Future CLs will polish all the above 4 penalties, including
checksumming of stacktraces and minimizing penalties for duplicate
violations.
Change-Id: Icbe61a2e950119519e7364030b10c3c28d243abe
Merge commit 'ac24d23cd4a96f38b4e9cb0318a7c298794b9b6a' into kraken
* commit 'ac24d23cd4a96f38b4e9cb0318a7c298794b9b6a':
Don't bring up Launcher until after boot complete
The preboot upgrade handling was bringing up the acore process with a default
application object, then the normal "start the HOME app" code was bringing up
Launcher2 [hosted in acore] in anticipation of boot completion... but then it
saw that the host process was alive and continued with Launcher2's init.
Launcher2 depends on a custom application object, however, so it crashed
immediately.
This change ensures that the HOME app is not actually initted at that level
until after boot has completed, at which point its proper application class
can be instantiated.
Fixes bug #2732250
Change-Id: I1a15384e2c0d50e14300df0c0db236bd7b1a187c
Only one can be running at a time, their process can not be killed,
and a notification is posted while it is running.
Change-Id: I843015723947e0c934ae63a1aeee139327c0bc01
This gives us a snapshot of what the system process was doing after 30 seconds
of apparent inactivity as well as after 1 minute, to help distinguishing actual
deadlocks from too-slow progress, livelock, etc.
Change-Id: I19758861d1b25f298e88788e8f1c7ec7bf828823
They're designed to handle one time upgrade code, which may
take a significant amount of time. Third party code cannot
receive this broadcast so the timing should be able to be
kept under control.
Bug: 2713849
Change-Id: I3733b6530198bebd9b8c2ba6f9f27a7999336b8d
It looks like there was a subtle bug where Process.setOomAdj() could
return false just because the given process doesn't exist, even though
it is documented to only return false if OOM killing is not supported
at all. This would cause the activity manager to fall into its code
path of trying to clean up processes itself, which it does a much
poorer problem at. I am thinking we may be seeing this problem more
now that the activity manager is killing background processes itself
when there are too many of them.
In addition, this change cleans up and reduces some of the logging
around killing processes.
Finally, try to improve process LRU management a bit by taking
into account process dependencies. Any dependent processes are
pulled up in the LRU list with the processes that is actually
moving. Also, we bring a process up if someone accesses its content
provider.
Change-Id: I34ea161f839679345578ffe681e8d9c5d26ab948
