If teams continue treating Android testing infrastructure as a fixed, human-provisioned resource, that model becomes harder to justify as test matrices grow and release cadences tighten. In a new post on its official blog, Canonical argues for a different pattern: on-demand Android validation environments created, used, and disposed of as ordinary pipeline stages — ephemeral rather than permanent.
This is the third instalment in a series. The first covered automation — how Android environments can be created and managed programmatically. The second examined scaling, using shared infrastructure to make those environments available to more developers, tests, and workloads. The third piece focuses on integration: wiring these environments directly into CI/CD so that each commit triggers a complete, repeatable validation run.
Reproducibility is the core payoff
According to Canonical, the central engineering benefit of this pattern is reproducibility. Each test run starts from an identical initial state, unaffected by data, accounts, or partial installs left over from previous runs. Test failures can therefore be reproduced under accurate, consistent conditions rather than depending on the accident of the moment.
Closely related is evidence preservation: after a run finishes, the relevant logs and artifacts can be captured and retained for post-hoc analysis. This matters especially in CI/CD settings, where failures often occur when no developer is on site — without a reliable snapshot of the original conditions, debugging can otherwise devolve into guesswork.
Virtualised versus containerised environments
The article also distinguishes between containerised and virtualised Android environments. The two approaches trade off against each other on startup speed, resource consumption, and isolation strength, and the piece includes practical details such as ADB connection setup for teams evaluating workloads. Android Automotive OS is cited as an example, showing that this type of environment can cover in-vehicle validation scenarios beyond conventional mobile application testing.
The approach itself is built on Anbox Cloud, Canonical's own product, and the post is written squarely in the context of that platform. Teams adopting different container platforms or CI systems can borrow the workflow thinking, but the concrete mechanics of environment provisioning will differ by platform.
Physical hardware is not replaced
Notably, the post does not package on-demand environments as a cure-all. Its broader strategy is more balanced: advancing validation into the pipeline wherever possible — running every change, rather than gating only at release boundaries — while acknowledging that certain categories of testing still depend on physical hardware that cannot be faithfully simulated.
This means teams evaluating the model need to focus on the boundary line — which tests can move into the pipeline, and which must remain on physical devices — rather than treating on-demand environments as wholesale replacements for existing device farms.
By its nature, the post is a hybrid of technical argument and product promotion rather than independent engineering advice. Canonical uses its own platform as the vehicle for explaining the benefits of on-demand Android environments as a pipeline feature; the principles around reproducibility and evidence preservation, however, are worth borrowing in any CI/CD discussion. Whether to adopt them remains contingent on each team's testing mix, physical-device requirements, and release frequency.
如果團隊繼續把 Android 測試基礎設施視為一套由人工配置、固定不變的資源，隨著測試矩陣不斷擴大、發佈節奏日益緊迫，這種模式會越來越難以站得住腳。Canonical 最近在其官方部落格發文，提出另一種模式：把 Android 驗證環境做成隨需建立、使用、並按一般 pipeline 階段流程銷毀——即棄式而非永久性。
這是系列的第三篇文章。第一篇談自動化：如何以程式化方式建立和管理 Android 環境；第二篇談規模化：如何透過共享基礎設施，讓這些環境可供更多開發者、測試和工作負載取用。第三篇聚焦整合：把這些環境直接接入 CI/CD，使每次提交都能觸發一套完整、可重複的驗證流程。
可重複性是核心收益
按 Canonical 的說法，這種模式最重要的工程收益在於可重複性。每次測試執行都從完全相同的初始狀態開始，不受前一次執行殘留的資料、帳號或未完成安裝的影響。因此，測試失敗可以按照準確、一致的條件重新產生，而不必依賴當時的巧合情況。
與此密切相關的是證據保存：執行結束後，相關的 log 和 artifact 可以被擷取並保留，供事後分析。這一點在 CI/CD 環境中尤其重要——失敗往往發生在開發者不在場的時候，若沒有可靠的原始情況快照，除錯就只能淪為猜測。
虛擬化環境與容器化環境的取捨
文章亦區分了容器化與虛擬化的 Android 環境。兩種方式在啟動速度、資源消耗和隔離強度上各有取捨，文中並附上 ADB 連線設定等實務細節，供團隊按自身工作負載作評估。Android Automotive OS 被列為例子，說明這類環境同樣可以涵蓋車載系統的驗證場景，不限於傳統手機應用程式測試。
整套方案建立在 Anbox Cloud 之上——這是 Canonical 自家的產品，文章亦是以該平台為語境撰寫的。採用其他容器平台或 CI 系統的團隊，可以借鏡其中的流程思路，但環境配置的具體機制會因平台而異。
實體硬件並非可被取代
值得留意的是，這篇文章並沒有把隨需環境包裝成萬靈丹。它在這方面的整體策略更為平衡：盡可能把驗證推進 pipeline——對每一次變更都執行，而不是只在發佈邊界設卡；同時承認某些類別的測試仍然依賴實體硬件，而這些測試無法被準確地模擬。
這意味著，團隊在評估這種模式時，需要把重心放在分界線上——哪些測試可以移交 pipeline、哪些必須保留於實體裝置——而不是把隨需環境視為現有裝置農場（device farm）的整體替代。
就其性質而言，這篇文章是技術論述與產品推廣的混合體，而非獨立的工程建議。Canonical 以自家平台作為說明隨需 Android 環境作為 pipeline 功能好處的載體；不過，其中關於可重複性和證據保存的原則，在任何 CI/CD 討論中都值得借鏡。是否採納，仍然取決於各團隊自身的測試組合、實體裝置需求和發佈頻率。