-
-
Notifications
You must be signed in to change notification settings - Fork 673
Description
Beginning on 2018-11-01 -- that's next week -- any new release we upload to the Play Store must have targetSdkVersion
set to 26 or higher.
This is a major change. It causes all systems running newer versions of Android than our previous target (22) to treat our app with a number of behavior changes introduced by the versions since then, up to the new target -- which means 6.0, 7.0, 7.1, and 8.0, aka Marshmallow, Nougat, and Oreo. That's years of changes, with known and, surely, unknown changes that affect us. Here's a concise list of just the most important changes:
https://developer.android.com/distribute/best-practices/develop/target-sdk
I committed this change to master in 53970d4, and released 19.0.100 to the alpha channel (on Android) with that change. That will help us find issues empirically. Now we need to find and fix them. 😛
UPDATE: I've released 19.1.101 to Android alpha. It fixes the critical known issue that notifications completely didn't work (#3076). More testing needed for all the "known unknown" potential issues below, as well as to spot any others!
Here's a list, which I'll keep updated, of the things we need to do:
- (@gnprice) Read through the list of high-risk changes to find likely issues.
- (@gnprice) Read through the more detailed "behavior changes" docs (this one and later) for each release to find likely issues.
- (everyone!) Play around with the
19.0.10019.1.101 alpha and look for issues. - (@gnprice, Set a channel on Android notifications (minimal, to unbreak SDK 26+) #3076) Set channels on our notifications. In 19.0.100, notifications
don'tdidn't work at all. - (filed as Test Android permissions flows, with target SDK 26+ #3576) Test permissions behavior.
- (@gnprice) Read through the permissions in our output manifest, and compare to docs to find "dangerous" permissions and other potential pitfalls.
- (-> Test Android permissions flows, with target SDK 26+ #3576) Test our use of the camera; test scenarios where the user first installs the app, we request permission, where the user then revokes permission, etc. See discussion of dangerous permissions; and more detail here and usage notes here.
- (-> Test Android permissions flows, with target SDK 26+ #3576) Test our use of the
WRITE_EXTERNAL_STORAGE
permission, similar to the camera; same docs apply. (For downloading files from the lightbox? Not 100% sure all the places this is used.) - (-> Test Android permissions flows, with target SDK 26+ #3576) Test our use of the
READ_EXTERNAL_STORAGE
permission, similar to the camera; same docs apply. (I think this applies when uploading an existing image. Not 100% sure if there are any other places.) - (-> Test Android permissions flows, with target SDK 26+ #3576) Test an install flow for any scary mentions of permissions. E.g., our manifest says we use the
SYSTEM_ALERT_WINDOW
permission. - (@gnprice) Understand our use (if any?) of
SYSTEM_ALERT_WINDOW
. Can we just remove it?- Answer: it's used by RN in debug builds, for displaying the debug menu. -> Get rid of SYSTEM_ALERT_WINDOW permission in Android manifest #3574
- (-> Test Android download/share flows, confirm no filesystem-permission issues #3577) Test downloading files, and sharing images (i.e. our
shareImage
.) There's a note aboutfile://
URLs which I think isn't an issue for downloading, but may be for our sharing; and I don't 100% understand what it's saying anyway. Some grepping findsfile://
URLs are used in several ways inrn-fetch-blob
, which in turn we use indownloadFile
, which is used in those two places. - (filed results as App restarts, and looks broken for a bit, on system display-size change #3575) Test we behave properly when the user changes their system "Display size" and/or "Font size" settings while the app is already open. See docs of a change in how the system handles this.
- (filed as Check how Android launchers that prefer square icons handle ours #3571)
(low-priority) Update to useandroid:roundIcon
. android: Add "round" icon required for SDK 26. #2993 is related. Empirically, on my device on stock Android 9, our icon with 19.0.100 shows up perfectly fine in the launcher the same as it always has, but maybe some launchers that prefer square icons will behave less well? Also the debug icon gets adjusted and looks less good, but that's a very low priority.
For later mop-up:
- (filed as Get rid of SYSTEM_ALERT_WINDOW permission in Android manifest #3574)
Remove theSYSTEM_ALERT_WINDOW
permission from the output manifest in release builds; it's only needed in debug builds, for displaying the RN debug menu.