[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.

[hramos]

We're on track for getting Android API 26 support ready for 0.57. @dulmandakh just landed 065c5b6 which bumps the Android build tools to v26.0.2 and uses SDK 26 to compile the Android project. I want to call this out as a great example of a long running issue (this was first brought up to our attention over six months ago) that was resolved by a member of the community through a PR.

I would like to get feedback here in this issue on what people think needs to be done to consider the next release "Android API 26 ready". Can we move the collaboration discussion above elsewhere? It does not belong in this issue. We have a Discuss forum that is better suited for it.

[dulmandakh]

To make next release "Android API 26 ready" we need to make target SDK 26.

My plan was to compile July release with SDK 26 then target SDK 26 in August release (just in time) to make transition to SDK 26 smoother and to see if there are issues to address. Therefore, I would like to ask to land 065c5b6 in July release, so we have time to test, fix bugs and maybe land SDK 26 features like custom fonts, better emoji support etc.

[hramos]

@dulmandakh can you comment on react-native-community/releases#14? We're tracking cherry-picks on that issue. I can take care of getting this onto 0.56.

[dulmandakh]

PR for gradle plugin 2.3.3, gradle 3.5.1 #19697

[willbattel]

@dulmandakh Why is the new Android target API 26 and not 27? Buildtools 26.X.X is already considered outdated by Gradle Android Plugin 3.X.X. Seems weird to me that you're only targeting the minimum required by Google, as opposed to the recommended version.

If you keep it at 26, all projects will continue to get WARNING: The specified Android SDK Build Tools version (26.0.2) is ignored, as it is below the minimum supported version (27.0.3) for Android Gradle Plugin 3.1.3. Android SDK Build Tools 27.0.3 will be used.

[dulmandakh]

@wbattel4607 I find it less disruptive way to satisfy Play Store requirements, because there are many developers and even more apps use React Native. IIRC, gradle plugin 3.x requires change in dependency definition and an aapt2 issue, etc...

[willbattel]

@dulmandakh that's fair, but many RN users have already made the switch to gradle plugin 3, especially given that many popular packages have migrated and require it, such as react-native-maps, react-native-firebase, etc...

The recommended practice is to target the latest API level when possible. Can you at least add documentation for how RN projects can gracefully upgrade from API 26 to the latest? I just find it strange that you're making the upgrade, but not to the recommended version.

[dulmandakh]

@wbattel4607 for my personal project I use SDK 27, and I find some issues with many packages. Also it's tiresome to create a project with old tools then update, deal with various issues. That was the motivation to create this PR.

I hope that core developers will adopt recommended practice as soon as possible. Maybe @wbattel4607 you can create a PR to target SDK 27.

[hramos]

React Native had been using the Android 23 SDK and 23.0.1 build tools for quite a long time, so it's expected any changes here will be done incrementally. The main goal is to comply with the minimum requirements in time for the Play Store requirements this August, i.e. build with and target SDK 26.

PRs that move us closer to recommended versions, as opposed to the bare minimum, while keeping tests green, are very welcome.

[dulmandakh]

Here is the PR to bump Android SDK to 27. Need help #20026

[dulmandakh]

I think that we need to focus more on upgrading NDK to land 64bit support and newer JSC. I downloaded and tried to compile RN with every version of NDK and r14b was the latest version that managed to compile RN with minimal code changes. Then, I created a PR #19893 and would like to ask for reviews.

[gengjiawen]

For andriod gradle 3.x support, related pr: #20767.

[AndrewJack]

Another one for the list: Cleartext traffic is not permitted for apps targeting android 9

If your app targets Android 9 or higher, the isCleartextTrafficPermitted() method returns false by default.

All react native apps (that target Android 9) will need the below config to debug with react native.

To use react native in debug mode when targeting API Level 28:

1. Create a file in android/app/src/main/res/xml/network_security_config.xml
2. Copy this:

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <debug-overrides>
        <trust-anchors>
            <certificates src="system" />
            <certificates src="user" />
        </trust-anchors>
    </debug-overrides>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
</network-security-config>

3. Create a file in android/app/src/debug/res/xml/network_security_config.xml

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="true">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
</network-security-config>

5. Add this line to the <application in AndroidManifest.xml -> android:networkSecurityConfig="@xml/network_security_config"

This config should be customised for each app. The above is for the generic case.

I'll have a bit more of a test and submit a PR to make this "just work" in the template.

Read more:

• https://developer.android.com/about/versions/pie/android-9.0-changes-28#framework-security-changes
• https://developer.android.com/training/articles/security-config#network-security-config

[ferrannp]

Finally I was able to put together code + issue on another big problem starting on Android P: Elevation does not animate when it is inside a view which animates its opacity (Android P).

This affects libraries such as react-navigation.

cc @kelset

[dulmandakh]

AndroidX migration proposal - #23112

[iremlopsum]

Finally I was able to put together code + issue on another big problem starting on Android P: Elevation does not animate when it is inside a view which animates its opacity (Android P).

This affects libraries such as react-navigation.

cc @kelset

Is there any update regarding this? I tried to look into it with my limited Native Android knowledge, but couldn't figure anything out.

This bug makes it really complicated to build nice transitions without building weird (pseudo-)DOM structures

[ferrannp]

Android Pie: Native feedback ripples are not affected by borderRadius - #6480

FYI the workaround in this comment works #6480 (comment). We already use it in react-native-paper. Not sure though if it can cause some unexpected behavior (haven't seen them).

[scottmas]

App startup is a huge Android issue IMO. On my tests, on iOS a completely bare production build app becomes interactive in 200ms, while on Android the time is closer to 650ms.

[dulmandakh]

Please test with 0.59, which includes a new JavaScript engine and has 64bit support.

[scottmas]

It is slightly improved on RN 59.0, averaging about 500ms, sometimes up to 600ms if its a completely cold start. Here are some more details:

On iOS I start the timer in AppDelegate.m

extern CFAbsoluteTime StartTime;

@implementation AppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{

  //Let's us print console.log() on production
  RCTSetLogThreshold(RCTLogLevelInfo - 1);

  NSDictionary *props = @{@"starttime" : @(StartTime)};

  RCTBridge *bridge = [[RCTBridge alloc] initWithDelegate:self launchOptions:launchOptions];
  RCTRootView *rootView = [[RCTRootView alloc] initWithBridge:bridge
                                                   moduleName:@"testapp"
                                            initialProperties:props];
  //Additional stuff...
}

On Android I start the timer in MainActivity.java inside getLaunchOptions:

public class MainActivity extends ReactActivity {

    private long starttime = System.currentTimeMillis();

    @Override
    protected ReactActivityDelegate createReactActivityDelegate() {
      return new ReactActivityDelegate(this, getMainComponentName()) {
        @Override
        protected Bundle getLaunchOptions() {
          Bundle initialProperties = new Bundle();

          initialProperties.putSerializable("starttime", starttime);
          return initialProperties;
        }
      };
    }
    //Additional stuff...
}

I end the timer on both platforms with the first onLayout callback for my topmost view. App.js looks as follows:

export default class App extends React.Component{

  getStarttime() {
    const { starttime } = this.props;
    //Convert CFAbsoluteTime to unix timestamp on ios...
    return Platform.OS === 'ios'
      ? Math.round(starttime * 1000 + 978307200000)
      : starttime;
  }

  logTimeToInteractive = () => {
    console.info(
      `${Date.now() -
        this.getStarttime()} ms to application paint`,
    );
  };

  render() {
    return (
      <View style={styles.container} onLayout={this.logTimeToInteractive}>
        <Text>Test</Text>
      </View>
    );
  }
}

The phones I used to generate these numbers are both relatively underpowered:
iOS - iPhone SE with latest OS
Android - Huawei Honor 7x with 3GB RAM and Kirin 659 CPU running Android 8.0

It would be interesting to see these startup time metrics on a broader cross section of devices.

[scottmas]

RN Core members, should I move this to a new thread? This thread seems like it may be more focused on build tooling and the like.

[JCMais]

@scottmas it's probably a good idea to have a separated issue to track that, since it's an important factor for RN adoption

[kelset]

@scottmas - if I understand correctly, you are talking about app startup time.

This is one of the main pain point that Fabric & TurboModules are tackling with the new architecture, so maybe we can have an issue called like "App start up time with RN" where we keep track of those average times / explain the benchmarking procedure and we use that as a reference to post new benchmarks when new versions of RN come out? 🤔

[cpojer]

JSC now supports 64-bit as of 0.59 and we just landed the AndroidX migration on master which should make it either into 0.60 or 0.61. I think it's fine to close this issue but if this is other stuff that is mainly focused on a discussion, we can move this to the discussion and proposals repo.