Androidアプリの自動化では、エミュレータだけで十分なのか、実機も必要なのかという判断がよく出ます。答えはたいてい「両方」です。役割が違います。
エミュレータは、状態をリセットしやすく、APIレベルや画面サイズ、言語、向きを固定しやすいので、Flowの初期設計やビルド後のスモークチェックに向いています。待機時間、OCR対象、クリック位置、停止条件を調整する場所として扱いやすいです。
一方で、実機はリリース前の確認に必要です。メーカーUI、権限ダイアログ、カメラ、通知、USBハブ、性能モード、画面比率、実際のタッチ応答などは、エミュレータだけでは十分に見えないことがあります。
使い分け
小さなQAチームなら、次の順番が現実的です。
- まずエミュレータでルートを作る
- 待機、OCR、スクリーンショット、停止条件を調整する
- 代表的なAndroid実機で同じチェックを走らせる
- 実機を増やすのは、その端末が実際のQA判断に役立つ場合だけにする
この順番にすると、自動化そのものの不具合と、端末固有の不具合を分けやすくなります。
LaiCai Flowで見るポイント
LaiCai Flowは、Androidデバイスとエミュレータの両方で、画面上の手順を見える形で繰り返すためのワークフロー層です。スクリーンショット、OCR、ログ、停止条件を残せるので、失敗時に「どの画面で何が起きたか」をレビューしやすくなります。
関連リンク:
詳しい記事はこちらです: Android Emulator vs Device Automation with LaiCai Flow
注意点
FlowはUI Automator、Appium、Firebase Test Lab、CIの代替ではありません。人間が繰り返している短い可視チェックを、証拠付きで再現しやすくするための層です。
テストアカウント、ステージング環境、許可された端末を使い、規約回避、偽のエンゲージメント、一括メッセージ、不要な個人情報の記録には使わないようにします。