* This is a huge update, mostly because we updated Gradle on the Android side, which includes a more strict bundle process for third party modules. On iOS, even though new architecture is disabled, we had to be explicit about it because of this react native update and because some updated dependencies have it enabled by default and are using turbo modules which are not available, YET, in our project.
Should fix this error:
~~~
Fatal Exception: java.lang.IllegalArgumentException: org.jitsi.meet: Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.
Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles.
at android.app.PendingIntent.checkFlags(PendingIntent.java:402)
at android.app.PendingIntent.getActivityAsUser(PendingIntent.java:485)
at android.app.PendingIntent.getActivity(PendingIntent.java:471)
at android.app.PendingIntent.getActivity(PendingIntent.java:435)
at com.google.android.gms.common.GoogleApiAvailabilityLight.getErrorResolutionPendingIntent(com.google.android.gms:play-services-basement@@17.5.0:25)
at com.google.android.gms.common.GoogleApiAvailabilityLight.getErrorResolutionPendingIntent(com.google.android.gms:play-services-basement@@17.5.0:21)
at com.google.android.gms.common.GoogleApiAvailability.getErrorResolutionPendingIntent(com.google.android.gms:play-services-base@@17.5.0:170)
at com.google.android.gms.common.GoogleApiAvailability.getErrorResolutionPendingIntent(com.google.android.gms:play-services-base@@17.5.0:173)
at com.google.android.gms.common.GoogleApiAvailability.zaa(com.google.android.gms:play-services-base@@17.5.0:112)
at com.google.android.gms.common.api.internal.GoogleApiManager.zaa(com.google.android.gms:play-services-base@@17.5.0:252)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.zaa(com.google.android.gms:play-services-base@@17.5.0:109)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.onConnectionFailed(com.google.android.gms:play-services-base@@17.5.0:75)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.zai(com.google.android.gms:play-services-base@@17.5.0:263)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.zaa(com.google.android.gms:play-services-base@@17.5.0:133)
at com.google.android.gms.common.api.internal.GoogleApiManager.handleMessage(com.google.android.gms:play-services-base@@17.5.0:164)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loopOnce(Looper.java:240)
at android.os.Looper.loop(Looper.java:351)
at android.os.HandlerThread.run(HandlerThread.java:67)
~~~
Fix for this crash:
~~~
Fatal Exception: java.lang.IllegalArgumentException: org.jitsi.meet: Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.
Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles.
at android.app.PendingIntent.checkFlags(PendingIntent.java:377)
at android.app.PendingIntent.getActivityAsUser(PendingIntent.java:460)
at android.app.PendingIntent.getActivity(PendingIntent.java:446)
at android.app.PendingIntent.getActivity(PendingIntent.java:410)
at com.google.android.gms.common.GoogleApiAvailabilityLight.getErrorResolutionPendingIntent(GoogleApiAvailabilityLight.java:25)
at com.google.android.gms.common.GoogleApiAvailabilityLight.getErrorResolutionPendingIntent(GoogleApiAvailabilityLight.java:21)
at com.google.android.gms.common.GoogleApiAvailability.getErrorResolutionPendingIntent(GoogleApiAvailability.java:97)
at com.google.android.gms.common.GoogleApiAvailability.getErrorResolutionPendingIntent(GoogleApiAvailability.java:100)
at com.google.android.gms.common.GoogleApiAvailability.zaa(GoogleApiAvailability.java:41)
at com.google.android.gms.common.api.internal.GoogleApiManager.zac(GoogleApiManager.java:214)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.onConnectionFailed(GoogleApiManager.java:86)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.connect(GoogleApiManager.java:219)
at com.google.android.gms.common.api.internal.GoogleApiManager$zaa.zaa(GoogleApiManager.java:112)
at com.google.android.gms.common.api.internal.GoogleApiManager.handleMessage(GoogleApiManager.java:145)
at android.os.Handler.dispatchMessage(Handler.java:107)
at com.google.android.gms.internal.base.zap.dispatchMessage(zap.java:8)
at android.os.Looper.loopOnce(Looper.java:238)
at android.os.Looper.loop(Looper.java:357)
at android.os.HandlerThread.run(HandlerThread.java:67)
~~~
Looks like the "Firebase Analytics" dependency is needed when migrating to the
new Firebase Crashlytics SDK. We are only interested in the "latest iversion
crash-free users" stat, which seems to require this. The documentartion is
somewhat confusing though.
It's a number whichb must be ever increasing with each build submitted to the
store.
Automate its value by using the number of seconds since 1st of January 2019.
That should be enough for ~680 years.
When running the app from Android Studio the React packager is not automatically
started. In vanilla RN projects this is done by the "react-native run-android"
command, but often times it is desired to run from Android Studio.
This fixes that by starting the packager from Gradle.
This is done at the app level, not the SDK.
Currently 2 Firebase services are used:
- Crashlytics
- Dynamic Links
They are enabled in tandem, if the appropriate Google services file
(GoogleService-Info.plist on iOS or google-services.json on Android) is found.
Each service needs to be individually enabled in the Firebase console.
Glide (which is used by react-native-fast-image) can cause trouble if the host
app (the one using the SDK) is using Glide already.
To avoid this, don't use the builtin AppGlideModule (as the docs recommend) and
let apps define it.
Set them to the next release versions. In additon, the buildNumber variable will
be used to match the requirements of versionCode:
https://developer.android.com/studio/publish/versioning
that is, a monotonically increasing number, independent of the app / sdk
version.
