[Analytics] Basic Consent migration control for legacy persisted collection enablement #8711

Activity

1. lehcar09

   added

   api: analytics

   on Oct 16, 2026
2. ProfSeaquill commented on Oct 28, 2026

   

   ProfSeaquill

   on Oct 28, 2026

   More actions

   Additional synthetic native reproduction for the legacy persisted-ON migration case, including a provider-before-Activity experiment. This adds an Android 35 / local-measurement-module environment and paired measurement-service database evidence.

   Scope: this concerns a legacy SDK grant with unknown consent provenance. It does not imply that valid affirmative consent must be revoked every launch, nor establish production-user impact or universal impossibility.

   Environment and preconditions

   • Firebase Analytics 23.2.0, Firebase Common 22.1.0; Crashlytics NDK 20.1.0 and Ads 25.4.0 / transitive UMP 4.0.0 also present. No UMP request or ad request was made in the candidate.
   • Android 35 Google ATD ARM64 emulator; GMS 24.23.35 (190408-646585959); selected local measurement module 185. The module label is not the Maven SDK version.
   • Fake Firebase/sample Ads configuration, no production project or real player data. IPv4/IPv6 egress was denied before installation and throughout the run. This is local collection/admission evidence, not cloud receipt or transmission evidence.
   • Public API seed: Analytics storage GRANTED, collection ON, then a late grant and a non-null public app-instance ID as positive controls. Read-only copied preferences confirmed G101, measurement_enabled=true and measurement_enabled_from_api=true. These prove SDK state, not affirmative user consent.
   • Candidate preserved app data, versionCode and versionName; this is a cold-start case, not an app-update case. No private SDK preference/database writes.

   Candidate

   Remove FirebaseInitProvider. Our non-exported provider has initOrder=1000. Its onCreate initializes Firebase, immediately disables collection through the public API, requests getSessionId() with an explicit background completion executor, then waits only for the remaining portion of a two-second deadline measured before initialization. No Firebase calls occur in the Application/Activity callbacks.

   Relevant manifest metadata:

   <meta-data android:name="firebase_analytics_collection_enabled" android:value="false" />
   <meta-data android:name="firebase_crashlytics_collection_enabled" android:value="false" />
   <meta-data android:name="google_analytics_default_allow_analytics_storage" android:value="false" />
   <meta-data android:name="google_analytics_default_allow_ad_storage" android:value="false" />
   <provider android:name="com.google.firebase.provider.FirebaseInitProvider"
       android:authorities="${applicationId}.firebaseinitprovider"
       tools:node="remove" />

   Core sequence (abridged from the exercised fixture; not a separately rerun standalone sample):

   long deadlineNs = SystemClock.elapsedRealtimeNanos() + TimeUnit.SECONDS.toNanos(2);
   ExecutorService completionExecutor = Executors.newSingleThreadExecutor();
   CountDownLatch completed = new CountDownLatch(1);
   
   FirebaseApp.initializeApp(context);
   FirebaseAnalytics analytics = FirebaseAnalytics.getInstance(context);
   analytics.setAnalyticsCollectionEnabled(false);
   analytics.getSessionId().addOnCompleteListener(completionExecutor, task -> {
       // Record elapsed timestamp, success/null result and callback thread.
       completed.countDown();
       completionExecutor.shutdown();
   });
   completed.await(Math.max(0, deadlineNs - SystemClock.elapsedRealtimeNanos()),
                   TimeUnit.NANOSECONDS);
   return true; // Provider returns; normal Activity lifecycle can proceed.

   The actual fixture also records callback status and deadlines separately. We do not assume getter completion acknowledges collection OFF or provides a documented synchronization contract. This was an empirical ordering experiment, not a proposed production workaround. Neither consent denial nor reset was invoked in this candidate.

   Result

   Relative to public collection-OFF return:

   Time	Observation
   +660 ms	SDK detects process already foreground
   +661 ms	New raw _s event timestamp
   +663 ms	Client logs session started
   +842 ms	Worker applies collection OFF
   +869 ms	Genuine getter completion observed / provider wait returns
   +875 ms	Provider exits
   +999 ms	First Activity onCreate
   +1087 ms	First Activity resumes
   +1507 ms	GMS logs session_start ingestion

   Getter completion was successful, non-null, on pool-2-thread-1, about 596 ms before the explicit deadline. Provider duration was about 1409 ms. The failure was therefore not a timeout or a main-thread completion-listener deadlock: the automatic session was generated before the fence completed and before any Activity lifecycle.

   Paired read-only copies of the measurement-service database show raw rows 5 → 6. The only new row was _s, payload SHA256:

   ccaaee6b70172d0f9735688d6824480ea3de59c22a535a393ca5619bb09e383b

   No additional app-update/first-open row or queued upload bundle appeared in this case. An ADB-listener interruption delayed final capture; recovery copied the same uninterrupted candidate process, without relaunching the Activity/app or running another case. The ordering logs were already captured before that interruption.

   We also separately tried removing FirebaseInitProvider and deferring first Firebase construction until after the first Activity resume, immediately followed by public collection OFF. That arrangement also admitted a new automatic session before worker OFF.

   Clarification requested

   Is there a supported startup/migration control that supersedes legacy unknown-provenance persisted enablement before automatic event admission, while still allowing collection after a valid decision in the same release?

   If the correct approach uses a different public API or initialization arrangement, what is its ordering contract across the client and Play services measurement process? We want to avoid private preference writes, undocumented Bundle keys, getter-as-ack assumptions, provider blocking, and treating a multi-release migration as safe when users can skip intermediate releases.

   No production configuration, credentials, real-user device logs or database payloads are attached.
3. YanlongLai commented on Oct 30, 2026

   

   YanlongLai

   on Oct 30, 2026

   Author

   More actions

   @ProfSeaquill Thanks for the additional reproduction and for clearly separating local event admission from transmission or backend receipt.

   The provider-before-Activity result is particularly useful: in this capture, the new _s event precedes worker-side collection OFF and the first Activity callback, despite the public setter having returned. Getter completion therefore does not resolve the startup boundary being requested here. This remains evidence for the tested configuration, rather than proof that every initialization arrangement behaves identically.

   For the Firebase Analytics team, could you clarify whether there is a supported public initialization or migration mechanism that prevents automatic event admission when an existing installation has persisted collection ON but the app cannot establish the provenance of that consent? The requirement is to keep Analytics disabled until a valid choice, while allowing opt-in in the same release and keeping unrelated Firebase products usable, including for users who skip intermediate releases.

   If such a mechanism exists, please point us to its documented ordering guarantees, including the Play services measurement process. If it does not, documenting that limitation and the supported migration alternative would help. We are not proposing provider blocking or getter completion as a production synchronization contract, and this request does not require revoking valid affirmative consent on every launch.
4. lehcar09 commented on Oct 30, 2026

   

   lehcar09

   on Oct 30, 2026

   Contributor

   More actions

   Hi @YanlongLai, thank you for reaching out and providing a detailed report.

   Currently, there's no documented startup or migration option that override a previously saved setAnalyticsCollectionEnabled(true) before Analytics starts. There's also no public-API sequence we can point to that guarantees no automatic events are recorded before a new opt-in. The setter's value persists across app launches and overrides the Manifest default until it's called again (Ref). The only documented control that outranks it is by adding the firebase_analytics_collection_deactivated in the manifest file, which is permanent for that app version so it doesn't let users opt in with the same release.

   The order you observed seems to coincide with app_update event; Analytics check for it at startup by comparing the current app version with the last version on the device. Calling setContent or setAnalyticsCollectionEnabled(false) early isn't documented to take effect before the check.

   I agree that this is a gap for Basic Consent migrations. I'll raise this to our engineers as a feature request covering a migration option and/or documentation of the limitation.

   One note on the fixture: withdrawing Analytics or Ad storage consent deletes all user properties, including ad personalization consent. If advertising choices need to stay independent, restore that value with setConsent

   👍React with 👍1Reacted by laiyanlong
5. lehcar09

   added

   type: feature requestNew feature or requestNew feature or request

   on Oct 30, 2026