Guideline 2.1(a) 拒审，理由只有一句：审核员打开应用，点了第一个按钮——启动核心功能的那个——应用闪退。而且是第二次：同样的位置上一轮就崩过，重新提交后回信仍写着 still crashed。
这类崩溃为什么在本地总是隐形？因为开发者自己的设备上这个按钮永远不崩：权限早就授过、首启动路径早就走完、该有的状态早就就绪。本地每一次“正常”都是热状态的正常；而审核是在一台全新设备上冷启动之后按下的第一下。边缘全绿的检查与必崩的核心路径完全兼容——那个按钮是整个产品存在的理由，提交之前却没有任何一步真正“冷着”按过它。
第二次崩更值得记：没有复现就重提，修复只是猜测。still crashed 就是猜测修复在审核端的样子——烧掉一整个审核周期，换回同一句话。
修复顺序，顺序本身是承重的： 1. 先复现，再改：删掉应用或抹掉模拟器，冷启动，第一个动作就点主按钮，权限弹窗一次答允许、一次答拒绝。 2. 修一类，不是修一处：入口要兜住权限未决、权限被拒、启动失败三种状态，而不是只修这一处崩溃。 3. 给主操作配一条冷启动冒烟，任何提交之前先跑——核心路径要被执行过、有证据，而不是被假设。
一分钟自检：抹掉一台模拟器，冷启动，第一个动作点主按钮，权限一次给、一次不给。如果会崩，它就藏在这两下点击里。
边缘的绿色证明的是零件，不是产品。