安卓系統的啓動流程與各種死法 系統啓動流程 系統奔潰重啓流程 系統開機之後死掉 系統開機死掉導致開不了機 總結

最近遇到了蠻多framework掛掉引發的問題,這裏做個總結分享.在看具體bug之前先簡單瞭解下安卓系統的啓動流程可以幫助我們定位和分析問題:

系統啓動流程

開機的流程圖如下:

大概的步驟爲:

  1. 啓動BootLoader: 開機引導可以初始化硬件設備、建立內存空間映射圖等,然後拉起LinuxKerne
  2. 啓動LinuxKernel: 設置緩存、加載驅動等,然後啓動init進程
  3. init進程根據init.rc進行初始化: init.rc可以看做一個腳本,可以在裏面修改文件權限、設置屬性、拉起進程等,zygote、servicemanager、surfaceflinger這些系統進程就是它拉起來的
  4. 啓動zygote: zygote啓動的時候會孵化system_server進程
  5. 啓動system_server: system_server會啓動PMS、WMS、AMS等系統服務
  6. 啓動AMS: AMS啓動的時候會去啓動一些ui相關的進程如SystemUi、Launcher等

系統奔潰重啓流程

再來分析下當system_server掛掉的時候的重啓流程:

  1. 由於java層的進程都是zygote fork出來的,它會監聽子進程退出的信號,然後判斷如果是system_server退出則kill掉自己
// https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/jni/com_android_internal_os_Zygote.cpp?q=com_android_internal_os_Zygote.cpp

// This signal handler is for zygote mode, since the zygote must reap its children

static jint com_android_internal_os_Zygote_nativeForkSystemServer(
        JNIEnv* env, jclass, uid_t uid, gid_t gid, jintArray gids,
        jint runtime_flags, jobjectArray rlimits, jlong permitted_capabilities,
        jlong effective_capabilities) {
  ...
  // 保存system_server的pid
  gSystemServerPid = pid;
  ...
}

static void SigChldHandler(int /*signal_number*/, siginfo_t* info, void* /*ucontext*/) {
    pid_t pid;
    ...
    while ((pid = waitpid(-1, &status, WNOHANG)) > 0) {
        ...
        // 如果system_server死掉了就把自己幹掉
        if (pid == gSystemServerPid) {
            async_safe_format_log(ANDROID_LOG_ERROR, LOG_TAG,
                                  "Exit zygote because system server (pid %d) has terminated", pid);
            kill(getpid(), SIGKILL);
        }
    }
    ...
}
  1. zygote死掉之後init進程會重新把它拉起來

因爲zygote的rc文件裏面配置了在zygote重啓的時候會重新啓動audioserver、cameraserver等進程,所以他們也會重啓

service zygote /system/bin/app_process64 -Xzygote /system/bin --zygote --start-system-server --socket-name=zygote
    class main
    priority -20
    user root
    group root readproc reserved_disk
    socket zygote stream 660 root system
    socket usap_pool_primary stream 660 root system
    onrestart exec_background - system system -- /system/bin/vdc volume abort_fuse
    onrestart write /sys/power/state on
    onrestart restart audioserver
    onrestart restart cameraserver
    onrestart restart media
    onrestart restart netd
    onrestart restart wificond
    task_profiles ProcessCapacityHigh MaxPerformance

然後zygote啓動的時候又會重新啓動system_server進程.接着就回到了正常開機的流程:PMS、WMS、AMS這些系統服務和SystemUi、Launcher被啓動

系統開機之後死掉

死法一: 看門狗幹掉

問題: 我們的某個應用打不開

直接原因: 從anr的trace定位到該應用啓動的時候會調用嵌入式組提供的某個so庫,調用裏面的某個方法卡死造成anr。

本來到這裏鍋應該就轉給底層去看了,但是底層說他也看不出具體原因,希望我們協助分析下.

一通搜索之後在發現anr裏面有系統的trace文件:

// 這裏是trace文件首行,意味着system_server出現卡死所以打印的堆棧
----- pid 4129 at 2021-11-04 19:08:03 -----
Cmd line: system_server
Build fingerprint: 'ViewSonic/IFP8650-5/IFP8650-5:11.0.0/20220907.130307/release-keys'
ABI: 'arm64'
Build type: optimized
Zygote loaded classes=21210 post zygote classes=3385
Dumping registered class loaders
#0 dalvik.system.PathClassLoader: [], parent #1
#1 java.lang.BootClassLoader: [], no parent

我還是第一次在anr目錄下見到system_server卡死的堆棧,真是漲見識了。

既然看到堆棧文件了證明system_server掛過然後自動重啓了,所以我們在日誌文件裏找下19:08:03附件的日誌看看,能看到system_server由於StorageManagerService阻塞被看門狗幹掉了:

...
11-04 19:08:10.436312  4129  4154 W Watchdog: *** WATCHDOG KILLING SYSTEM PROCESS: Blocked in monitor com.android.server.StorageManagerService on foreground thread (android.fg)
11-04 19:08:10.436985  4129  4154 W Watchdog: android.fg annotated stack trace:
11-04 19:08:10.437073  4129  4154 W Watchdog:     at android.os.MessageQueue.nativePollOnce(Native Method)
11-04 19:08:10.437120  4129  4154 W Watchdog:     at android.os.MessageQueue.next(MessageQueue.java:335)
11-04 19:08:10.437161  4129  4154 W Watchdog:     at android.os.Looper.loop(Looper.java:183)
11-04 19:08:10.437202  4129  4154 W Watchdog:     at android.os.HandlerThread.run(HandlerThread.java:67)
11-04 19:08:10.437244  4129  4154 W Watchdog:     at com.android.server.ServiceThread.run(ServiceThread.java:44)
11-04 19:08:10.437272  4129  4154 W Watchdog: *** GOODBYE!
--------- switch to main
11-04 19:08:10.437306  4129  4154 I Process : Sending signal. PID: 4129 SIG: 9
...
11-04 19:08:11.591232  3900  3900 E Zygote  : Exit zygote because system server (pid 4129) has terminated

然後它會自動重啓:

然後framework重啓:
11-04 19:08:11.990854 10300 10300 D AndroidRuntime: >>>>>> START com.android.internal.os.ZygoteInit uid 0 <<<<<<

那系統重啓了爲什麼會導致so方法卡死呢?

從系統哥那瞭解到so內部實際是和某個由init.rc啓動的服務進程做通訊,該進程需要調用system_server的某些方法。

system_server crash重啓,並不會引發這個服務進程重啓,也不會通知到這個服務,所以這個服務保存着之前掛掉的system_server的通訊鏈路,通訊失敗然後就出現問題了。

死法二: 出現未捕獲異常被幹掉

過了幾天在另外一個方案上又出現了同樣卡死的問題,容易聯想到應該也是system_server掛掉了。正常情況下system_server進程號是在1000以內的,用ps命令查看進程號發現它比較大,所以大概率的確是掛過了:

ps -A | grep system_server

其實我們可以直接通過"Exit zygote"關鍵字查找日誌,石錘它是否真的掛過:

> grep -rn "Exit zygote"
./logd/logcat.099:12670:09-19 06:19:39.800634   301   301 E Zygote  : Exit zygote because system server (pid 618) has terminated

從崩潰的時間點開始往上找618進程的日誌可以看到他是因爲創建IpClient失敗崩潰:

--------- switch to crash
09-19 06:19:38.510179   618   700 E AndroidRuntime: *** FATAL EXCEPTION IN SYSTEM PROCESS: WifiHandlerThread
09-19 06:19:38.510179   618   700 E AndroidRuntime: java.lang.IllegalStateException: Could not create IpClient
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at com.android.wifi.x.android.net.networkstack.NetworkStackClientBase.lambda$makeIpClient$1(NetworkStackClientBase.java:74)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at com.android.wifi.x.android.net.networkstack.-$$Lambda$NetworkStackClientBase$vgsHk-RCpPUAYmE-7YTwKKaAuFA.accept(Unknown Source:6)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at com.android.wifi.x.android.net.networkstack.NetworkStackClientBase.requestConnector(NetworkStackClientBase.java:119)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at com.android.wifi.x.android.net.networkstack.NetworkStackClientBase.makeIpClient(NetworkStackClientBase.java:70)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at com.android.wifi.x.android.net.ip.IpClientUtil.makeIpClient(IpClientUtil.java:80)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at com.android.server.wifi.FrameworkFacade.makeIpClient(FrameworkFacade.java:202)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at com.android.server.wifi.ClientModeImpl.setupClientMode(ClientModeImpl.java:3606)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at com.android.server.wifi.ClientModeImpl.access$3600(ClientModeImpl.java:164)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at com.android.server.wifi.ClientModeImpl$ConnectModeState.enter(ClientModeImpl.java:3790)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at com.android.wifi.x.com.android.internal.util.StateMachine$SmHandler.invokeEnterMethods(StateMachine.java:1037)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at com.android.wifi.x.com.android.internal.util.StateMachine$SmHandler.performTransitions(StateMachine.java:879)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at com.android.wifi.x.com.android.internal.util.StateMachine$SmHandler.handleMessage(StateMachine.java:819)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at android.os.Handler.dispatchMessage(Handler.java:106)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at android.os.Looper.loop(Looper.java:223)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at android.os.HandlerThread.run(HandlerThread.java:67)
09-19 06:19:38.510179   618   700 E AndroidRuntime: Caused by: android.os.DeadObjectException
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at android.os.BinderProxy.transactNative(Native Method)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at android.os.BinderProxy.transact(BinderProxy.java:550)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at com.android.wifi.x.android.net.INetworkStackConnector$Stub$Proxy.makeIpClient(INetworkStackConnector.java:226)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     at com.android.wifi.x.android.net.networkstack.NetworkStackClientBase.lambda$makeIpClient$1(NetworkStackClientBase.java:72)
09-19 06:19:38.510179   618   700 E AndroidRuntime:     ... 14 more
--------- switch to events
09-19 06:19:38.510843   618   700 I am_crash: [618,0,system_server,-1,android.os.DeadObjectException,Could not create IpClient,BinderProxy.java,-2]

死法三: 系統關鍵服務奔潰導致系統重啓

過了一個星期,又又出現了同樣的卡死問題。但是這次直接過濾"Exit zygote"關鍵字找不到信息, 但是看system_server進程號是4677,大概率還是掛過

system 4677 4416 6 02:47:25 ? 00:05:48 system_server

然後再搜索zygote啓動的關鍵字" START com.android.internal.os.ZygoteInit"發現的確系統在中間重啓過:

./logd/logcat.028:3181:09-29 02:47:22.978333 4416 4416 D AndroidRuntime: >>>>>> START com.android.internal.os.ZygoteInit uid 0 <<<<<<

去這個時間往上找可以看到一些native的堆棧錯誤:

--------- switch to crash
09-29 02:47:21.762310  4403  4403 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
09-29 02:47:21.762564  4403  4403 F DEBUG   : Build fingerprint: 'Droidlogic/t982_ar301/AVS-7500:11/RD2A.211001.002/eng.user5.20220811.094633:user/test-keys'
09-29 02:47:21.762637  4403  4403 F DEBUG   : Revision: '0'
09-29 02:47:21.762742  4403  4403 F DEBUG   : ABI: 'arm'
09-29 02:47:21.763405  4403  4403 F DEBUG   : Timestamp: 2022-09-29 02:47:21-0400
09-29 02:47:21.763549  4403  4403 F DEBUG   : pid: 343, tid: 3098, name: [email protected]  >>> /vendor/bin/hw/[email protected] <<<
09-29 02:47:21.763584  4403  4403 F DEBUG   : uid: 1000
09-29 02:47:21.763614  4403  4403 F DEBUG   : signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xf26ea000
09-29 02:47:21.763695  4403  4403 F DEBUG   : Cause: [GWP-ASan]: Buffer Overflow, 0 bytes right of a 24-byte allocation at 0xf26e9fe8
09-29 02:47:21.763743  4403  4403 F DEBUG   :     r0  f26e9fe8  r1  0000000c  r2  00000000  r3  00000000
09-29 02:47:21.763774  4403  4403 F DEBUG   :     r4  00000000  r5  0000001a  r6  e87d9088  r7  f0444160
09-29 02:47:21.763803  4403  4403 F DEBUG   :     r8  e87d9080  r9  e87d8ec8  r10 f26e9fe8  r11 f0e3f760
09-29 02:47:21.763836  4403  4403 F DEBUG   :     ip  f0e3db20  sp  e87d8ea0  lr  f0e18db3  pc  f1d9ceca
09-29 02:47:21.776427  4403  4403 F DEBUG   : backtrace:
09-29 02:47:21.776600  4403  4403 F DEBUG   :       #00 pc 00002eca  /vendor/lib/libamgralloc_ext.so (am_gralloc_get_width(native_handle const*)+8) (BuildId: e6b2c270ca2b92162da0e931af324ab6)
09-29 02:47:21.776802  4403  4403 F DEBUG   :       #01 pc 00058daf  /vendor/lib/hw/hwcomposer.amlogic.so (NnProcessor::asyncProcess(std::__1::shared_ptr<DrmFramebuffer>&, std::__1::shared_ptr<DrmFramebuffer>&, int&)+310) (BuildId: 0ed81d2b4576c8a8b13c166d0020f67a)
09-29 02:47:21.776907  4403  4403 F DEBUG   :       #02 pc 0004a82f  /vendor/lib/hw/hwcomposer.amlogic.so (MultiplanesWithDiComposition::runProcessor(MultiplanesWithDiComposition::DisplayPair&, int&, int&)+210) (BuildId: 0ed81d2b4576c8a8b13c166d0020f67a)
09-29 02:47:21.776977  4403  4403 F DEBUG   :       #03 pc 0004d9e1  /vendor/lib/hw/hwcomposer.amlogic.so (MultiplanesWithDiComposition::commit(bool)+976) (BuildId: 0ed81d2b4576c8a8b13c166d0020f67a)
09-29 02:47:21.777048  4403  4403 F DEBUG   :       #04 pc 0003d1bb  /vendor/lib/hw/hwcomposer.amlogic.so (Hwc2Display::presentVideo(int*)+58) (BuildId: 0ed81d2b4576c8a8b13c166d0020f67a)
09-29 02:47:21.777102  4403  4403 F DEBUG   :       #05 pc 0004370f  /vendor/lib/hw/hwcomposer.amlogic.so (VideoTunnelThread::handleGameMode()+154) (BuildId: 0ed81d2b4576c8a8b13c166d0020f67a)
09-29 02:47:21.777154  4403  4403 F DEBUG   :       #06 pc 00043375  /vendor/lib/hw/hwcomposer.amlogic.so (VideoTunnelThread::gameModeThreadMain(void*)+56) (BuildId: 0ed81d2b4576c8a8b13c166d0020f67a)
09-29 02:47:21.777213  4403  4403 F DEBUG   :       #07 pc 000808b3  /apex/com.android.runtime/lib/bionic/libc.so (__pthread_start(void*)+40) (BuildId: 7bc8508bdbcc8163b9a5fbf3443efa72)
09-29 02:47:21.777261  4403  4403 F DEBUG   :       #08 pc 00039d23  /apex/com.android.runtime/lib/bionic/libc.so (__start_thread+30) (BuildId: 7bc8508bdbcc8163b9a5fbf3443efa72)
09-29 02:47:21.777295  4403  4403 F DEBUG   : deallocated by thread 445:

這個堆棧我看們可以看出pid 343這個進程在libamgralloc_ext.so的am_gralloc_get_width方法裏面出現了野指針

然後往下翻一點可以看到一堆的系統服務died:

09-29 02:47:22.551747   394  3624 E csound  : [HIDLServer]:serviceDied, droid tvserver daemon a client died cookie:2
09-29 02:47:22.551817   394  3624 E csound  : tvserver daemon client:2 died
09-29 02:47:22.551865   394  3624 E csound  : handleServiceDeath, client size:5
09-29 02:47:22.551956   323   411 E SystemControl: systemcontrol daemon client died cookie:1
09-29 02:47:22.637123   493   621 W AudioSystem: AudioFlinger server died!
09-29 02:47:22.079547   393   393 E HwcComposer: executeCommands failed because of Status(EX_TRANSACTION_FAILED): 'DEAD_OBJECT: '
09-29 02:47:22.114335  1020  1358 W SurfaceComposerClient: ComposerService remote (surfaceflinger) died [0xf24d2c10]
09-29 02:47:22.450807   323   411 E SystemControl: systemcontrol daemon client died cookie:0
09-29 02:47:22.451031   394  3624 E csound  : [HIDLServer]:serviceDied, droid tvserver daemon a client died cookie:4
09-29 02:47:22.451104   394  3624 E csound  : tvserver daemon client:4 died
09-29 02:47:22.451150   394  3624 E csound  : handleServiceDeath, client size:5

而且上一個system_server(pid 777)最後的打印是爲343創建墓碑文件,接着Zygote就重啓了,所以大概率是這個系統服務的奔潰引發了整個系統的奔潰:

09-29 02:47:22.009985   777   996 W NativeCrashListener: Couldn't find ProcessRecord for pid 343
--------- switch to main
09-29 02:47:22.010605   291   291 E tombstoned: Tombstone written to: /data/tombstones/tombstone_08
--------- switch to system
09-29 02:47:22.017120   777   811 I BootReceiver: Copying /data/tombstones/tombstone_08 to DropBox (SYSTEM_TOMBSTONE)
09-29 02:47:22.018136   777   811 I DropBoxManagerService: add tag=SYSTEM_TOMBSTONE isTagEnabled=true flags=0x2
--------- switch to events
09-29 02:47:22.042284   777   811 I dropbox_file_copy: [/data/tombstones/tombstone_08,65536,SYSTEM_TOMBSTONE]
09-29 02:47:22.047667   777   811 I commit_sys_config_file: [log-files,5]
...
09-29 02:47:22.978333  4416  4416 D AndroidRuntime: >>>>>> START com.android.internal.os.ZygoteInit uid 0 <<<<<<

由於log裏面並沒有搜索到Zygote exit或者crash的信息,那麼有可能是日誌被沖掉了

還有可能是zygote被restart了,我們看這個進程的rc文件可以看他如果他重啓的話會重啓surfaceflinger:

service vendor.hwcomposer-2-4 /vendor/bin/hw/[email protected]
    class hal animation
    user system
    group graphics drmrpc
    capabilities SYS_NICE
    onrestart restart surfaceflinger
    ...

然後看surfaceflinger的rc文件發現它會重啓zygote:

service surfaceflinger /system/bin/surfaceflinger
    class core animation
    user system
    group graphics drmrpc readproc
    capabilities SYS_NICE
    onrestart restart zygote
    ...

所以死因就清晰了

  1. /vendor/bin/hw/[email protected]出現野指針crash重啓
  2. /vendor/bin/hw/[email protected]重啓的時候會重啓surfaceflinger
  3. surfaceflinger重啓的時候又會重啓zygote

爲了以後不再受這個卡死問題的困擾,讓系統哥在zygote的rc文件裏面配置zygote重啓的時候把那個異常的服務也同步重啓就可以了。

系統開機死掉導致開不了機

死法四: native奔潰導致卡logo

問題: 升級軟件之後開機卡logo開不了機

出現這個問題首先要分析日誌,但是串口直接logcat的話刷的太快不好排查所有些抓日誌的小技巧:

  1. 使用重定向把日誌導出到文件,例如/storage目錄下:

logcat > /storage/log.log

然後就能用busybox vi去編輯查看了

  1. 插入u盤將日誌文件導出到u盤(需要root)

由於開機沒有成功,u盤可能還沒有掛載上去,需要我們手動掛載。

首先需要用blkid命令列出所有文件系統,找到u盤(u盤名字就叫PTT)的設備節點爲/dev/sda1:

console:/storage # blkid
/dev/zram0: UUID="12a21a37-1a08-42e6-97e3-90cb1a1ba60a" TYPE="swap"
/dev/mmcblk0p16: TYPE="squashfs"
/dev/mmcblk0p18: TYPE="squashfs"
/dev/mmcblk0p20: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/mmcblk0p32: SEC_TYPE="msdos" UUID="5278-5278" TYPE="vfat"
/dev/mmcblk0p39: UUID="57f8f4bc-abf4-655f-bf67-946fc0f9f25b" TYPE="ext4"
/dev/block/mmcblk0p56: LABEL="/" UUID="5ac835d7-e53a-59f8-a2c4-b8a6967b849e" TYPE="ext4"
/dev/block/mmcblk0p58: LABEL="vendor" UUID="c7f6b4dc-c6f7-59d6-90cf-bc83aed55ec7" TYPE="ext4"
/dev/block/mmcblk0p60: UUID="cf81e7c0-047f-404a-81da-7d188dd0ccc0" TYPE="ext4"
/dev/sda1: LABEL="PTT" UUID="B4BE-1BCC" TYPE="vfat"

然後隨便找個地方例如就在/storage,創建一個目錄並且將u盤mount過去,接着將日誌拷貝過去:

mkdir sda
mount /dev/sda1 sda/
cp /storage/log.log /storage/sda
sync

然後我們就能把u盤拔出來插到我們自己的電腦上分析日誌了,從這個日誌裏面由於zygote還沒啓動成功,所以前面用的"Exit zygote"關鍵字是找不到日誌的,但是能看到一直在報native層的堆棧。

創建java虛擬機的時候找不到libaccelerator_base.so觸發斷言導致系統奔潰:

09-22 11:34:20.119  2233  2233 I tombstoned: received crash request for pid 3174
09-22 11:34:20.128  3209  3209 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
09-22 11:34:20.129  3209  3209 F DEBUG   : Build fingerprint: 'cvt/mt9950_cn/mt9950_cn:11/RP1A.200720.011/6182:user/release-keys'
09-22 11:34:20.129  3209  3209 F DEBUG   : Revision: '0'
09-22 11:34:20.129  3209  3209 F DEBUG   : ABI: 'arm64'
09-22 11:34:20.129  3209  3209 F DEBUG   : Timestamp: 2022-09-22 11:34:20+0800
09-22 11:34:20.130  3209  3209 F DEBUG   : pid: 3174, tid: 3174, name: main  >>> zygote64 <<<
09-22 11:34:20.130  3209  3209 F DEBUG   : uid: 0
09-22 11:34:20.130  3209  3209 F DEBUG   : signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
09-22 11:34:20.130  3209  3209 F DEBUG   : Abort message: 'Error preloading public library libaccelerator_base.so: dlopen failed: library "libaccelerator_base.so" not found'
09-22 11:34:20.130  3209  3209 F DEBUG   :     x0  0000000000000000  x1  0000000000000c66  x2  0000000000000006  x3  0000007fe9f17ef0
09-22 11:34:20.130  3209  3209 F DEBUG   :     x4  0000007c1de1e000  x5  0000007c1de1e000  x6  0000007c1de1e000  x7  000000000000168c
09-22 11:34:20.130  3209  3209 F DEBUG   :     x8  00000000000000f0  x9  0000007c192b17f8  x10 ffffff80fffffbdf  x11 0000000000000001
09-22 11:34:20.130  3209  3209 F DEBUG   :     x12 0000000000000000  x13 0000000000000655  x14 0000007fe9f16d10  x15 00008b1aad54c6e4
09-22 11:34:20.130  3209  3209 F DEBUG   :     x16 0000007c1934ac80  x17 0000007c1932bf20  x18 0000007c1d608000  x19 00000000000000ac
09-22 11:34:20.130  3209  3209 F DEBUG   :     x20 0000000000000c66  x21 00000000000000b2  x22 0000000000000c66  x23 00000000ffffffff
09-22 11:34:20.130  3209  3209 F DEBUG   :     x24 0000007987636000  x25 0000000000000002  x26 0000007987013c07  x27 000000000000002b
09-22 11:34:20.130  3209  3209 F DEBUG   :     x28 0000007987638000  x29 0000007fe9f17f70
09-22 11:34:20.130  3209  3209 F DEBUG   :     lr  0000007c192df0c4  sp  0000007fe9f17ed0  pc  0000007c192df0f4  pst 0000000000000000
09-22 11:34:20.151  3209  3209 F DEBUG   : backtrace:
09-22 11:34:20.151  3209  3209 F DEBUG   :       #00 pc 000000000004e0f4  /apex/com.android.runtime/lib64/bionic/libc.so (abort+180) (BuildId: c78cdff5b820a550771130d6bde95081)
09-22 11:34:20.151  3209  3209 F DEBUG   :       #01 pc 0000000000565bc8  /apex/com.android.art/lib64/libart.so (art::Runtime::Abort(char const*)+2320) (BuildId: a0e45eb7480266d293a7de84fc1c7a3c)
09-22 11:34:20.151  3209  3209 F DEBUG   :       #02 pc 0000000000013ab0  /system/lib64/libbase.so (android::base::SetAborter(std::__1::function<void (char const*)>&&)::$_3::__invoke(char const*)+80) (BuildId: 6d398535cd6d9315930f056432520bb9)
09-22 11:34:20.151  3209  3209 F DEBUG   :       #03 pc 0000000000006ec8  /system/lib64/liblog.so (__android_log_assert+336) (BuildId: c92329feece7a2d7fa4d9fb6acc815f9)
09-22 11:34:20.151  3209  3209 F DEBUG   :       #04 pc 000000000000ebcc  /apex/com.android.art/lib64/libnativeloader.so (android::nativeloader::LibraryNamespaces::Initialize()+324) (BuildId: 4e6450569b3bdee211e32baf7d0dfba7)
09-22 11:34:20.151  3209  3209 F DEBUG   :       #05 pc 000000000000e044  /apex/com.android.art/lib64/libnativeloader.so (InitializeNativeLoader+36) (BuildId: 4e6450569b3bdee211e32baf7d0dfba7)
09-22 11:34:20.151  3209  3209 F DEBUG   :       #06 pc 000000000039066c  /apex/com.android.art/lib64/libart.so (JNI_CreateJavaVM+732) (BuildId: a0e45eb7480266d293a7de84fc1c7a3c)
09-22 11:34:20.151  3209  3209 F DEBUG   :       #07 pc 00000000000a023c  /system/lib64/libandroid_runtime.so (android::AndroidRuntime::startVm(_JavaVM**, _JNIEnv**, bool, bool)+9060) (BuildId: 88ac6961382cb34f5fac714acaf48103)
09-22 11:34:20.151  3209  3209 F DEBUG   :       #08 pc 00000000000a0890  /system/lib64/libandroid_runtime.so (android::AndroidRuntime::start(char const*, android::Vector<android::String8> const&, bool)+464) (BuildId: 88ac6961382cb34f5fac714acaf48103)
09-22 11:34:20.151  3209  3209 F DEBUG   :       #09 pc 0000000000003570  /system/bin/app_process64 (main+1320) (BuildId: d4686d3f8282764488eb9ca7cc518583)
09-22 11:34:20.151  3209  3209 F DEBUG   :       #10 pc 00000000000495b4  /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+108) (BuildId: c78cdff5b820a550771130d6bde95081)
09-22 11:34:20.192  3175  3175 F libc    : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 3175 (main), pid 3175 (main)

像這種native的奔潰,如果logcat裏面定位不到根因的話可以分析/data/tombstones下的墓碑文件,裏面的信息比較全:

console:/data/tombstones # ls
tombstone_00  tombstone_07  tombstone_14  tombstone_21  tombstone_28
tombstone_01  tombstone_08  tombstone_15  tombstone_22  tombstone_29
tombstone_02  tombstone_09  tombstone_16  tombstone_23  tombstone_30
tombstone_03  tombstone_10  tombstone_17  tombstone_24  tombstone_31
tombstone_04  tombstone_11  tombstone_18  tombstone_25
tombstone_05  tombstone_12  tombstone_19  tombstone_26
tombstone_06  tombstone_13  tombstone_20  tombstone_27

死法五: 系統應用簽名錯誤導致系統崩潰開不了機

有時候我們在手動替換系統應用的時候會出現開不了機的情況,那麼由於是替換完應用纔出現問題的,所以我們可以直接接入串口過濾應用包名:

console:/storage # blkid logcat | grep me.linjw.demo
09-21 23:19:10.932  3611  3611 E AndroidRuntime: java.lang.IllegalStateException: Signature mismatch on system package me.linjw.demo for shared user SharedUserSetting{5a1fdd7 android.uid.system/1000}

從上面的信息就能很明顯的看到是me.linjw.demo的簽名錯誤導致拋出異常。

如果是編譯系統的時候應用簽名就錯了,升級軟件就開不了機,我們用前面的方法把logcat導出來,還是過濾下"Exit zygote"關鍵字,也是能看到日誌的:

09-21 23:19:11.061 3541 3541 E Zygote : Exit zygote because system server (pid 3611) has terminated

同樣再往上搜索3611進程的日誌可以看到是PackageManagerService在開機的時候搜索所有安裝的apk的時候觸發到了應用系統簽名錯誤的異常:

09-21 23:19:10.932  3611  3611 E AndroidRuntime: *** FATAL EXCEPTION IN SYSTEM PROCESS: main
09-21 23:19:10.932  3611  3611 E AndroidRuntime: java.lang.IllegalStateException: Signature mismatch on system package me.linjw.demo for shared user SharedUserSetting{5a1fdd7 android.uid.system/1000}
09-21 23:19:10.932  3611  3611 E AndroidRuntime:    at com.android.server.pm.PackageManagerService.reconcilePackagesLocked(PackageManagerService.java:16568)
09-21 23:19:10.932  3611  3611 E AndroidRuntime:    at com.android.server.pm.PackageManagerService.addForInitLI(PackageManagerService.java:9537)
09-21 23:19:10.932  3611  3611 E AndroidRuntime:    at com.android.server.pm.PackageManagerService.scanDirLI(PackageManagerService.java:9131)
09-21 23:19:10.932  3611  3611 E AndroidRuntime:    at com.android.server.pm.PackageManagerService.scanDirTracedLI(PackageManagerService.java:9083)
09-21 23:19:10.932  3611  3611 E AndroidRuntime:    at com.android.server.pm.PackageManagerService.<init>(PackageManagerService.java:3111)
09-21 23:19:10.932  3611  3611 E AndroidRuntime:    at com.android.server.pm.PackageManagerService.main(PackageManagerService.java:2599)
09-21 23:19:10.932  3611  3611 E AndroidRuntime:    at com.android.server.SystemServer.startBootstrapServices(SystemServer.java:851)
09-21 23:19:10.932  3611  3611 E AndroidRuntime:    at com.android.server.SystemServer.run(SystemServer.java:590)
09-21 23:19:10.932  3611  3611 E AndroidRuntime:    at com.android.server.SystemServer.main(SystemServer.java:408)
09-21 23:19:10.932  3611  3611 E AndroidRuntime:    at java.lang.reflect.Method.invoke(Native Method)
09-21 23:19:10.932  3611  3611 E AndroidRuntime:    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
09-21 23:19:10.932  3611  3611 E AndroidRuntime:    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:925)
09-21 23:19:10.933  3611  3611 E AndroidRuntime: Error reporting crash
09-21 23:19:10.933  3611  3611 E AndroidRuntime: java.lang.NullPointerException: Attempt to invoke interface method 'void android.app.IActivityManager.handleApplicationCrash(android.os.IBinder, android.app.ApplicationErrorReport$ParcelableCrashInfo)' on a null object reference
09-21 23:19:10.933  3611  3611 E AndroidRuntime:    at com.android.internal.os.RuntimeInit$KillApplicationHandler.uncaughtException(RuntimeInit.java:158)
09-21 23:19:10.933  3611  3611 E AndroidRuntime:    at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1073)
09-21 23:19:10.933  3611  3611 E AndroidRuntime:    at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1068)
09-21 23:19:10.933  3611  3611 E AndroidRuntime:    at java.lang.Thread.dispatchUncaughtException(Thread.java:2203)
09-21 23:19:10.933  3611  3611 I Process : Sending signal. PID: 3611 SIG: 9
09-21 23:19:11.061  3541  3541 E Zygote  : Zygote failed to write to system_server FD: Connection refused
09-21 23:19:11.061  3541  3541 I Zygote  : Process 3611 exited due to signal 9 (Killed)
09-21 23:19:11.061  3541  3541 E Zygote  : Exit zygote because system server (pid 3611) has terminated

總結

1.如果發現system_server的進程號比較大,那麼大概率重啓過

2.可以用"Exit zygote"關鍵字去搜索找到system_server掛掉的時間,如果沒有這個找不到這個關機字的話也能搜索下"START com.android.internal.os.ZygoteInit"看看重啓的時間,然後往上搜索下面的關鍵字找具體死因:

  • DEBUG : native 層出現異常的時候會有堆棧的打印
  • crash : 奔潰信息打印
  • kill : 一些異常觸發系統被強殺
  • tombstone : 虛擬機、c層的錯誤觸發墓碑文件生成
  • died : 某些服務死掉
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章