[META] Roadmap of future Android(s)

[kelset]

Currently, the latest release of React Native (0.55.4 at the time of writing) relies on v23 of the Android ecosystem tools (buildTools, SDK, etcs), leaving a huge deal of customisation of the build.gradle files to each and every dev.

Lately Google has started notifying about how the newer versions of the OS (> 25), and the tooling, will undergo some major changes (and set some deadlines) - hence, opening an 'umbrella' issue become necessary in order to understand/coordinate which of these change will affect the repo.

Here's an extract from their announcement:

In the second half of 2018, Play will require that new apps and app updates target a recent Android API level. This will be required for new apps in August 2018, and for updates to existing apps in November 2018. This is to ensure apps are built on the latest APIs optimized for security and performance.

---

What follow is the 'most comprehensive' list of changes I managed to research & find - but of course take this with the classic "grain of salt" (and leave a comment if you see something missing).

Android 8 Oreo (API 26)

Android 8.1 Oreo (API 27)

Android 8.0 Behaviour Changes

In depth (that I think may be relevant):

• Background Execution Limits
  

• Alert windows

Android 9.0 Pie (API 28)

Android P Behaviour Changes

In depth (that I think may be relevant):

• Restrictions on non-SDK interfaces

• Screen rotation changes

Google Play Services

Beginning with version 15 of all Play services and Firebase libraries, version numbers adhere to the semantic versioning scheme. As you know, semver is an industry standard for versioning software components, so you can expect that version number changes for each library indicate the amount of change in the library.

Source: Announcing new SDK versioning in Google Play services and Firebase

Android Support Library

Today, we launch an early preview of the new Android extension libraries (AndroidX) which represents a new era for the Support Library. Please preview the change and give us your feedback. Since this is an early preview, we do not recommend trying this on any production projects as there are some known issues.

These updates will continue the 28.0.0 versioning scheme that began with 28.0.0-alpha1 in March 2018, and they will continue to be source-compatible with existing projects that depend on the android.support package.

The stable release of 28.0.0 will be the final feature release packaged as android.support. All subsequent feature releases will only be made available as androidx-packaged artifacts.

Source: Hello World, AndroidX

---

Related issues

• Android Target API Level 26 required in August 2018 pthread.h not found #2 - Android Target API Level 26 required in August 2018 #2 #18095 (fixed by android compileSdkVersion 26, use buildToolsVersion 26.0.3 #19257)
• React Native apps fail to build since NDK update to r17 (due to removed support for ARMv5/armeabi) - React Native apps fail to build since NDK update to r17 (due to removed support for ARMv5/armeabi) #19321
• RN 0.47 seems to be working fine with gradle 4.0 and compileSdkVersion / buildToolsVersion 26 - RN 0.47 seems to be working fine with gradle 4.0 and compileSdkVersion / buildToolsVersion 26 #15448
• Inverted FlatList issues - Inverted FlatList doesn't work on Android P #19434
• Removing unused permissions added at build time - [Android] Removing unused permissions added at build time #5886
• Third party 64-bit library support on Android - Support third-party 64-bit libraries on Android #2814
• Violations on android P Restrictions on non-SDK interfaces [ Important ] Violations on android P Restrictions on non-SDK interfaces #19067
• The ART <Surface> becomes invisible in Android - The ART '<Surface>' becomes invisible in Android #17565
• Android Pie: Native feedback ripples are not affected by borderRadius - TouchableNativeFeedback's ripples aren't affected by borderRadius on Android 9 #6480
• [META] Kotlin in React Native - [META] Kotlin in React Native #19991
• [META] Upgrading JSC - [META] Upgrading JSC #19737

Related PRs

• android compileSdkVersion 26, use buildToolsVersion 26.0.3 - android compileSdkVersion 26, use buildToolsVersion 26.0.3 #19257
• Update all the android related projects to target API level 27 Update all the android related projects to target API level 27 #17741

[hramos]

Thanks for compiling all of this, @kelset. Now that 0.56 has been cut and is scheduled to be released in July, we can start working on getting 0.57. This release would hit stable this August, so it's time to focus on getting API 26 support in. We should aim to have everything in place by July 1.

[MarkOSullivan94]

There's an ongoing issue with Fresco. Seems to only affect Android devices API 25 and above.

Image component inside Custom Markers and Callouts in Android not appearing or rendering.

react-native-maps/react-native-maps#1870

Can we push to have this finally fixed for 0.57.x? Not sure if any of you have contact with the Fresco team or if there can be a combined effort from both teams to implement a solution.

[kelset]

@MarkOSullivan94 I don't see how what you linked is relevant to this post, and it seems like there is already a Fresco issue related to it facebook/fresco#1445 so until that is closed I don't think there is anything that we can do on the react native side.

The purpose of this issue is to plan and discuss and let everyone know how the react-native repo will tackle upgrading to newer Android versions "overall".

[MarkOSullivan94]

@kelset apologies, I misunderstood the purpose of this. I thought it was all Android suggestions / issues for future RN releases.

I know there is already an issue related to it on Fresco but with both RN and Fresco being owned by Facebook, I would like to think there would be some communication between the teams and was hoping there could be a combined effort to fix it.

Right now there looks like it's very low priority given how the last update on the progress was this: facebook/fresco#1445 (comment)

Curious where I can post suggestions / issues I'd like to be fixed for 0.57.x such as this issue?

[kelset]

No problem - it's confusing, I know.

I know there is already an issue related to it on Fresco but with both RN and Fresco being owned by Facebook, I would like to think there would be some communication between the teams and was hoping there could be a combined effort to fix it.

Sadly it's not "that simple" (disclaimer: I don't work for fb) - the baseline for their OSS approach is to consider every project as an independent entity, because different teams are involved and they may not even be in the same continent (ex. the Metro team is in London, the RN one mostly in California).

Curious where I can post suggestions / issues I'd like to be fixed for 0.57.x such as this issue?

Well if you think about it technically every issue ideally is to be solved for the "next release", and the fact that some do and some don't is mostly related to PR being merged and tests being green. So if there are issues that you think are "more important" for you the best things to do are:

• submit PRs that fix them
• use the reactions such as 👍
• comment the open issues with extra informations that could help pin point the precise cause of said issue if it's being pinpointed yet

In "extreme scenarios" where you need some fixes urgently you can always fork the repo.

[MarkOSullivan94]

Sadly it's not "that simple" (disclaimer: I don't work for fb) - the baseline for their OSS approach is to consider every project as an independent entity, because different teams are involved and they may not even be in the same continent (ex. the Metro team is in London, the RN one mostly in California).

I guess neither of us can know the extent that their project teams communicate with each other although with them operating in different time zones, I could imagine it must be quite difficult.

Well if you think about it technically every issue ideally is to be solved for the "next release", and the fact that some do and some don't is mostly related to PR being merged and tests being green.

That is true but with every project there is features / issues which will be a higher priority (I would like to think the amount of 👍's would help influence this). It would be nice to see some of these issues / features ranked in terms of their priority or if we can help push certain issues / features to become a higher priority (what I'm wanting to do with the Fresco issue).

In "extreme scenarios" where you need some fixes urgently you can always fork the repo.

I have tried implementing a fix myself but couldn't get RN building locally: #19358

I'd love to be able to contribute eventually to the main project instead of just making documentation tweaks / improvements.