| 712886fd979f58b0de7cefc3bce885ad7f4493b6 |
|
28-Apr-2018 |
Makoto Onuki <omakoto@google.com> |
Log slow message delivery on Looper
Sample log:
04-27 15:30:17.306 1000 942 942 W Looper : Dispatch took 222ms on main, h=Handler (com.android.server.job.JobSchedulerService$JobHandler) {42042fc} cb=null msg=7 start=48162 end=48384
04-27 15:30:17.306 1000 942 942 W Looper : Delivery took 235ms on main, h=Handler (com.android.server.job.JobSchedulerService$JobHandler) {42042fc} cb=null msg=4 start=48149 end=48384
04-27 15:30:17.773 1000 942 942 W Looper : Dispatch took 445ms on main, h=Handler (android.app.ActivityThread$H) {5df4c77} cb=android.app.-$$Lambda$LoadedApk$ReceiverDispatcher$Args$_BumDX2UKsnxLVrE6UJsJZkotuA@badd538 msg=0 start=48406 end=48851
04-27 15:30:17.828 1000 942 942 W Looper : Drained
04-27 15:30:24.389 1000 942 942 W Looper : Dispatch took 718ms on main, h=Handler (android.hardware.soundtrigger.SoundTriggerModule$NativeEventHandlerDelegate$1) {d7e9947} cb=null msg=4 start=54749 end=55467
04-27 15:30:24.389 1000 942 942 W Looper : Delivery took 621ms on main, h=Handler (com.android.server.media.MediaSessionRecord$MessageHandler) {5851574} cb=null msg=7 start=54846 end=55467
04-27 15:30:24.499 1000 942 942 W Looper : Drained
Bug: 78590632
Test: Boot and check log
Test: setprop log.looper.1000.android.bg 1 and runtime-restart and check log
Change-Id: Ief1fc65b40b8a3d583879f55a76288e3dba6be7d
/frameworks/base/core/java/com/android/internal/os/BackgroundThread.java
|
| daf72b1bd190eb9df405347419c19a98b58bb89c |
|
01-Nov-2017 |
Michael Wright <michaelwr@google.com> |
Change shared looper tag from ACTIVITY_MANAGER to SYSTEM_SERVER
Most of these are shared, so enabling all ActivityManager logging just
to get looper traces seems wrong.
Test: build, trace with system_server tag, see looper info
Change-Id: I3741dbacab25f5c02f6f8d17f0c8377d8f842776
/frameworks/base/core/java/com/android/internal/os/BackgroundThread.java
|
| 74cd3de6f4889d54a3da930de5e7ad00b97f03e9 |
|
07-Apr-2016 |
Jeff Sharkey <jsharkey@android.com> |
Automatically trace messages on shared loopers.
There are a handful of looper threads in the system_process that
are shared by dozens of different internal services. To help track
down what these operations are, tag the processing of each message
with a string that tries describing where it originated from: the
class name of the Handler, and the message number or class name of the
Runnable.
Bug: 28046299
Change-Id: I409ec43fea8daaae4fd70df05d4fed929a7249ae
/frameworks/base/core/java/com/android/internal/os/BackgroundThread.java
|
| 8d044e8bc287c1a567d82aedbe30085b011544c3 |
|
01-May-2013 |
Dianne Hackborn <hackbod@google.com> |
Start combining threads in system process.
This introduces four generic thread that services can
use in the system process:
- Background: part of the framework for all processes, for
work that is purely background (no timing constraint).
- UI: for time-critical display of UI.
- Foreground: normal foreground work.
- IO: performing IO operations.
I went through and moved services into these threads in the
places I felt relatively comfortable about understanding what
they are doing. There are still a bunch more we need to look
at -- lots of networking stuff left, 3 or so different native
daemon connectors which I didn't know how much would block,
audio stuff, etc.
Also updated Watchdog to be aware of and check these new
threads, with a new API for other threads to also participate
in this checking.
Change-Id: Ie2f11061cebde5f018d7383b3a910fbbd11d5e11
/frameworks/base/core/java/com/android/internal/os/BackgroundThread.java
|