Android: Split (google) emulators across different adb servers

[d4vidi]

Description

• This pull request addresses the issue described here: #<?>

This pull request aims to greatly increase stability in Android (google) emulator devices in a multi-devices environment. It addresses the following problem (no issue reported so I'm writing it here) -

Problem

With local emulators being shifted back into the main focus, we've recently started noticing on numerous environments (local, CI) that with Detox running over more than 1 emulator concurrently, the ADB server gets "lost". Namely it often cannot handle concurrently executed ADB commands, thus resulting in frequent ADB command failures. This phenomenon has become more noticeable with the recent introduction of the automated device status-bar configuration feature.

Solution

The ADB ↔ emulator framework supports multiple ADB servers and so this PR introduces a shift to an architecture by which each dispatched emulator gets its own ADB server, listening on a dedicated port.

Initializing an ADB server with a port can be done using either the -P <port> argument or the ANDROID_ADB_SERVER_PORT env var.

Starting up an emulator while specifying a custom ADB server port can be done strictly via the ANDROID_ADB_SERVER_PORT env var.

This solution prefers the -P arg when possible - since it's more verbose, but otherwise resorts to the env-var. This takes into account the fact emulator allocation is performed by the primary context - which is fundamentally a single process, and the runtime execution of tests commands is performed by worker - each running in its own process.

Debts

• Strict port allocation. For now, we work inside the open-range starting from the default ADB server port (5037) + 1 (i.e. 5038). We implicitly assume the 5037+ ports are either free or strictly used by adb servers.
• Apply this technique to Geny-cloud and attached (real) Android devices?
  Note: Didn't do this because I haven't looked into whether there exists a (clean?) way to connect those devices onto specific servers (i.e. specify the port).
• Protect using a dedicated "toggle" since this has breaking potential (in some envs)

---

For features/enhancements:

• I have added/updated the relevant references in the documentation files.

For API changes:

• I have made the necessary changes in the types index file.

[noomorph]

What's the guarantee that the port is taken by an ADB server actually?

[noomorph]

Can't we just enumerate ports from adbPortRegistry?

[noomorph]

Do you check that it is actually free?

[noomorph]

I feel a bit uneasy about this change. That process.env.* mutation to enable third party reporters – I see where you are coming from, but it is, to say the least, very puzzling situation... The tradeoff is real - one worker = one device at time, but yes, we can allow to accumulate a bit more tech debt. I'm more puzzled that after 4-5 years of using Android emulators outside gmsaas we never caught issues like that... if the flakiness appears specifically near device allocation (status bar tweaks), did you double check that there's no way something else is missing?

Overall, the PR is straightforward enough - you augmented device cookie, now you use also adb server port. The port allocation seems fishy to me in the current implementation - on CI scale, the risk is high enough that something will occupy presumably an ADB'ish port, and are you well equipped to handle this case? 🤔

The port allocation logic seems to be suspicious enough that I'd ask you to stop and look, please. 🙏

[d4vidi]

@noomorph thanks for the review! I'd rather we talk in person but in any case here is where I was coming from with this solution:

• Yes indeed, the port allocation solution is as naive as it gets. Nevertheless, we've always run under the assumption that port 5037 is free and there were no issues with that; As a matter of fact, this port is used not just by detox users, but by any Android / react-native developer out there that has ever run an emulator. So this puts that assumption on the very safe side IMO. That is why I was hesitant to try to introduce a more robust soltuion (but applied of a protection toggle nonetheless).
• That said, the alternatives I did have in mind are in these 2 directions:
  • Random port
  • Scanning for free ports within a constant range (e.g. 5038-5067 - thus also implicitly limiting the amount of concurrent adb servers)
• process.env -- well, I'm not overly fond of it myself but I didn't have a better idea. I'm not sure it's that bad.