| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
fix(app): local-dev Firebase placeholders must be format-valid, not just fake (#11594) Firebase's native SDK format-validates GOOGLE_APP_ID and API_KEY at Firebase.initializeApp() time, before any network call and before Auth is routed to the local emulator — so a syntactically invalid placeholder crashes the app on launch even though the values are never meant to reach a real backend. Measured on iPhone 17 Pro / iOS 27.0 while verifying an unrelated iOS UIScene fix: a dev-flavor build using the local-harness placeholder configs crashed with `'Configuration fails. It may be caused by an invalid GOOGLE_APP_ID...'`, then (after fixing that) with `API Key length must be 39 characters, API Key must start with 'A'`. GOOGLE_APP_ID was "1:000000000000:ios:omi-dev-local" (a human-readable string where Firebase expects a hex-like token) and API_KEY was "local-firebase-auth-emulator-api-key" (37 chars, doesn't start with 'A'). Both are now syntactically valid-looking but still fake — no real Firebase project is reachable with them, matching the existing IS_ANALYTICS_ENABLED=false / IS_GCM_ENABLED=false posture of this placeholder config. Fixed in all three sources that describe this same fake identity: the iOS plist, the Android json, and the Dart FirebaseOptions consts — main.dart selects the Dart consts explicitly for OMI_APP_PROFILE=local_dev, but the crash traced to native Firebase plugin registration reading the bundled plist even earlier, before Dart's main() runs, so both had to change. Also patches BUNDLE_ID in the copied plist to track the per-hostname-suffixed APP_BUNDLE_IDENTIFIER dev builds already get (generate_ios_custom_config), since the placeholder's static BUNDLE_ID never matched it. This one turned out not to be the actual crash trigger — Firebase's error message named the wrong field — but it's still a real mismatch and cheap to fix alongside it. Failure-Class: none | 27 天前 | |
harden(app): fail fast on mobile build profile drift (#12559) | 10 天前 |