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

[META] Roadmap of future Android(s) #19297

Closed
6 of 13 tasks
kelset opened this issue May 16, 2018 · 35 comments
Closed
6 of 13 tasks

[META] Roadmap of future Android(s) #19297

kelset opened this issue May 16, 2018 · 35 comments
Assignees
Labels
Contributor A React Native contributor. 📮Known Issues This indicates an issue that refers to a bug or limitation of RN that is not currently being handled Partner Platform: Android Android applications. Ran Commands One of our bots successfully processed a command. Resolution: Locked This issue was locked by the bot. Type: Discussion Long running discussion.

Comments

@kelset
Copy link
Contributor

kelset commented May 16, 2018

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):

Android 9.0 Pie (API 28)

Android P Behaviour Changes

In depth (that I think may be relevant):

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

Related PRs

@kelset kelset added Type: Discussion Long running discussion. Core Team Platform: Android Android applications. Ran Commands One of our bots successfully processed a command. labels May 16, 2018
@hramos hramos self-assigned this May 16, 2018
samuel-h-r-nunes added a commit to team-r3/r3 that referenced this issue May 17, 2018
* Updated packages:
  * react: ^16.3.2 (was ^16.3.0-alpha.1)
  * react-native: ^0.54.4 (was ^0.54.4)
  * native-base: "^2.4.4 (was ^2.4.2)
  * redux: ^4.0.0 (was ^3.7.2)
  * react-test-renderer: ^16.3.2 (was 16.3.0-alpha.3)
  * NOTE: I read the update notes and these should be safe changes,
    including "redux", which got a major version update.

* Gradle-related changes:
  * Changed the way how the SDK is defined in the Gradle configuration:
    Now this is configured globally in `/android/build.gradle`, which
    gets rid of the version warnings.
  * Updated Gradle to version 4.4 (was 4.1).
  * Updated the Gradle plugin to version 3.1 (was 3.0.1).

INSTALLATION STEPS:
===================
rm package-lock.json
rm node_modules
npm install --no-optional  // (NOTE: "--no-optional" needed on Windows)

TROUBLESHOOTING:
================
* If there are any errors like "could not delete folder x", remove those
  folders manually, e.g.:
    rm C:\r3\android\app\build\intermediates\incremental\processDebugResources
    rm C:\r3\android\app\build\generated\source\r\debug\org\webkit

* If there are errors like "unable to create folder x", try again. It
  should work on the second time.

READ
====
* Main motivation:
  * We should have an SDK version which is at least v26, since that will
    be the minimum to be accepted in the Play store after August 2018:
      facebook/react-native#17287
      facebook/react-native#19297
  * Regarding Gradle, the latest versions are required to build for the
    lastest SDKs, but will also increase compilation time a lot:
      facebook/react-native#15448

* React Native Maps installation and Gradle upgrade instructions:
    https://itnext.io/install-react-native-maps-with-gradle-3-on-android-44f91a70a395

* Migration instructions for the Android Gradle Plugin v3.0.0:
    https://developer.android.com/studio/build/gradle-plugin-3-0-0-migration

* List of versions of the Android Gradle Plugin and upgrade steps:
    https://developer.android.com/studio/releases/gradle-plugin
@hramos
Copy link
Contributor

hramos commented Jun 12, 2018

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
Copy link

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
Copy link
Contributor Author

kelset commented Jun 13, 2018

@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
Copy link

@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
Copy link
Contributor Author

kelset commented Jun 13, 2018

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
Copy link

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
Copy link
Contributor

hramos commented Jun 13, 2018

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
Copy link
Contributor

dulmandakh commented Jun 13, 2018

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
Copy link
Contributor

hramos commented Jun 13, 2018

@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
Copy link
Contributor

PR for gradle plugin 2.3.3, gradle 3.5.1 #19697

@willbattel
Copy link

@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
Copy link
Contributor

dulmandakh commented Jun 14, 2018

@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
Copy link

@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
Copy link
Contributor

@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
Copy link
Contributor

hramos commented Jun 14, 2018

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.

@noktigula

This comment has been minimized.

@kelset kelset changed the title Roadmap of future Android(s) [Umbrella issue] [META] Roadmap of future Android(s) Jun 15, 2018
@dulmandakh
Copy link
Contributor

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

@dulmandakh
Copy link
Contributor

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
Copy link
Contributor

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

@AndrewJack
Copy link
Contributor

AndrewJack commented Sep 18, 2018

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>
  1. 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>
  1. 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:

@ferrannp
Copy link
Contributor

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
Copy link
Contributor

AndroidX migration proposal - #23112

@hramos hramos added Partner Contributor A React Native contributor. and removed Core Team labels Mar 8, 2019
@iremlopsum
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

dulmandakh commented Mar 12, 2019 via email

@scottmas
Copy link

scottmas commented Mar 12, 2019

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
Copy link

scottmas commented Mar 14, 2019

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
Copy link

JCMais commented Mar 15, 2019

@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
Copy link
Contributor Author

kelset commented Mar 18, 2019

@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
Copy link
Contributor

cpojer commented Mar 19, 2019

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.

@cpojer cpojer closed this as completed Mar 19, 2019
@facebook facebook locked as resolved and limited conversation to collaborators Mar 19, 2020
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Mar 19, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Contributor A React Native contributor. 📮Known Issues This indicates an issue that refers to a bug or limitation of RN that is not currently being handled Partner Platform: Android Android applications. Ran Commands One of our bots successfully processed a command. Resolution: Locked This issue was locked by the bot. Type: Discussion Long running discussion.
Projects
None yet
Development

No branches or pull requests