OpenHarmony 3.2 无法进入桌面分析思路

本文分享了无法进入桌面时的常见分析思路，如有遗漏，欢迎补充。

在提供思路前，我们需要了解在OpenHarmony上，应用依赖的服务有哪些，开机动画的消失时机是什么，以及预装应用安装与启动的大概流程，方便出现问题是能快速定位。

基础应用依赖的服务

进程名	id	依赖	作用	备注
foundation	401		包管理
foundation	4606		窗口管理
foundation	180		元能力管理
foundation	3308		display管理
foundation	3299		公共事件管理
foundation	3203	3299、1301	通知管理	需开启内核选项CONFIG_ASHMEM
foundation	501		应用管理
accesstoken_service	3503		应用权限管理
account_mgr	200		账户管理
multimodalinput	3101		多模输入
storage_manager	5003	3299	存储管理	需开启内核选项CONFIG_HMDFS_FS与CONFIG_HMDFS_FS_PERMISSION
distributeddata	1301		分布式数据管理
softbus_server	4700		分布式软总线

此外，应用运行还依赖如下进程：

• appspawn：应用孵化进程，应用进程都是从该进程孵化出来。

• samgr：SystemAbility管理，上述的所有服务都是通过该进程管理。

• render_service：图形渲染服务

预装应用安装与启动

安装

• 包管理服务在启动时，会扫描/system/app下的所有hap文件，并安装所有的singleton为true的应用，如SystemUI。

• 账户服务在启动时，会创建系统账户（0号）与标准账户（100号），创建标准账户后会切换至标准账户，并通知包管理服务。

• 包管理服务在收到账户服务的通知后，继续安装剩余的应用，如Launcher。

• 应用的安装过程大致分为安装包校验、安装包解析、代码解压、用户目录创建等过程。

• 应用代码被存放在/data/app/el1/bundle/public。

• 应用安装成功后，会将应用数据（包名、代码路径、数据路径、ability信息）写入包管理的数据库中。

启动

• 元能力管理服务在启动时，会尝试启动所有的常驻进程，即singleton与keepAlive均为true的应用，如SystemUi。

• 切换至标准用户后，且开机动画显示后，尝试启动该用户的最高优先级应用，即priority最大的应用，默认是Launcher。

开机动画消失时机

开机动画的消失，依赖于如下bootevent：

1. appspwan的bootevent.appspawn.started

2. param_watcher的bootevent.param_watcher.started

3. bootanimation的bootevent.bootanimation.started

4. foudation中窗口管理的的bootevent.wms.fullscreen.ready

5. samgr的bootevent.samgr.ready

6. 锁屏应用的bootevent.screenlock.ready

当上述6个bootevent均ready后，开机动画会消失。

分析思路

以下思路均建立在图形适配已经OK的情况下。

开机动画异常

无法进入开机动画的情况下，需要查看init、render_service、samgr、foundation等基础进程是否正常启动了，可以进入设备的/data/log/faultlog/faultlogger下看看是否有进程的崩溃记录。

必要时可以查看串口日志中内核是否有异常信息。

开机动画正常

开机动画正常显示，但是无法进入桌面，俗称卡logo。

检查桌面应用

首先需要检查桌面是否安装成功并启动。

安装

安装可以通过bm命令或查看代码安装路径内是否有内容：

# bm dump -n com.ohos.launcher
com.ohos.launcher:
{
    "appId": "com.ohos.launcher_BNtg4JBClbl92Rgc3jm/RfcAdrHXaM8F0QOiwVEhnV5ebE5jNIYnAx+weFRT3QTyUjRNdhmc2aAzWyi+5t5CoBM=",
    "appIndex": 0,
    "applicationInfo": {
        "accessTokenId": 537765300,
        "accessible": false,
        "allowCommonEvent": [],
        "apiCompatibleVersion": 9,
        "apiReleaseType": "Release",
        "apiTargetVersion": 9,
        "appDetailAbilityLibraryPath": "",
        "appDistributionType": "os_integration",
        "appPrivilegeLevel": "system_basic",
        "appProvisionType": "release",
        "appQuickFix": {
            "bundleName": "",
            "deployedAppqfInfo": {
  ......            

# cd /data/app/el1/bundle/public/com.ohos.launcher
# ls
launcher_settings  ohos.global.systemres          systemResources
misc               ohos.global.systemres.overlay
nweb               phone-launcher

启动

启动是否成功：

# ps -ef | grep launcher
20010037      1583   257 0 10:13:26 ?     00:00:06 com.ohos.launcher
root          2671  2648 5 10:43:01 pts/1 00:00:00 grep launcher

接下来需要分成几种情况来说明。

安装成功启动也成功

此时说明系统与框架没有问题，问题可能出在应用。需要检查Launcher应用的日志内，是否有明显的错误。正常情况下，Launcher应用会在影响流程的关键代码处，均加上日志。

出现这种情况，可能是应用业务代码出现问题，也可能是某个系统api出现问题。

安装成功但启动不成功

启动不成功一般是在启动过程中闪退了，可以查看/data/log/faultlog/faultlogger目录下是否有闪退日志。如果没有闪退日志，则需要分析：

1、ams是否有拉起Launcher，相关日志关键字：

Start the highest priority

该日志会指明bundleName与abilityName。如果没有该日志，需要检查Launcher应用的skills与priority是否正确，可以对比与系统版本对应社区版本的Launcher的配置文件。还需要检查ams服务是否启动正常，可以通过查看元能力相关的日志确认。

2、应用框架是否正常：

# kill `pidof bootanimation`

强行kill开机动画后，如果屏幕上下有状态栏和导航栏，说明应用框架相关服务正常，需重点分析Launcher启动日志，或查看是否有闪退日志。如果屏幕全黑，则需检查与应用相关的那些服务是否正常。

安装不成功

安装不成功的情况，大概率是基础应用依赖的服务有一个或多个异常。根据预装应用安装的流程可以知道，Launcher与SystemUI的安装时机不一样，反映到系统内则是账户服务切换系统账户的过程，所以我们可以首先查看SystemUI是否安装正常：

# bm dump -n com.ohos.systemui

1、如果SystemUI也未安装，可能是BMS整个就没有启动，可以查看包管理相关日志确认。或者在下载源代码时，未拉取大文件导致所有的hap未下载，此时可以查看/system/app下的所有hap包的大小，是否只有几kb。如果hap包大小正常，可以尝试手动安装launcher看看是否报错：

# bm install -r -p /system/app/com.ohos.launcher/Launcher.hap

如果报错，可根据报错信息查找相关代码。

2、如果SystemUI安装成功，但是Launcher不成功，则需要检查100号账户是否已经创建并active：

# acm dump -a
ID: 100
        Name: u**********
        Type: admin
        Status: active
        Constraints:
                constraint.wifi
                constraint.wifi.set
                constraint.locale.set
                constraint.app.accounts
                constraint.apps.install
                constraint.apps.uninstall
                constraint.location.shared
                constraint.unknown.sources.install
                constraint.global.unknown.app.install
                constraint.bluetooth.set
                constraint.bluetooth
        Verified: true
        Serial Number: 2021023100000001
        Create Completed: true
        To Be Removed: false

• 如果100号用户未创建或状态不正常，则需要通过日志来分析不正常的原因。此时可以通过acm create -n test -t admin手动创建账户，看是否报错。

• 账户服务会受storage服务影响，可以通过该服务的sa id 5003来筛选日志，看服务是否启动成功。

• 日志搜索关键字HMDFS，如果有相关报错，则可能是内核选项CONFIG_HMDFS_FS未打开。

bootevent

如果桌面安装、启动、日志均正常，则需要检查开机动画依赖的bootevent的相关进程是否都已经正常启动：

• appspwan

• paramwatcher

• foudation

• samgr

• com.ohos.systemui

如果有进程没有起来，可以查看设备/data/log/faultlog/faultlogger下看看是否有进程的崩溃记录。当然，绝大部分情况下前4个进程不会有问题，如果有问题桌面的安装和启动也不会正常，因此我们需要重点排查最后一个SystemUI，具体一点就是锁屏应用。

• 首先通过bm命令查看锁屏应用是否安装：

  # bm dump -n com.ohos.systemui

  查看其中是否包含screenlock的信息，如：

   ......
   "extensionInfos": [
                  {
                      "bundleName": "com.ohos.systemui",
                      "compileMode": 0,
                      "description": "$string:MainAbility_desc",
                      "descriptionId": 150995217,
                      "enabled": true,
                      "hapPath": "/system/app/com.ohos.systemui/SystemUI-ScreenLock.hap",
                      "icon": "$media:icon",
                      "iconId": 150994954,
                      "label": "$string:app_name",
                      "labelId": 150994944,
                      "metadata": [],
                      "moduleName": "phone",
                      "name": "com.ohos.systemui.screenlock.ServiceExtAbility",
                      "permissions": [],
                      "priority": 0,
                      "process": "",
                      "readPermission": "",
                      "resourcePath": "/data/app/el1/bundle/public/com.ohos.systemui/phone/resources.index",
                      "srcEntrance": "./ets/ServiceExtAbility/ServiceExtAbility.ts",
                      "type": 3,
                      "uri": "",
                      "visible": true,
                      "writePermission": ""
                  }
              ],
              "hapPath": "/system/app/com.ohos.systemui/SystemUI-ScreenLock.hap",
  ......

• 如果安装成功，检查日志中是否有ScreenLock相关日志，确保锁屏应用启动成功。如果没有日志，重点则需要转移到锁屏应用启动失败的问题上

• 如果安装不成功，检查/system/app/com.ohos.systemui/SystemUI-ScreenLock.hap是否存在，或者大小是否正常。

• 可以尝试手动安装，看是否报错bm install -r -p /system/app/com.ohos.systemui/SystemUI-ScreenLock.hap

此步骤的目的是确保锁屏应用启动了，系统为了保证锁屏界面是开机动画后的第一帧，做了如果锁屏不启动开机动画不消失的限制。

总结

无法进入桌面可能得原因有很多，需要根据现象一步步的排查。主要思路就是从开机动画与桌面应用入手，根据其安装状态、启动状态的差别可以定位到不同的服务，再结合日志深入分析具体的原因。