Cold-start crashes that CI never saw

Why a green pipeline can still ship an Android cold-start crash — and what auditors look for when flaky lanes hide the signal.

A pipeline that is “usually green” is not the same as a release gate. In more than one Android audit we have found cold-start crashes gated behind a flaky emulator job that engineers learned to re-run until it passed.

What to inspect

  • Jobs marked optional or continue-on-error that still cover startup
  • Emulator images that differ from the minimum OS you claim to support
  • Initialization order in Application subclasses and ContentProviders
  • Third-party SDKs that assume network on first launch

A practical habit

Treat re-runs as a smell. If a startup job fails twice in a week, log it in the release readiness memo even when the eventual colour is green. Auditors will ask for that history; having it ready shortens the review.

When we flag a cold-start issue as a blocker, we include the stack signature and the exact job name that should have caught it. That combination is what moves a debate from opinion to scheduling.

← Back to Field Notes