Target Android 12 (set targetSdkVersion to 31), by 2022-11 deadline

[gnprice]

This is the successor to #4284 (and #3665 and #3563 and #3075). We should update our targetSdkVersion to 31, meaning Android 12.

Based on the last few years' experience, Google Play will probably set a deadline for this of late 2022. It's been the first business day of November in each of the last few years.

The important steps for this upgrade are:

1. Read about the potentially-breaking changes, and identify those that might affect us.
2. Make a WIP change to targetSdkVersion.
3. Test the WIP change thoroughly, especially in the areas highlighted in step 1. Fix things as needed, and repeat.

We aren't aware of any blockers to this, so we can try doing it any time. It'd be nice to do it well before the deadline -- or at least to go far enough to learn about any unknown blockers.

[gnprice]

Well, here's one blocking issue: https://developer.android.com/about/versions/12/behavior-changes-12#notification-trampolines We'll need to replace our NotificationIntentService, which we use when you tap a notification to open it, with directly opening an Activity. (We learned about this from a lint warning in Android Studio: https://github.com/zulip/zulip-mobile/pull/5121#discussion_r747107709)

• Ideally this would be our MainActivity. We'll need to play with things somewhat to try to get the correct behavior in all three cases of the app being in the foreground, in the background, and not running. (Currently NotificationIntentService has NotifyReact.kt do this work.)
  • The main advice from Android upstream won't work for us verbatim because it assumes the canonical Android model where basically every screen in your app is a distinct activity. That structure isn't even the unanimous advice of Android upstream these days -- some of their voices say you should have one or a few activities and use Fragments for navigation instead. But in any case it's not our structure of things using RN, and we have just one activity where the app's whole UI (apart from the notifications) lives. Hence the need to play with things to find a solution.
• If we can't make that work, it should certainly be possible to make a trampoline activity, analogous to our ShareToZulipActivity. That sure won't be in the spirit of what they're going for here, though. It may also cause visible jank in the UI, like an extra transition.

[chrisbobbe]

A few items stand out in the list of breaking changes. Blank checkboxes are things we need to fix before targeting Android 12.

• I expect "Android App Links", as in "Android App Links verification changes", won't be relevant until we work on #4577. It's something you can use so that your website can also be opened by your Android app. "Verification" is a step where the device makes a request to the website and retrieves some metadata from it, for the app's sake. Until #4577, I don't think we'll have any websites that need to be verified like this. (Our zulip:// URLs, for web auth, don't point at websites.) When we work on that issue, we'll just use the updated verification protocol.

• [ ] #5171

• "App hibernation": @gnprice and I discussed this in the office, and I think we concluded that there's not a ton we can do about this? Users who leave the app untouched for a really long time will stop getting notifications. Hopefully when that happens, it'll coincide with the user not caring if they don't get notifications.

• [ ] "Safer component exporting": We'll have to put a few lines in our Android manifest XML file. That should be easy.

• [x] "Notification trampoline restrictions": That's what Greg was talking about above, in https://github.com/zulip/zulip-mobile/issues/5101#issuecomment-966039530, and it's been fixed in #5146! 🎉

• "Connectivity": I think the only thing from this (and it doesn't have to happen before we target Android 12) is that @react-native-community/netinfo should eventually stop using an Android API that's newly deprecated; I've filed https://github.com/react-native-netinfo/react-native-netinfo/issues/552 for that.