Android Support

[saikrishna321]

Is there any ETA for android support as react-native apps support both iOS and android

[rotemmiz]

No ETA yet, we are in the process of finishing and stabilizing detox for iOS. Android will follow.

[saikrishna321]

@rotemmiz any specific tool detox would depend on like espresso ?

[rotemmiz]

The plan is to use espresso, yes

[jeduden]

@rotemmiz is there a rough implementation plan ? would you consider accepting pull requests helping to get android support working faster ?

[rotemmiz]

There's a plan indeed. I think it will be best if I write a bit about our roadmap in the documentation.

In a nutshell, we want to use a similar architecture as the one we implemented on iOS:

1. use Espresso as the native driver (we'll need to figure out how to integrate with espresso, since it runs only with instrumentation context)- there's already a rough native skeleton implemented. the invocation mechanism is already implemented in react-native-invoke.
2. wrap android and adb for emulator control - like we did with fbsimctl.
3. extend Device.js to AndroidDevice and AndroidEmulator, implementing all of its functionality.
4. The hardest part will be creating a custom IdlingResource for react native bridge, like we did in iOS. Since java can't swizzle functions, we'll need to use a different approach.

[rotemmiz]

And of course, we love PRs :)

[DanielZlotin]

for future reference: I managed to make this almost work, look here

Although I gave up on this when trying to test application lifecycle, as Espresso runs as part of the app under test's process, so stopping one will stop the other.
I ended up using uiAutomator with great results

[rotemmiz]

I'm a bit afraid of trusting uiautomator , I had experience with it in MagnetoTesting, and it was flaky, we had to pet our UI tests constantly.
The problem you raised might not be an issue as the test runner in detox is external to the application and to espresso's lifecycle and resides in a different process.

[DanielZlotin]

if you look at the current tests in https://github.com/wix/react-native-navigation/tree/v2/AndroidE2E/app/src/androidTest/java/com/reactnativenavigation/e2e/androide2e you'll see there's zero flakiness, it's just a little different kind of thinking than espresso

[talarari]

also its worth noting that uiAutomator lets you interact with stuff outside the app.
so pulling down the notification curtain and such would work.

[simonracz]

Hey, I plan to work on 2. and 3. from @rotemmiz 's list.

Is anyone else working on this?

Few notes:

• android is deprecated, was split to sdkmanager and avdmanager
• platform_tools can be installed now separately, which is nice
• adb and avdmanager seems to be enough alone, they cover the current use cases

[simonracz]

Which one of the following would be preferred?

1. Call adb directly similarly to how fbsimctl is called.
2. Use adbkit for adb commands.

The 2. option adds another dependency, might not cover everything, but on the upside is already tested. I would prefer 1. at the moment, but really don't mind.

[talarari]

@rotemmiz - can you elaborate on this please?

4. The hardest part will be creating a custom IdlingResource for react native bridge, like we did in iOS. Since java can't swizzle functions, we'll need to use a different approach.

[LeoNatan]

@talarari What I did for iOS was to strategically swizzle RN methods so that I could react to what is happening for internal logic, such as starting a timer or the JS thread runloop.

Method swizzling is the process of replacing a method implementation at runtime. Since Objective C is dynamic, there is a great flexibility regarding this. Java does not allow method swizzling, so it would be much more difficult to implement a similar approach.