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

Open
kelset opened this Issue May 16, 2018 · 24 comments

Comments

Projects
None yet
8 participants
@kelset
Collaborator

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

  • Android Target API Level 26 required in August 2018 #2 - #18095 (fixed by #19257)
  • 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 - #15448
  • Removing unused permissions added at build time - #5886
  • Third party 64-bit library support on Android - #2814
  • Violations on android P Restrictions on non-SDK interfaces #19067
  • Inverted FlatList issues - #19434
  • The ART <Surface> becomes invisible in Android - #17565
  • Android Pie: Native feedback ripples are not affected by borderRadius - #6480
  • [META] Kotlin in React Native - #19991
  • [META] Upgrading JSC - #19737

Related PRs

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

@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 and Gradle configuration
* 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 hramos referenced this issue Jun 12, 2018

Closed

0.56.x Discussion #14

@hramos

This comment has been minimized.

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

This comment has been minimized.

MarkOSullivan94 commented Jun 12, 2018

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-community/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

This comment has been minimized.

Collaborator

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

This comment has been minimized.

MarkOSullivan94 commented Jun 13, 2018

@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

This comment has been minimized.

Collaborator

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

This comment has been minimized.

MarkOSullivan94 commented Jun 13, 2018

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

This comment has been minimized.

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

This comment has been minimized.

Collaborator

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

This comment has been minimized.

Contributor

hramos commented Jun 13, 2018

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

@dulmandakh

This comment has been minimized.

Collaborator

dulmandakh commented Jun 13, 2018

PR for gradle plugin 2.3.3, gradle 3.5.1 #19697

@willbattel

This comment has been minimized.

willbattel commented Jun 13, 2018

@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

This comment has been minimized.

Collaborator

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

This comment has been minimized.

willbattel commented Jun 14, 2018

@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

This comment has been minimized.

Collaborator

dulmandakh commented Jun 14, 2018

@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

This comment has been minimized.

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 was marked as off-topic.

noktigula commented Jun 15, 2018

Is there any plans about upgrading minSdk?

@kelset kelset changed the title from Roadmap of future Android(s) [Umbrella issue] to [META] Roadmap of future Android(s) Jun 15, 2018

@dulmandakh

This comment has been minimized.

Collaborator

dulmandakh commented Jul 4, 2018

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

@dulmandakh

This comment has been minimized.

Collaborator

dulmandakh commented Jul 17, 2018

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.

@dulmandakh

This comment has been minimized.

Collaborator

dulmandakh commented Jul 28, 2018

This PR bumps Android NDK to latest version available #20357, which is the latest version to include GCC and GNU STL.

@dulmandakh

This comment has been minimized.

Collaborator

dulmandakh commented Aug 8, 2018

Android NDK r17b or latest version is landed with 6117a6c.

@dulmandakh

This comment has been minimized.

Collaborator

dulmandakh commented Aug 14, 2018

A PR to bump SDK to 28 #20585, and another PR to bump support library to 27.1.1 #20586

@gengjiawen

This comment has been minimized.

Collaborator

gengjiawen commented Aug 21, 2018

For #2814 , maybe merge my pr #18754 first. @hramos

@gengjiawen

This comment has been minimized.

Collaborator

gengjiawen commented Aug 21, 2018

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

@AndrewJack

This comment has been minimized.

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:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment