Spent some time this week attempting to get this working, with the original reasoning being that it would make it easier to review PRs that introduce Maestro tests (currently running on a physical device doesn't work, it seems). If you're using an arm-based emulator, this all works just fine (e.g. using a M-series MacBook).
Approaches to get this working:
Build the app to target x86_64 and run on x86_64 emulator
This is the most ideal option and while I didn't get it to fully work. I was able to identify an issue with the gradle build process in nmrn (see #443), but that didn't fully resolve things. I ran into a separate issue that seems related to nodejs-mobile:
node:internal/modules/cjs/loader:1340
return process.dlopen(module, path.toNamespacedPath(filename));
^
Error: dlopen failed: cannot locate symbol "napi_get_cb_info" referenced by "/data/data/com.comapeo.dev/files/nodejs-project/node_modules/sodium-native/build/Release/sodium.node"...
at Module._extensions..node (node:internal/modules/cjs/loader:1340:18)
at Module.load (node:internal/modules/cjs/loader:1119:32)
at Module._load (node:internal/modules/cjs/loader:960:12)
at Module.require (node:internal/modules/cjs/loader:1143:19)
at require (node:internal/modules/cjs/helpers:121:18)
at load (file:///data/data/com.comapeo.dev/files/nodejs-project/index.js:45241:11)
at file:///data/data/com.comapeo.dev/files/nodejs-project/index.js:45438:20
at ModuleJob.run (node:internal/modules/esm/module_job:194:25) {
code: 'ERR_DLOPEN_FAILED'
}
Node.js v18.17.1
I stopped pursuing this once I got here. Probably worth creating an issue in nodejs-mobile in case anyone in the community has an idea of what the error entails.
Build the app to target arm64 and run on x86_64 emulator
Gregor brought to my attention that if the emulator you've created is using >= Android 11, you can run arm-targeting apks on an intel emulator (source). while I didn't get this to fully work, but I learned that in order for this new emulator feature to work properly, I needed to explicitly filtered out intel targets for the ndk by specifying ndkFilter in the app build.gradle. I ran into an issue that gave the following error:
com.facebook.soloader.SoLoaderDSONotFoundError: couldn't find DSO to load: libfbjni.so
In general, I consider this a nice-to-have and so I don't expect this to be resolved anytime soon, but it's worth documenting all of this in case we need to get this working at some point.
Spent some time this week attempting to get this working, with the original reasoning being that it would make it easier to review PRs that introduce Maestro tests (currently running on a physical device doesn't work, it seems). If you're using an arm-based emulator, this all works just fine (e.g. using a M-series MacBook).
Approaches to get this working:
Build the app to target x86_64 and run on x86_64 emulator
This is the most ideal option and while I didn't get it to fully work. I was able to identify an issue with the gradle build process in nmrn (see #443), but that didn't fully resolve things. I ran into a separate issue that seems related to nodejs-mobile:
I stopped pursuing this once I got here. Probably worth creating an issue in nodejs-mobile in case anyone in the community has an idea of what the error entails.
Build the app to target arm64 and run on x86_64 emulator
Gregor brought to my attention that if the emulator you've created is using >= Android 11, you can run arm-targeting apks on an intel emulator (source). while I didn't get this to fully work, but I learned that in order for this new emulator feature to work properly, I needed to explicitly filtered out intel targets for the ndk by specifying
ndkFilterin the app build.gradle. I ran into an issue that gave the following error:Was able to get past this error by enabling legacy packaging for jni libs (see https://developer.android.com/build/releases/past-releases/agp-4-2-0-release-notes#compress-native-libs-dsl). However, I ran into a cryptic issue around ndk translation, and decided to stop there.
In general, I consider this a nice-to-have and so I don't expect this to be resolved anytime soon, but it's worth documenting all of this in case we need to get this working at some point.