[Feature Request]: Target SDK 34

[BenHenning]

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

Per https://developer.android.com/google/play/requirements/target-sdk and https://apilevels.com/ apps are required to target at least SDK 34 by 31 August 2024 in order to continue deploying using the Play Store.

Since Oppia Android is targeting SDK 33, we are blocked from releasing new versions of the app.

Describe the solution you'd like

Once #5473 is addressed, we should follow the process and document:

• The list of changes from SDK 33 to SDK 34 relevant to Oppia Android.
• What (if any) follow-up changes are needed to the app before the SDK upgrade can occur.

Then, those changes will need to be implemented and verified, then the app updated to SDK 34 and manually tested.

Describe alternatives you've considered

The upgrade to SDK 34 could happen directly, but the audit is very important to ensure no new Android functionality breaks the app (which is something I've seen happen before on other apps), and it makes sense to finish #5473 first to ensure the process of doing this is written down since we essentially need to upgrade SDK versions every year.

Additional context

#5137 demonstrates the process that was conducted for upgrading the app to target SDK 33.

[theMr17]

Known Problems

• System now supports non-linear font scaling up to 200% for accessibility. The app needs to be tested for larger font sizes.

Require Additional Verification

• All dynamically-loaded files must be marked as read-only, or the system will throw an exception. Is it a concern, considering the asset files we load?

Interest for Future Work

• Android 14 introduces partial access to photos and videos, allowing users to grant apps access to specific images and videos. This needs to be considered if we decide to switch to a different method for selecting user profile pictures.

Behavior changes: all apps

https://developer.android.com/about/versions/14/behavior-changes-all contains the high-level behavior changes in SDK 34. Items of note:

• Permission is now required to schedule exact alarms.
• The system can queue context-registered broadcasts while the app is in a cached state.
• Apps can no longer kill the background processes of other apps using killBackgroundProcesses(). This function can now only terminate the app's own processes.
• Bluetooth stack enforces an MTU (Maximum Transmission Unit) of (512 + 5) bytes for the first GATT (Generic Attribute Profile) client request.
• Move apps to the restricted standby bucket if their jobs repeatedly cause ANR errors, with tracking via the UsageStatsManager API.
• The mlock() limit is reduced from 64 MB to 64 KB per process.
• Background apps are prohibited from performing background work after entering a cached state until reactivated.
• Users can now dismiss previously non-dismissible notifications from foreground services.
• System now supports non-linear font scaling up to 200% for accessibility.
• OWNER_PACKAGE_NAME in the media store is redacted unless the storing app has a visible package name.

Behavior changes: Apps targeting Android 14 or higher

https://developer.android.com/about/versions/14/behavior-changes-14 contains the high-level behavior changes are apps targetting Android 14 or higher. Items of note:

• Apps must specify at least one foreground service type for each foreground service.
• The BLUETOOTH_CONNECT permission is now enforced for the BluetoothAdapter.getProfileConnectionState() method.
• JobScheduler enforces stricter callback behavior.
• TileService.startActivityAndCollapse() is deprecated and now throws an exception when called.
• Introduces partial acess to photos and videos, allowing users to grant apps access to specific images and videos.
• Full-screen intent notifications are restricted to apps for calling and alarms only.
• Apps must use explicit intents for unexported components.
• Apps must specify whether runtime-registered broadcast receivers are exported or not using flags.
• All dynamically-loaded files must be marked as read-only, or the system will throw an exception.
• Apps must opt in to grant background activity launch privileges when sending a PendingIntent or binding to a background service by using specific flags.
• Apps are now protected from Zip Path Traversal vulnerabilities.
• Apps requires user consent for each MediaProjection capture session.

[BenHenning]

Thanks @theMr17! My follow-up thoughts on your findings + questions:

• JobScheduler enforces stricter callback behavior.
• Apps must use explicit intents for unexported components.
• Apps must specify whether runtime-registered broadcast receivers are exported or not using flags.
• Apps must opt in to grant background activity launch privileges when sending a PendingIntent or binding to a background service by using specific flags.

All three of these could be issues if one of our (now quite old) third-party dependencies isn't set up to handle these new restrictions correctly (Firebase components especially come to mind). I think verifying that the app doesn't crash when played through & that there aren't noteworthy logcat errors on a build targeting SDK 34 should be sufficient. We can't actually verify logging behavior itself until #4751 is addressed (which is outside the scope of this issue).

• System now supports non-linear font scaling up to 200% for accessibility. The app needs to be tested for larger font sizes.

I agree that this should be tested as part of the above.

• All dynamically-loaded files must be marked as read-only, or the system will throw an exception. Is it a concern, considering the asset files we load?

What APIs exactly are affected here? We use AssetManager for all file loading except for Glide's cache (I think), though it's possible some of our dependencies perform some additional file operations.

I'm wondering if this actually has to do with Android app modules rather than data files. Was there additional documentation provided for this new requirement?

• Android 14 introduces partial access to photos and videos, allowing users to grant apps access to specific images and videos. This needs to be considered if we decide to switch to a different method for selecting user profile pictures.

If this behaves like it does on iOS (which I'm familiar with), then we actually should test this with the app's current profile selection as part of the test above to ensure that it behaves correctly. If it does, then I think there's no additional work needed (including in the future since we've effectively integrated with the feature already).

@theMr17 could you PTAL and let me know your thoughts, and provide the additional context as requested? Separately, do you have bandwidth to perform the actual build and test on a local version of the app targeting SDK 34 to verify the above? It's fine if you use an emulator to verify, though it's important to test with a Proguard-optimized version of the app (e.g. //:oppia_beta).

[theMr17]

Thanks @BenHenning for following up on this! Here’s an update on the testing and issue tracking:

I agree that this should be tested as part of the above.

Sounds good. I will create an issue to track this.

I'm wondering if this actually has to do with Android app modules rather than data files. Was there additional documentation provided for this new requirement?

It seems this is more about dynamic code loading than asset files, so we shouldn’t need to address this anytime soon. Reference: Dynamic Code Loading Changes in Android 14.

If this behaves like it does on iOS (which I'm familiar with), then we actually should test this with the app's current profile selection as part of the test above to ensure that it behaves correctly. If it does, then I think there's no additional work needed (including in the future since we've effectively integrated with the feature already).

The app's current profile image selection works correctly without any required changes, as we select the image by launching a gallery intent. The permission changes don’t affect us.

@theMr17 could you PTAL and let me know your thoughts, and provide the additional context as requested? Separately, do you have bandwidth to perform the actual build and test on a local version of the app targeting SDK 34 to verify the above? It's fine if you use an emulator to verify, though it's important to test with a Proguard-optimized version of the app (e.g. //:oppia_beta).

Yes, I can build the oppia_beta version of the app locally. I am going ahead to test the app with SDK version updated to 34. I will look into the Firebase components, keeping track of any logcat errors or crashes as they arise.

[theMr17]

Tested profile creation/deletion and login. No issues found, works fine.

[theMr17]

Playing, pausing, resuming, and finishing a lesson.

Tested, no issues found.

[BenHenning]

Thanks @theMr17! In that case, could you perhaps send your draft commit that you used to verify as a PR for performing the upgrade? It sounds like all we need to do is check that in in order to complete the SDK 34 work (and file the issue you mentioned above).

Edit: Also, just to check: did you test the beta build on an SDK 34 device/emulator?