Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Target Android 13 (set targetSdkVersion to 33), by 2023-10 deadline #5453

Closed
gnprice opened this issue Jul 27, 2022 · 7 comments · Fixed by #5749 or #5761
Closed

Target Android 13 (set targetSdkVersion to 33), by 2023-10 deadline #5453

gnprice opened this issue Jul 27, 2022 · 7 comments · Fixed by #5749 or #5761

Comments

@gnprice
Copy link
Member

gnprice commented Jul 27, 2022

This is the successor to #5101 (and an annual series of previous issues linked there.) We should update our targetSdkVersion to 33, meaning Android 13.

Based on past experience, Google will probably set a deadline for this of late 2023. 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. Last time around, we did it nearly a year in advance (in #5174), and that was great.

@gnprice
Copy link
Member Author

gnprice commented Jul 27, 2022

Here's one task we'll do as part of this upgrade, in the Play Console. I don't think any of the other work for the upgrade needs to block on it; just noting it here so we have the information handy when it comes up.

You must complete the advertising ID declaration before you can release an app that targets Android 13 (API 33). We'll use this declaration to provide safeguards in Play Console to accommodate changes to advertising ID in Android 13.

Apps targeting Android 13 or above and use advertising ID must include the com.google.android.gms.permission.AD_ID permission in the manifest.

That's a warning I get when I make a release in the Play Console today.

It doesn't seem to appear in the list of changes linked above, which I guess is because it's purely about the behavior of the Play Console and not about the behavior of the OS itself.

We do not use any kind of "advertising ID", so I expect that declaration should be easy to fill out.

@chrisbobbe chrisbobbe changed the title Target Android 13 (set targetSdkVersion to 33), by 2023-11 deadline Target Android 13 (set targetSdkVersion to 33), by 2023-08-30 deadline Aug 18, 2023
@chrisbobbe
Copy link
Contributor

The deadline is in fact 2023-08-30, not early November as we had predicted. However, they do let you request an extension until November 1: https://support.google.com/googleplay/android-developer/answer/11926878

image

@gnprice
Copy link
Member Author

gnprice commented Aug 22, 2023

We do not use any kind of "advertising ID", so I expect that declaration should be easy to fill out.

I've now filled this declaration out. It was nice and to the point ­— a single yes/no question.

@gnprice
Copy link
Member Author

gnprice commented Aug 22, 2023

Reading through that list of potentially-breaking changes, the things I notice are:

  • "Granular media permissions": @chrisbobbe flagged this on Friday. It's confusingly explained, but I believe the upshot is that we would need to declare those permissions if we were still using the "scoped storage" API that Android 10 introduced for this use case… but happily we've already switched, on Android 13, to using that version's spiffy new photo picker, which puts the user completely in control of what media the app sees (by having the system present a nice UI for the user to make the choice in, rather than leaving the app to provide that UI) and makes such permissions unnecessary.

    And empirically I've tested android: Update targetSdkVersion to 33 (Android 13) #5749 in this respect and it works great.

    This is one place where we'd have run into an obstacle if we'd tried to take this update super early; we got the use of the Android 13 photo picker with react-native-image-picker v4.9.0, released 2022-11, which I guess we took in android/deps: compileSdkVersion to 33 (Android 13); image-picker to 4.10.2 #5618 in 2022-12. Though that's still fairly early in the cycle — so good work r-n-image-picker contributors in being on top of it.

  • "App color theme applied automatically to WebView content": Not sure offhand if this could affect anything for us, but will want to check.

  • "Permission required for advertising ID"… Huh, I remarked above (in 2022-07) that this didn't seem to be on this page.

    And indeed, the Wayback Machine confirms that it wasn't there as of 2022-08-01. Nor was the WebView theme thing.

    Browsing history a bit, the page gained those by 2022-08-12. At that point there were still a couple of significant differences from today's version, notably in what it said about the "Granular media permissions" change and how to handle it. By 2022-09-27 it was substantially the same as today, though some tweaks in that latter section were still to come.

    So I guess that's another point in favor of not rushing to handle these updates too early — better to wait until at least September, to let them settle on what the story is.

    Anyway, as concerns this "advertising ID" item itself: as discussed above, we don't use any such thing, so we don't need to touch anything in the app on this point, and I've now filled out the form in the Play Console to the same effect.

@gnprice
Copy link
Member Author

gnprice commented Sep 1, 2023

Reopening because we had to revert this change. Quoting @chrisbobbe from #5752:

From a user report, we found that we now have to handle a new runtime permission for notifications, and the consequence of not doing so is that notifications stop working on Android 13. Ouch; that would have been good to see mentioned in the "behavior changes" doc: https://developer.android.com/about/versions/13/behavior-changes-13#notification-permission-fgs-appearance

Discussion (starting with the user report): https://chat.zulip.org/#narrow/stream/48-mobile/topic/.22This.20app.20does.20not.20send.20notifications.22/near/1634168

I've filed #5753 for discussion of the notifications permission specifically.

@gnprice
Copy link
Member Author

gnprice commented Sep 1, 2023

Also our new deadline is 2023-10-31, so two months from now, after I requested that extension mentioned above. (Not sure why the discrepancy where it said November 1 then; but it's telling me October 31 now.)

@gnprice gnprice changed the title Target Android 13 (set targetSdkVersion to 33), by 2023-08-30 deadline Target Android 13 (set targetSdkVersion to 33), by 2023-10 deadline Sep 1, 2023
chrisbobbe referenced this issue Sep 13, 2023
…sion

We bumped this to 33 in 6f44474 / v27.210, but then reverted it in
2e196e4 because of #5753, "Use the new POST_NOTIFICATIONS runtime
permission on Android".

Bump it again, this time with a fix for that issue: we declare the
new permission and add a runtime function call to request it in
context.

For users, this means:

- If on iOS: No change.

- If below Android 13: No change. A permission request follows the
  creation of a notification channel, so effectively it happens on
  app startup:
    https://developer.android.com/develop/ui/views/notifications/notification-permission#new-apps

- For a new app install on Android 13, the permission will now be
  requested in context instead of at startup:
    https://developer.android.com/develop/ui/views/notifications/notification-permission#new-apps

- For existing app installations when Android is upgraded to 13 or
  later, the permission should automatically be granted without a
  prompt as long as notifications hadn't been explicitly disabled
  before the upgrade. This should still work across a "backup and
  restore":
    https://developer.android.com/develop/ui/views/notifications/notification-permission#existing-apps
  (However: we are tracking #5484 as an unrelated cause of
  notifications breaking across a "backup and restore".)

If RN and Android decide it's helpful, a "rationale" is shown to the
user just before the new in-context permission request. That's a
modal showing a message we provide (see added code), with an OK
button to close the modal and proceed to Android's plain Yes/No
dialog for the permission request.

Fixes: #5753
@chrisbobbe
Copy link
Contributor

Closing, belatedly, as fixed by #5761.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants