{
  "id": 12336066,
  "title": "Run Android Tests on Real Phones in GitHub Actions",
  "url": "https://urgent.news/2026/10/06/run-android-tests-on-real-phones-in-github-actions",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-06T08:27:35.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/cloudfone/run-android-tests-on-real-phones-in-github-actions-3777"
  },
  "original_language": "en",
  "account": "Running Android tests on real devices through GitHub Actions is essential when your app relies on hardware-specific behavior or sensor checks. Emulators can only provide limited assurance, and a green pipeline in such scenarios may not be meaningful. The author has set up a rack of real Android phones in Singapore, accessible via adb from a hosted runner.\n\nThe workflow begins with setting up the job in a repository. The workflow triggers on push or pull request events and runs on Ubuntu. The steps include checking out the code, setting up Android, building the debug APK, connecting to the device, installing the app, running tests, and disconnecting from the device. The connect step retries up to five times if the connection fails initially. The disconnect step ensures the device is properly released after each test run.\n\nThe key points to note are the use of secrets for the Android Debug Bridge (adb) endpoint and any related tokens, keeping the sensitive information out of the workflow file and logs. The connect step uses a loop to handle potential network issues, and the disconnect step is always executed, regardless of test outcomes, to ensure proper cleanup.\n\nOne common issue in CI environments is the mismatch between the adb server version on the runner and the phone. Using the `setup-android` action helps ensure you have the latest platform-tools. Another issue is signature errors during installation, which can be resolved by uninstalling the previous build before installing the new one.\n\nTests may also hang or time out due to default adb timeouts optimized for cable connections rather than network hops. Increasing the timeouts can help mitigate this problem. Additionally, when multiple pull requests trigger simultaneously, they might compete for the same phone, causing state corruption. Using a concurrency group for device jobs helps prevent this issue by queuing the jobs instead of allowing them to collide.\n\nIf multiple phones are required, the process can be scaled using a matrix strategy. Each phone gets its own secret, and the workflow can be configured to run jobs for each phone's endpoint in parallel. This approach allows running tests on various devices simultaneously, providing a more comprehensive testing experience.",
  "summary": "Emulators in CI are fine until your app cares about being on a real device. Once a sensor check or hardware-specific behaviour enters the picture, a green pipeline stops meaning much. I run a rack of real Android phones in Singapore that people drive over adb, and this came out of running it. Here is the workflow I'd start from, including the parts that fail quietly the first time you try it on a…",
  "key_points": [
    "Run Android tests on real devices in GitHub Actions for hardware-specific behavior.",
    "Set up a rack of real Android phones in Singapore accessible via adb from a hosted runner.",
    "Use secrets for adb endpoint and tokens, employ setup-android action for latest platform-tools."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}