Android Baggage Screening，业内常称为行李检查测试，是Google对Android设备出厂镜像进行质量筛查的一道重要关卡。凡是需要通过GMS认证（Google Mobile Services认证）的设备，送测时Google都会对设备中的预装应用做一次全面体检，检查是否有崩溃、安全漏洞、隐私违规、功能异常等问题。很多OEM厂商和应用开发团队在第一次接触送测流程时，容易在这一环节被卡住，返工成本很高。理解它的检测逻辑和执行方法，能帮助你在送测前提前把问题解决掉。
一、行李检查测试到底检查什么
从名字上看，baggage（行李）指的就是设备出厂时自带的那些东西，包括预装APK、系统配置、默认设置等。Google的检测脚本会把设备当成一件待安检的行李，逐个扫描里面的内容，任何可能影响用户体验或违反兼容性规范的问题都会被标记出来。
具体的检测范围主要分几大类。第一类是应用稳定性，检测预装应用在启动、常用操作路径下是否出现崩溃或ANR，比如system_server崩溃、开机后桌面反复重启这类问题会被直接列为严重项。第二类是安全和隐私合规，包括应用是否申请了不必要的敏感权限、targetSdkVersion是否达到最低要求、是否在用户不知情的情况下采集数据等。第三类是功能完整性，比如拨号、短信、相机、设置这些核心功能是否正常工作，预装的第三方应用是否可以正常卸载或停用。
需要特别注意的是，行李检查测试不是简单跑一遍CTS就完事。CTS（Compatibility Test Suite）侧重的是API层面的兼容性，而行李检查更关注整机出厂状态的实际表现，两者互补，缺一不可。有些设备CTS全绿，但行李检查照样能扫出一堆预装应用崩溃记录，这就是因为两者的关注维度不同。
二、如何在本地搭建环境模拟执行
在正式送测之前，建议先在本地环境做一轮自检。虽然Google内部的完整检测工具链不对外公开，但绝大部分检测项可以通过公开工具组合来模拟。基础环境需要一台Linux主机（推荐Ubuntu），配置好Android SDK和adb工具，并准备一台刷好user版本固件的待测设备，注意必须是user版本而不是userdebug版本，因为行李检查评估的就是量产固件的真实状态。
环境搭建的核心步骤如下：
# 安装Android SDK基础工具 sudo apt-get update sudo apt-get install openjdk-17-jdk android-tools-adb # 配置SDK路径（示例） export ANDROID_HOME=/home/user/Android/Sdk export PATH=$PATH:$ANDROID_HOME/platform-tools # 验证设备连接状态 adb devices adb shell getprop ro.build.type # 确认输出为 user
搭建好环境后，先做一轮基础信息采集，确认设备的固件属性符合送测要求。比如targetSdkVersion、安全补丁级别、系统版本号这些字段，都是检测报告里最先被检查的项。
# 采集设备关键属性 adb shell getprop ro.build.version.release # Android版本 adb shell getprop ro.build.version.security_patch # 安全补丁级别 adb shell getprop ro.build.fingerprint # 固件指纹 # 列出所有预装应用 adb shell pm list packages -s | sort > preinstalled_packages.txt
拿到预装应用列表后，逐个检查这些包的targetSdkVersion是否满足Google Play的最新要求。低于门槛的应用在送测时会被直接拒绝，这是最常见的返工原因之一。
三、常见不合规项及修复思路
根据实际的送测经验，行李检查中暴露的问题集中在几个固定区域。第一个高发区是预装应用崩溃。检测脚本会monkey测试配合定向启动的方式遍历所有预装应用，任何一个应用出现连续崩溃都会被记录。修复方法是通过adb logcat抓取崩溃堆栈，定位到具体的应用版本后更新或替换。自检时可以用下面的命令模拟这个过程：
# 用monkey对指定预装应用做稳定性测试 adb shell monkey -p com.example.preinstalled --throttle 300 \ -s 500 --ignore-crashes --ignore-timeouts -v 50000 # 抓取崩溃日志 adb logcat -b crash -d > crash_log.txt
第二个高发区是权限滥用。一些预装的运营类、工具类应用会申请大量与功能无关的权限，比如一个天气应用申请短信权限，这类问题在隐私监管趋严的背景下会被重点标记。修复思路是逐包导出权限声明做审查：
# 导出指定应用的权限申请情况 adb shell dumpsys package com.example.preinstalled | grep "requested permissions" -A 30
第三个高发区是不可卸载的第三方应用。Google规定，非核心功能的第三方预装应用必须支持用户卸载或至少停用，如果应用被声明在特权目录里且没有合理理由，就会被判定违规。修复时可以调整应用的安装分区，把非必要应用从/system/priv-app移到普通区域，或者通过overlay配置声明其为可卸载。
四、测试报告解读与送测前的自查清单
拿到检测报告后，要按严重程度分级处理。标记为Critical的问题必须全部修复才能重新送测，比如核心功能崩溃、安全漏洞；标记为High的问题原则上也要清零，个别Medium项如果修复成本过高，可以在送测说明中给出解释和后续修复计划。切忌抱着侥幸心理带病送测，一次送测失败的重测周期通常要两到四周，直接影响产品上市节奏。
送测前建议按这份清单做最后一轮自查：确认固件是正式签名的user版本；安全补丁级别达到要求；所有预装应用targetSdkVersion达标；monkey测试两小时无崩溃；敏感权限申请有对应功能说明；不可卸载应用仅限核心系统组件。把这份清单跑完，行李检查的通过率会有明显提升。
总的来说，行李检查测试考察的是设备出厂时的整体质量状态，与其把它当成一道门槛，不如当成一次免费的全面体检。在开发流程中尽早引入这些自检手段，把问题消化在送测之前，才是控制认证成本最有效的方式。