Which device‑cloud providers support real cellular connectivity for OTP delivery, and how can I integrate them?

Device‑cloud providers that give you real cellular connectivity (so OTPs sent to a virtual number actually arrive on the device)

| Provider | How cellular is provided | Typical integration points | Notes | |----------|--------------------------|----------------------------|-------| | AWS Device Farm | Real Android phones and iOS devices connected to carrier networks (SIM slots). | • Upload your APK/IPA<br>• Create a “Remote Access” session or a “Test” run<br>• Use the AWS SDK or Appium scripts to interact with the device | You can script the whole OTP flow; the device receives the SMS just like a physical phone. | | Google Firebase Test Lab (formerly Cloud Test Lab) | Uses physical devices on Google’s test farms that have carrier SIMs. | • Use gcloud firebase test android run with your app bundle<br>• Add UI‑Automator or Espresso tests that read the incoming SMS via SmsManager | Works best for automated UI tests; you can also launch a remote session to view the SMS in the device logs. | | Microsoft App Center Test | Real devices on Microsoft’s farm, many with active cellular connections. | • Upload your app and test scripts (Appium, Espresso, XCUITest)<br>• Run a “Device Set” test that includes devices with SIM support | Provides detailed logs, video, and device screenshots that include the SMS notification. | | Sauce Labs Real Device Cloud | Physical Android devices equipped with carrier SIMs (LTE/3G). | • Use Sauce’s REST API or Selenium/Appium bindings<br>• Request a device with mobileDevice capability realDevice:true | You can retrieve the SMS from the device log or via the on‑screen notification. | | BrowserStack App Automate | Real Android phones with carrier connectivity (SIM enabled). | • Upload your app, write Appium/Espresso scripts<br>• Set device capability to a model that supports cellular | Offers a “Live” view where you can see the SMS pop‑up in real time. | | Kobiton | Physical devices with active SIM cards; some plans include a “cellular bundle”. | • Upload the app and run Appium/Espresso scripts<br>• Use kobiton:deviceName capability to pick a cellular‑enabled device | Provides a “Device Console” where you can view SMS notifications and logs. |

How to integrate them into your OTP‑testing workflow

1. Choose the provider that matches your stack

• If you already use AWS services, AWS Device Farm is the easiest to integrate (IAM roles, S3 buckets, etc.).
• If you prefer Google‑centric tooling, go with Firebase Test Lab.

2. Set up an account & obtain API credentials

• Create a user/API key in the provider’s console.
• Store the key securely (e.g., in your CI secret store).

3. Select a device with cellular support

• Most consoles let you filter by “Carrier”, “SIM”, or “Cellular”.
• Reserve a device model that matches the Android version you need.

4. Upload your app & test scripts

• Use the provider’s CLI (aws devicefarm, gcloud firebase test android run, saucectl, etc.) or UI.
• Write your test to trigger the OTP request in the app.

5. Capture the OTP

• Option A – Read the SMS via Android APIs

     SmsMessage[] msgs = Telephony.Sms.Intents.getMessagesFromIntent(intent);
     String otp = msgs[0].getMessageBody(); // parse the code
     

• Option B – Pull the device log
• After the OTP is received, fetch the device log (adb logcat equivalent via the provider’s API) and extract the code with a regex.
• Option C – Use the on‑screen notification
• Some providers expose a screenshot/video frame; you can OCR the OTP from the notification.

6. Validate & continue the test

• Feed the extracted OTP back into the app (e.g., via UI Automator setText).
• Assert that the login/verification succeeded.

7. Integrate into CI/CD

• Add the test command to your pipeline (GitHub Actions, GitLab CI, Jenkins, etc.).
• On each PR or build, the pipeline spins up a real device, runs the OTP flow, and reports success/failure.

Quick starter snippets

AWS Device Farm (CLI)

aws devicefarm create-project --name MyOTPProject
aws devicefarm upload-apk --project-arn $PROJECT_ARN --name MyApp.apk --type ANDROID_APP
aws devicefarm schedule-run \
    --project-arn $PROJECT_ARN \
    --app-arn $APP_ARN \
    --device-pool-arn $POOL_WITH_CELLULAR \
    --name "OTP Test Run" \
    --test type=APPIUM_NODE,testPackageArn=$TEST_PACKAGE_ARN

Firebase Test Lab (gcloud)

gcloud firebase test android run \
  --type instrumentation \
  --app app-debug.apk \
  --test app-debug-androidTest.apk \
  --device model=Pixel4,version=13,locale=en,orientation=portrait

Sauce Labs (Appium)

caps = {
  "platformName": "Android",
  "deviceName": "Google Pixel 5",
  "app": "sauce-storage:myApp.apk",
  "realDevice": "true",
  "sauce:options": {
      "username": SAUCE_USER,
      "accessKey": SAUCE_KEY
  }
}
driver = webdriver.Remote("https://ondemand.saucelabs.com/wd/hub", caps)

---

Bottom line: Genymotion itself can’t receive real OTPs because it lacks carrier‑level SMS, but the providers above give you genuine cellular connectivity so your virtual‑number workflow will work. Pick the one that fits your existing toolchain, set up the device pool with cellular‑enabled phones, and integrate the test scripts via their CLI or API. 🚀

If you need a deeper dive into any specific provider’s setup (e.g., exact capability JSON for Appium, CI pipeline example, or pricing guidance), just let me know!