我来帮你梳理问题根源和对应的解决思路，都是折腾AOSP编译踩过的实际坑：

首先说你碰到的第一个问题——lunch时提示kernel目录缺失：
你选的aosp_shiba-trunk_staging-userdebug是谷歌的预发布测试分支，这类分支的源码同步经常有延迟，尤其是对应到具体的AOSP tag（比如android-15.0.0_r20）时，kernel仓库的指定版本可能还没同步到本地，就会出现路径不存在的错误。你手动切到main分支虽然让目录出现了，但这直接埋下了后面启动失败的隐患。

解决lunch失败的正确姿势 #

• 优先用稳定的lunch目标：放弃trunk_staging测试分支，直接选aosp_shiba-userdebug，这是Pixel 8对应的稳定userdebug编译目标，和android-15.0.0_r20的tag匹配度最高，不会出现依赖目录缺失的问题。
• 如果非要用trunk_staging目标：别乱切kernel分支到main，要同步到和当前AOSP tag对应的kernel版本。你可以打开.repo/manifests目录下的对应manifest文件，找到device/google/shusky-kernels/6.1对应的commit哈希，然后进入该目录执行git checkout <对应commit哈希>，这样就能拿到和系统tag同步的kernel源码，解决lunch的路径错误。

然后是刷机后卡启动页的问题：
这完全是因为你把kernel切到main分支导致的版本不兼容——main分支的kernel可能包含了和android-15.0.0_r20系统框架不匹配的改动，比如驱动逻辑、系统调用接口的变化，系统启动时kernel和上层服务对接不上，自然就卡在启动页了。

修复启动卡屏的步骤 #

1. 回滚kernel到对应tag的版本：按照上面说的，用manifest里指定的版本切回正确的kernel分支，不要用main。
2. 彻底清除旧编译产物：执行make clobber清空所有之前的编译文件，避免残留的main分支kernel代码和新编译的系统混合，导致奇怪的兼容性问题。
3. 重新完整编译：重新lunch正确的目标，然后执行make -j$(nproc)编译完整的镜像，确保kernel和系统的每一部分都是同步的版本。

最后再给你两个小提醒：

• 同步源码时一定要用repo sync -c -j$(nproc)，-c参数会只同步当前分支的commit，避免同步到无关分支导致仓库混乱。
• 遇到分支依赖问题时，优先看AOSP的官方manifest文件，里面的每个仓库版本都是和当前tag严格绑定的，跟着它走就不会错。

内容来源于stack exchange