AI & TechnologyFirebase Test Lab Shutting Down: Alternatives for 2027

Firebase Test Lab will be fully shut down on September 30, 2027, and Google's named replacement is the Developer Device Platform on Google Cloud. The platform's gcloud beta device-run command supports Android instrumentation and iOS XCTest in preview, so any release pipeline that runs tests on Test Lab needs a plan before that date.

The facts below come from Firebase, Google Cloud, Flutter and Android documentation, as shown in the sources. I checked each one on October 18, 2026. Google can change a date, so open the linked page before you plan around it.

Disclosure: App369 is my studio. I build and fix Flutter and Firebase apps, and the last section mentions what I sell. Google doesn't pay me for anything on this page.

The dated timeline

I found no earlier dated change on these pages than the shutdown itself. The one dated change before it is the pricing change after April 30, 2027.

For the other Firebase retirements, see my Firebase deprecations table.

What stops, and what doesn't

The Test Lab page says: "Firebase Test Lab is deprecated and will be fully shut down on September 30, 2027." It adds that, to maintain your testing workflows, you can migrate to the Developer Device Platform on Google Cloud.

The migration FAQ is blunter. It says "Yes, you won't be able to run any workflows after September 30, 2027." So the Firebase console and API go with it, and so do any gcloud or CI jobs that call them.

Firebase's migration page gives the practical reason to move early: "To prevent CI/CD interruptions, transition to the Developer Device Platform before the shut down date."

Android Device Streaming is a separate case. The migration page says it is not being deprecated and describes it as a core feature of the Developer Device Platform.

How teams use Test Lab today

Firebase describes three steps. You prepare a test, define a test matrix of devices, OS versions, locales and orientations, then run it and review results in the Firebase console. The test types on the Test Lab page are:

• Android instrumentation tests
• Robo tests on Android, which run without a pre-written test
• Game Loop tests on iOS and Android
• XCTest on iOS

You can start runs from the Firebase console, the gcloud CLI, Android Studio or a CI system. These are the commands Firebase's own pages show.

Android instrumentation:

gcloud firebase test android run \
  --type instrumentation \
  --app app-debug-unaligned.apk \
  --test app-debug-test-unaligned.apk \
  --device model=Nexus6,version=21,locale=en,orientation=portrait

The Android page says --type robo is the default when no type is given, and that --type instrumentation is implied when you pass a test APK with --test.

iOS XCTest:

gcloud firebase test ios run --test PATH/TO/MyTests.zip \
 --device model=MODEL_ID_1,version=VERSION_ID_1,locale=LOCALE_1,orientation=ORIENTATION_1

For CI, Firebase's continuous integration page walks through Jenkins and links to Bitrise and CircleCI docs for other systems. It says to create a service account with an Editor role and activate it, and to enable the Google Cloud Testing API and the Cloud Tool Results API. Every one of those pipelines calls gcloud firebase test, which is why the shutdown is a pipeline change and not just a console change.

What Google names as the replacement

Google names one replacement, and one feature that continues. I am listing only what Firebase's pages name.

The Developer Device Platform

Firebase's migration FAQ lists these offerings:

• Device Run: runs tests on devices in its lab, with results in the Google Cloud console.
• Device Streaming API: connects to remote physical Android devices.
• Agent skills: help AI coding agents find, reserve and interact with devices.
• Device Catalog: lets you find, sort and explore devices.

Three facts from the pages matter before you commit:

• The platform is in preview. Firebase says that means Google's Pre-GA Offerings Terms apply and support might be limited.
• It requires billing to be enabled. The FAQ notes that Test Lab "supported some usage without billing."
• After April 30, 2027, the FAQ says pricing combines pay-per-use and per-device slot subscription options. The pricing page describes a pay-per-minute plan and sends you to Google for current rates.

Android Device Streaming in Android Studio

The Android Developers page says it "lets you securely connect to remote physical Android devices hosted in Google's secure data centers and Android Partner Device Labs." The page says it is free to try on the Spark plan, and that usage beyond the monthly no-cost minutes may incur billing. It needs Editor or Owner permission on the Firebase project, or specific IAM roles. This is a way to try an app on a device from Android Studio. It is not a replacement for a CI test run, and Google does not present it as one.

My advice: treat the Developer Device Platform as the replacement for your pipeline, and Android Device Streaming as something you keep for hands-on device checks.

What the new command supports

Google's migration guide describes gcloud beta device-run as an enhancement to the gcloud firebase test CLI. It labels it a preview offering that is available "as is" and might have limited support. The supported test types it lists are Android instrumentation and iOS XCTest.

The command mapping:

The guide writes the iOS command with alpha and the Android one with beta. Confirm which track applies on the day you run it.

Google's translation page changes flags too. A few examples from its tables:

• --app becomes --apps, and --additional-apks is merged into it.
• --device model=M,version=V becomes --device=M-V.
• --timeout becomes --instrumentation-timeout on Android and --xctest-timeout on iOS.
• --results-bucket becomes --bucket-name.
• --client-details becomes --labels.
• --num-flaky-test-attempts R becomes --flaky-test-attempts A, where A is R plus 1 (Android; the iOS flag takes a direct count).

The guide lists several behavior differences from Test Lab:

• Retries run only the failing test cases, where Test Lab retries the whole shard.
• Android instrumentation runs with only a test APK.
• The per-shard limit is 3 hours, up from Test Lab's 45 minutes.
• The Device Catalog has server-side filtering and real-time availability.

Google also offers two ways to convert your scripts: a manual route using the translation tables, and an AI-assisted route using a migration skill file with a coding agent. The guide names Antigravity, Claude Code and Codex. If you use an agent, read its output against the translation table before you merge it.

What the pages do not cover

The translation page says nothing about Robo tests or Game Loop tests, and the migration guide lists only instrumentation and XCTest as supported types. If you run Robo or Game Loop tests on Test Lab, these pages document no replacement for them. The migration page links a support contact, or you can plan to rebuild those checks as instrumentation tests.

The FAQ also says the platform does not work with VPC Service Controls, and that Google can't commit to supporting Appium, Flutter/FlutterDriver, React Native/Jest or Cucumber, though some are on its roadmap.

What it means for Flutter integration tests

Flutter's integration testing page has dedicated Test Lab sections for Android and iOS. Its Android steps build an APK with Gradle, then use the Instrumentation test type. The integration_test README shows the same flow with these commands:

gcloud firebase test android run --type instrumentation \
  --app build/app/outputs/apk/debug/app-debug.apk \
  --test build/app/outputs/apk/androidTest/debug/app-debug-androidTest.apk \
  --timeout 2m \
  --results-bucket=<RESULTS_BUCKET> \
  --results-dir=<RESULTS_DIRECTORY>

For iOS, it uploads a zip with gcloud firebase test ios run --test "build/ios_integ/Build/Products/ios_tests.zip" and a --device flag.

Here is what Google's pages imply for those steps.

1. The test types overlap. Flutter's Test Lab flow uses Android instrumentation and an iOS XCTest zip, and those are the two types the platform lists in preview. Google does not say that Flutter integration_test runs on the platform, and I haven't tested it.
2. --results-dir has no equivalent. Google's translation table marks it unsupported and says sub-paths are organized automatically in Cloud Storage under automation/sessions/{session_id}/. If your pipeline reads results from a fixed folder, change that step.
3. --timeout and --results-bucket are renamed. Use --instrumentation-timeout and --bucket-name on Android.
4. Flutter's pages still point at Test Lab. The Flutter page and README have no deprecation note that I saw, so they will tell you to do things Google's own notice says will stop.
5. Flutter/FlutterDriver support isn't committed. The platform FAQ says some frameworks are on the roadmap but it can't commit to them. For Android it says apps built with a framework that supports Espresso (for example, Flutter) can run an Espresso instrumentation test.

My advice: copy your current Test Lab step into a branch, translate it with Google's table, and run it against a small test before you touch your main pipeline.

A short plan

1. Find every use. Search your repos, CI settings and scripts for gcloud firebase test. Check the Firebase console for Test Lab matrices as well.
2. Write down the test types. Instrumentation and XCTest have a documented path. Robo and Game Loop don't.
3. Enable billing on the Google Cloud project you will use. The platform requires it.
4. Translate one job with the flag table and run it in preview, in a branch, while your Test Lab job stays in place.
5. Compare cost. Matching pricing ends after April 30, 2027, so check Google's current rates before you decide on volume.
6. Cut over only after the new job passes in CI. Keep Test Lab until then. My advice: finish well before September 30, 2027, so a broken flag doesn't stall a release.

For every other dated Apple, Google Play and Firebase requirement in 2026 and 2027, see App Store and Google Play deadlines for 2026 and 2027.

Need a hand?

If your release pipeline runs tests on Firebase Test Lab and you want it moved before the shutdown, the App Fix Ticket covers it in two fixed-price steps. A $450 Diagnosis gives you the root cause with evidence and a fixed repair quote within 3 business days, credited toward the fix. If you go ahead, the $1,200 Fix takes 5 business days and comes as a pull request. Or send me a short description.