[Android] Expo SDK 46 local EAS build is slow

[raajnadar]

With bare or managed workflow

Version - eas-cli/2.1.0 darwin-x64 node-v16.17.0

Why is Expo SDK 46 forcing me to download NDK? Even when I am not using the new arch?

Checking the license for package NDK (Side by side) 21.4.7075529 in /Users/{username}/Library/Android/sdk/licenses License for package NDK (Side by side) 21.4.7075529 accepted. Preparing “Install NDK (Side by side) 21.4.7075529 (revision: 21.4.7075529)”.

Can we use the latest version instead of the 21.4.7075529?

Is there any way to make it faster? This issue is with local eas builds

I can give more information if required…

[brents]

can you share a link to your build?

[raajnadar]

It is a local build using eas-cli on my mac os monteray

eas build --platform android --local

[brents]

expo/expo/blob/dec397fdc746a4cb632a714620e8574eac9c258d/templates/expo-template-bare-minimum/android/build.gradle#L7-L22

you can change this if you want. it is identical to the react-native template: react-native/build.gradle at 2fc44ac8e144b7d93e1ccc95163dd33c94d2a197 · facebook/react-native · GitHub

[raajnadar]

This cmd is very slow due to the following process

:expo-modules-core:downloadBoost > boost_1_76_0.tar.gz > 8.80 MB/124.24 MB do

When I used the ./gradlew bundleRelease cmd I can see the same thing, the above process is slow and is downloaded for each build. And it is the reason for the eas local build to be slow. In EAS the process is stuck at and no UI changes so it was not visible, but gradlew cmd I can see this.

where can I find resources why is that slow to download or why it is downloading for each build it should be cached?

For the NDK version can we use the version above 21.4.7075529 for the Intel chip? Any idea?

These are dependencies in the project

"@react-native-community/datetimepicker": "6.2.0",
"@react-navigation/material-top-tabs": "^6.2.2",
"@react-navigation/native": "^6.0.11",
"@react-navigation/stack": "^6.2.2",
"axios": "^0.27.2",
"base-64": "^1.0.0",
"date-fns": "^2.29.1",
"expo": "^46.0.10",
"expo-barcode-scanner": "~11.4.0",
"expo-build-properties": "~0.3.0",
"expo-file-system": "~14.1.0",
"expo-intent-launcher": "~10.3.0",
"expo-print": "~11.3.0",
"expo-status-bar": "~1.4.0",
"expo-updates": "~0.14.5",
"react": "18.0.0",
"react-native": "0.69.5",
"react-native-gesture-handler": "~2.5.0",
"react-native-pager-view": "5.4.24",
"react-native-paper": "^4.12.4",
"react-native-safe-area-context": "4.3.1",
"react-native-screens": "~3.15.0",
"react-native-tab-view": "^3.1.1"

[brents]

hey there. you may be better off asking such questions on discord or searching through react-native issues, as this is not specific to expo itself.

[brents]

also - here’s a pr where we have done some work to improve the state of downloading boost multiple times: [core] Added `REACT_NATIVE_DOWNLOADS_DIR` environment variable support by Kudo · Pull Request #19015 · expo/expo · GitHub - we have also made related changes in react-native

[raajnadar]

@brents

[core] Added REACT_NATIVE_DOWNLOADS_DIR environment variable support by Kudo · Pull Request #19015 · expo/expo · GitHub

Tried asking on discord, but no one answered, Discord

[raajnadar]

I think this will be available in the next SDK. Can we use this with SDK 46?

[brents]

you can do anything you want, the source is all open! we can’t provide guidance on how to do this though

[wodin]

Hi @raajnadar

You should be able to apply the patch to node_modules/expo-modules-core/android/build.gradle with patch-package

[raajnadar]

Hey, I have no issue to wait and get the change from the expo modules core npm package itself

I find it easier to stick to the managed flow.

Just to find out if it is due to EAS cli or the vanilla react native I ran expo prebuild and ran ./gradlew bundleRelease to get the verbose build log to find out the slow build process, in eas there is no verbose log, it just gets stuck with no indicator

[wodin]

@raajnadar

I find it easier to stick to the managed flow.

Sure, I understand, but if you’re using eas build or eas build --local then you can use patch-package in the managed workflow. Depending on exactly what you’re patching, you might need to be more careful with OTA updates. But this particular change should be completely safe, since it just changes the way the download happens rather than the actual code.