Why is the API 34+ importance-based app-start check not used below API 34?

[ankursamarya]

Background

app_start being suppressed on API 34+ (#8103). The old timing-window heuristic was replaced on API 34+ by a RunningAppProcessInfo.importance read at first capture. The changelog says "Pre-API-34 behavior is unchanged."

So today there are two different signals:

• Below 34 — StartFromBackgroundRunnable is posted to the main Looper from FirebasePerfEarly (FirebasePerfEarly.java:55). If it runs before the first onActivityCreated, the start is treated as background (AppStartTrace.java:350-356).
• 34+ — ActivityManager.getMyMemoryState() importance is read once during registerActivityLifecycleCallbacks. Only IMPORTANCE_FOREGROUND allows the trace (AppStartTrace.java:360).

Question

ActivityManager.getMyMemoryState() has been available since API 16, and AppStartCause.readImportance() already runs on every API level (AppStartCause.java:79). Only the classification is gated:

if (apiLevel >= 34) {
    Cause cause = importance == IMPORTANCE_FOREGROUND
        ? Cause.FOREGROUND
        : Cause.UNKNOWN;
    return new AppStartCause(cause, importance, apiLevel);
}

// API < 34: legacy AppStartTrace logic owns the decision.
return new AppStartCause(Cause.UNKNOWN, importance, apiLevel);

What specifically blocks using the importance signal below API 34?

[jrodiz]

Good question, and the framing is right: nothing blocks the read. getMyMemoryState() has been available since API 16, AppStartCause.readImportance() runs on every API level, and importance is recorded on every API level. Only the classification is gated, and that gate is a scoping-of-risk decision rather than an API-availability one. Five reasons, roughly in order of weight.

1. There is no pre-API-34 defect to fix. #8103 is an API-34+ ordering change; the OS drains the posted runnable before delivering the activity-launch transaction. Below 34 the ordering holds as designed. The legacy check isn't a tolerated workaround there; it's correct.

2. The signals aren't equivalent: swapping below 34 would regress warm-start suppression. The legacy check is a relative ordering at the first onActivityCreated; importance is a single sample at ContentProvider init. PROCESS_STATE_BOUND_TOP maps to IMPORTANCE_FOREGROUND, so a process forked by a foreground app binding one of its services samples FOREGROUND with no activity involved, and a warm start that follows would be admitted as _app_start, which the pre-34 path suppresses today. That changes what the metric measures.

3. Importance-driven suppression fails silently. A wrong sample on a genuine launcher tap drops _app_start with no error surface — the shape of #8103, and why it went unnoticed so long. The legacy check fails the other way: ambiguity keeps the trace. On 34+ that trade beat losing the trace entirely; below 34 there's nothing on the other side of it.

4. The procState → importance mapping isn't one function pre-34. procStateToImportanceForTargetSdk returns the *_PRE_26 / *_PRE_28 constants for apps targeting below API 26, and pre-Oreo devices predate the background-execution limits. With minSdk 23, acting on the signal below 34 asserts a stable meaning for IMPORTANCE_FOREGROUND across API 23–33 on every OEM ROM.

5. No production data backs the swap on that population. The 34+ flip rests on four emulator images across three trigger scenarios plus the device reports in #8103 and #5920 (I will get back with the tests I made, let me search them for your reference), which show nothing on API 23–32, OEM ROMs, or FCM- and JobScheduler-driven starts, which are exactly the triggers at risk. The rollout plan required demonstrated agreement between the two signals in production before flipping a tier; that data exists for 34+ and not below.

The intent isn't "importance everywhere eventually" — it's the best validated signal per tier. API 35+ has ApplicationStartInfo, which is authoritative rather than inferential and is the better long-term answer there; it isn't used yet because the OS often hasn't recorded the process start by the time FirebasePerfEarly captures.

What would unblock extending it downward: importance is recorded on every API level on purpose. Shadow-comparing the importance-derived decision against the legacy one across the pre-34 fleet, and seeing high agreement including on OEM ROMs, turns this from an assumption into a data-backed change.

I've put this rationale into AppStartCause as a docs-only change so the next reader finds it at the gate instead of having to ask. Will post the PR shortly

fyi... @tejasd