Feature/jrc 8103.fix.api.34.heuristic#8317
Conversation
#8103) Replace the timing-window heuristic in resolveIsStartedFromBackground on API 34+ with an OS-reported process start cause. Pre-API-34 keeps the legacy runnable-before-onActivityCreated check. API < 34: mainThreadRunnableTime set first ⇒ suppress (legacy, unchanged). API 34+: ProcessStartCause.cause FOREGROUND ⇒ log. UNKNOWN / null ⇒ suppress. New ProcessStartCause helper reads RunningAppProcessInfo.importance at first capture via ActivityManager.getMyMemoryState. IMPORTANCE_FOREGROUND indicates an activity-driven start; anything else maps to UNKNOWN. Pre-API-34 returns UNKNOWN and the legacy AppStartTrace logic owns the decision. FirebasePerfEarly stops scheduling StartFromBackgroundRunnable on API 34+ since its output is no longer consumed there. :firebase-perf:testReleaseUnitTest — 0 failures / 0 errors. AppStartTraceTest 9/9, ProcessStartCauseTest 6/6.
Rename ProcessStartCause → AppStartCause (class, field, test helpers/class) per review, and document resolveIsStartedFromBackground: the pre-API-34 branch is the only one that checks/clears mainThreadRunnable; the API 34+ branch is driven by the OS-reported cause.
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. |
📝 PRs merging into main branchOur main branch should always be in a releasable state. If you are working on a larger change, or if you don't want this change to see the light of the day just yet, consider using a feature branch first, and only merge into the main branch when the code complete and ready to be released. |
firebase-perf: fix API 34+ background-start heuristic in AppStartTrace
Fixes #8103 (follow-up to b/339891952).
AppStartTrace's background-start detection relied on the ordering of a posted main-thread runnable vs the firstonActivityCreated. On API 34+ the OS can drain the runnable before delivering the activity-launch Binder transaction even on a genuine cold foreground launch — the gap on real Pixel devices is ~200–300 ms, well above the previous 50 ms tolerance. Every affected user lost their_app_starttraces.Fix
On API 34+,
resolveIsStartedFromBackgroundswitches from the timing-window heuristic to an OS-reported process start cause. Pre-API-34 is unchanged.The new
AppStartCausehelper readsRunningAppProcessInfo.importanceviaActivityManager.getMyMemoryStateonce, at first capture insideAppStartTrace.registerActivityLifecycleCallbacks.IMPORTANCE_FOREGROUND⇒FOREGROUND(activity-driven start); anything else ⇒UNKNOWN. Pre-API-34 returnsUNKNOWNso the legacy decision stays in charge.FirebasePerfEarlystops schedulingStartFromBackgroundRunnableon API 34+ since its output is no longer consumed.Behavior matrix
Tests
./gradlew :firebase-perf:spotlessApply :firebase-perf:testReleaseUnitTest— 0 failures.AppStartTraceTest9/9 (@Config(sdk = 33)for the pre-API-34 path; FOREGROUND / UNKNOWN / null for API 34+).AppStartCauseTest6/6 (null-context, pre-API-34, API 34 FOREGROUND / SERVICE / CACHED importance branches, constructor).Test project app: https://github.com/jrodiz/firebase-perf-e2e-for-issue8103
Risks
_app_startemission rate rises on the previously-broken population — the intent.RunningAppProcessInfo.importanceis stable public SDK and a single Binder IPC; no reflection.