[Feature Request]: Get app to exceed 'bad' thresholds for ANRs and crash rates

[BenHenning]

Is your feature request related to a problem? Please describe.

The Play Store sometimes will deprioritize apps in search results if they have user-perceived crashes and ANR rates that exceed predetermined thresholds by Google. The Oppia Android app currently exceeds these rates for both metrics.

Describe the solution you'd like

We need to reduce ANRs and crashes such that the app's crash threshold goes below the bad threshold. Here is the current situation:

	Current rate (Play Console)	Current rate (Firebase last 90 days)	Expected rate threshold
Crashes	2.67%	2.87%	<1.09%
ANRs	0.60%	Unknown (not captured by Firebase)	<0.47%

Describe alternatives you've considered

The alternative is not fixing these, which is actually fine while the app is in beta. However, as we approach global availability this becomes more important (especially after GA launch because then Oppia's searchability will directly relate to users' ability to find the app).

Additional context

Key crash clusters that should be fixed:

• [BUG]: Play Console warns about unspecified mutability in PendingIntents #5442 -- currently makes up ~70% of all crashes (per Firebase).
• [BUG]: cT.D - lateinit property profileId has not been initialized #5449 -- currently makes up ~10% of all crashes (per Firebase).
• [BUG]: MediaPlayer can block the main thread (cause of ANR) #5650 -- currently makes up ~53% of all ANRs (per Play Console)--note that this estimate is general for media player issues and the proposed fix in that issue is expected to fix the top 2 ANR clusters and possibly several others caused by general media player problems.

We will need to keep this issue open until we see a release that brings the rates back down. Also, if possible we should try to ensure fixes include regression tests to help prevent the crash returning in the future.

[BenHenning]

NB: making this a soft GA requirement since we will really want these fixed once we're in GA (it's not technically a blocker to prevent GA, but it could affect our ability to reach users once the app is in full production).

[TanishMoral11]

Hey @BenHenning ,

I believe that addressing this issue is very important. As you mentioned, the Play Store deprioritizes the Oppia app if the app exceeds the user-perceived crash and ANR thresholds. This can significantly affect the app's visibility and popularity.

To resolve this, my goal is to reduce the crash rate and bring it below the predetermined thresholds set by Google. Based on the current situation, I've thought of the following steps to reduce crashes and ANRs:

Planned Changes:

1. In app/src/main/java/org/oppia/android/app/application/AbstractOppiaApplication.kt:

   • Added exception handling in initializeFirebaseApp and initializeWorkManager methods to ensure exceptions are logged and handled gracefully.
   • Disabled WorkManager initialization for SDK 31+ due to compatibility issues.
   • Updated Firebase App Check initialization to use different providers for developer and production builds, ensuring better compatibility across environments.

2. In app/src/main/AndroidManifest.xml:

   • Removed WorkManagerInitializer and InitializationProvider to prevent automatic initialization of WorkManager, which is not compatible with SDK 31+.

3. In app/src/main/java/org/oppia/android/app/devoptions/RouteToViewEventLogsListener.kt:

   • Added exception handling in the routeToViewEventLogs method to log and handle exceptions effectively, improving overall stability.

4. In app/src/main/java/org/oppia/android/app/application/ApplicationComponent.kt:

   • Added exception handling in the getWorkManagerConfiguration method to log and handle exceptions gracefully, preventing unexpected crashes.

5. In app/src/main/java/org/oppia/android/app/application/ApplicationModule.kt:

   • Added exception handling in the provideWorkManagerConfiguration method to improve error handling and ensure the app runs smoothly under various conditions.

---

I believe these changes will help reduce crashes and improve the overall stability of the app. Could you please guide me on whether this approach is correct? And if possible, let me know if there are any additional measures I can take to further enhance the app's performance.

Thanks!

[adhiamboperes]

@TanishMoral11, This issue is a tracking issue for 3 sub-issues, and I believe the best approach is to actually address each of them seperately i.e. go to the linked sub issue and debug in the issue comments. That way, it is easier to track which solutions have been suggested for each respective issue.

That said, I believe your solution here is for the first sub issue.

Planned Changes:

1. In app/src/main/java/org/oppia/android/app/application/AbstractOppiaApplication.kt:

• Disabled WorkManager initialization for SDK 31+ due to compatibility issues.
• Updated Firebase App Check initialization to use different providers for developer and production builds, ensuring better compatibility across environments.

As far as I know, the above description is exactly the current implementation. Could you clarify how your proposed changes are different from current implementation?

2. In app/src/main/AndroidManifest.xml:

   • Removed WorkManagerInitializer and InitializationProvider to prevent automatic initialization of WorkManager, which is not compatible with SDK 31+.

How does this impact the current implementation? We expect WorkManager to be initialized on the app launch. Could you also clarify the incompatibility with SDK 31+?

3. In app/src/main/java/org/oppia/android/app/devoptions/RouteToViewEventLogsListener.kt:

   • Added exception handling in the routeToViewEventLogs method to log and handle exceptions effectively, improving overall stability.

This is a debug only codepath, so I am not convinced that it affects the overall app stability in production.

4. In app/src/main/java/org/oppia/android/app/application/ApplicationComponent.kt:

   • Added exception handling in the getWorkManagerConfiguration method to log and handle exceptions gracefully, preventing unexpected crashes.

ApplicationComponent.kt is an interface. Could you elaborate how exception handling is implemented here?

5. In app/src/main/java/org/oppia/android/app/application/ApplicationModule.kt:

   • Added exception handling in the provideWorkManagerConfiguration method to improve error handling and ensure the app runs smoothly under various conditions.

provideWorkManagerConfiguration is located in WorkManagerConfigurationModule, and as a dagger module, I am not sure how the exception handling should be added here.