“Install Error(-10)” Got You Stuck? The Hidden Trick to Beat Google Play’s Pre-launch Test

 

🤔 Why the “App Not Owned” Error Happens

If your app fails the Google Play Pre-launch Test with this scary message —

u9.a: -10: Install Error(-10): The app is not owned by any user on this device.
An app is "owned" if it has been acquired from Play.

— you’re not alone.

This happens because the Pre-launch Test runs on Google’s own test devices, which aren’t linked to your Play account or purchase history.
So, if your app uses Play Core libraries (like AppUpdateManager or AppReviewManager), the “ownership check” fails, and your app never even gets installed.

It’s one of those bugs that make you scream: “But it works fine on my phone!” 😩

 

🤔 The Secret Fix Google Never Told You

Here’s the insider trick that devs have quietly been using:


Settings.System.getString(context.contentResolver, "firebase.test.lab")

This line reveals whether your app is currently running inside Firebase Test Lab — the same environment used for Pre-launch Tests.
If the value is "true", you’re in a test device.
That means you can safely skip anything that requires Play services or user ownership checks.

Here’s how to use it:


val isTestLab = Settings.System.getString(context.contentResolver, "firebase.test.lab") == "true"
if (!isTestLab) {
    // Run Play Core logic only in real user environments
}

Boom. 💣
No more random -10 install errors.
Your Pre-launch Test will finally pass like a charm.

 

⚡ Summary

The “Install Error(-10)” is not a bug in your code — it’s a Play Console quirk.
By detecting the Test Lab environment with:


Settings.System.getString(context.contentResolver, "firebase.test.lab")

you can bypass Play-related ownership checks and let your app install smoothly during the Pre-launch Test.

A single line of code could be the difference between “Test failed 🚫” and “Release ready ✅” — now that’s a win worth sharing.

👉 Firebase Test Lab × リリース前レポート環境を見分けるKotlin実装


IDE × AIモデル別:プロンプトに食わせるべきファイルまとめ

主要IDEごとに、連携AI・推奨ファイル・目的・補足を整理した表です。プログラミング中心にまとめています。

1. 基本のセット

  • プロジェクト概要・設計
    README.md, architecture.md
    AIに全体像・設計方針・責務を理解させる
  • 依存・環境情報
    build.gradle(.kts), package.json, Podfile, .env.example
    SDK・ライブラリ・環境変数を正確に認識させる
  • コーディング方針・ルール
    .prompt.yaml, .copilot-instructions.md, .editorconfig
    命名規則、禁止API、コードスタイルを統一

2. IDE × AIモデル別の推奨ファイルと効果

IDE 推奨AIモデル 重点ファイル 効果 補足
Android Studio / IntelliJ Gemini Code Assist, Copilot .prompt.yaml, build.gradle, architecture.md Androidプロジェクト全体を理解した補完・設計提案 プロジェクト全体の構造を解析可能。方針ファイルで安定化。
Xcode Copilot, GPT-5 .prompt.yaml, Package.swift, README.md SwiftUI/MVVM設計に沿った正確なコード生成 Xcodeは依存解析が弱めなので .prompt.yaml を明示すると効果大。
VS Code Copilot Chat, GPT-5 .copilot-instructions.md, package.json, README.md 軽量環境で多言語対応、チーム開発の方針共有に有効 拡張機能単位でAI切替可能。指示ファイルが最重要。
Cursor / Windsurf / Aider GPT-5 / Claude 3.5 / Gemini 1.5 .prompt.yaml / .cursorconfig, README.md, architecture.md, build設定 設計・生成・リファクタを自動で分担 ファイル単位でAIが文脈キャッシュを保持。設計書参照可。
Jupyter / DataSpell / VSCode + Python GPT-4 Turbo, Gemini Advanced .ipynb / .csv / .xlsx, analysis.md / README.md, .prompt.yaml データ解析・統計・グラフ生成 データ+分析目的+出力形式を渡すと的確に解析可能。
Figma / Webflow / Framer Gemini 1.5 Pro (Vision), GPT-5 Vision .fig / .svg / layout.json, style_reference.jpg, .prompt.yaml UIデザイン→コード変換・スタイル抽出 構図+目的+出力フォーマット指定でSwiftUIやComposeコード化が容易。

3. 実務での運用Tips

  • サンプルコードを渡す
    /sample_code に小さな動作例を置くと、AIが文体やパターンを模倣しやすい
  • 変更履歴を渡す
    CHANGELOG.md や feature_list.md を読むことで、過去の修正意図を理解し、安全な提案が可能
  • 大きなファイルは要約して渡す
    設計書や長文ドキュメントは、AIの文脈理解の負荷を減らすために必要部分だけ渡す
  • 依存関係やAPI仕様は明示
    未定義関数や古いAPIの誤提案を防ぐため、build.gradle や .env.example を食わせる

4. まとめ

プログラミングAIを「単なるコード補完」ではなく、プロジェクト理解型のアシスタントとして活用するには、

「概要 + 環境 + 方針」をAIに与えることが最も重要です。

  • IDEや言語に合わせたファイルを食わせる
  • 設計方針と依存関係を明確化する
  • サンプルコードや履歴で文脈を補完する

この3ステップで、AIは理解に基づいたコード生成・設計提案を行い、開発効率と品質を大幅に向上させられます。


結局は Android Studio の AI は Gemini に収束するのか - Ultimately, does Android Studio's AI end up relying on Gemini?

 

🤔 ChatGPT の回答

Gemini が主力

・ Android Studio の AI 開発支援として Google が推進中
・ コード生成・補完・UI → コード変換・クラッシュ解析など対応

“完全収束”ではない

・ 他の AI プラグインや補助ツールも併用可能
・ Gemini が唯一の選択肢になるとは断言できない

ポイント

・ Android 開発では Gemini が中心になる傾向
・ 企業や個人のニーズ次第で別のツール併用もあり

 

🤔 GitHub Copilot の回答

・ 公式AIはGeminiへ移行(Studio Bot → Gemini in Android Studio)

・ 他AIプラグイン(Copilot/JetBrains AI等)は併用可

・ 企業向けはGemini Code Assist等でガバナンス・送信制御に対応

・ 結論:公式はGemini中心、チーム事情で使い分け可能

 

🤔 Gemini の回答

・ Android StudioのAIは、現在「Gemini in Android Studio」です。

・ Googleの最新AIモデル「Gemini」(Gemini 1.5 Pro)が基盤です。

・ GoogleのAI技術がGeminiに収束・統合されている流れの一環です。

 

🤔 まとめ

公式AIはGeminiに収束、ただし併用も可能

公式AIは「Gemini」が主力

・ Android Studioに標準搭載されるAI(旧Studio Bot)は、現在「Gemini in Android Studio」となり、Googleの最新AI (Gemini 1.5 Pro) が基盤となっています。
・ これは、Googleが自社AI技術をGeminiに収束・統合している大きな流れの一環です。

“完全な収束”ではない(併用が可能)

・ Geminiが公式AIである一方、それが「唯一の選択肢」になるわけではありません。
・ GitHub CopilotやJetBrains AIなど、他のAIプラグインも引き続き併用できます。

使い分けが実態

・ Android開発の中心はGeminiになっていく傾向です。
・ ただし、企業の方針や個人のニーズ(ガバナンス、慣れなど)に応じて、最適なツールを使い分ける形が現実的です。


3大 AIプラグイン ショートカット比較表(Copilot / JetBrains AI / Gemini)

 

🤔 3大AIプラグイン ショートカット比較表(Copilot / JetBrains AI / Gemini)

機能 GitHub Copilot JetBrains AI Assistant Gemini for Android Studio
AIコード補完の表示 ⌥](次候補)
⌥[(前候補)
⌥Space ⌘I または Ctrl+I
AI候補を確定 Tab または Enter Enter Enter
補完候補を拒否 Esc Esc Esc
AIチャットを開く ⌘⇧I ⌥⇧A ⌘⇧.
選択コードの説明 / 修正 ⌘⇧\\ ⌥Enter → 「AI提案」 ⌘⇧L
コメントからコード生成 // コメント後に Enter AIチャットから「コード生成」 コメント入力 → ⌘Enter
コードの最適化・修正 ⌘.(Quick Fix) ⌥Enter → 「AIでリファクタ」 ⌘⇧M
ドキュメント生成 / 説明追加 ⌘⇧/ AIチャット「この関数を説明して」 ⌘⇧D
選択範囲に対するAI操作 ⌘⇧\\(説明・修正) ⌥Enter ⌘⇧L
ファイル全体を改善 なし(コメントから提案) ⌥⇧A → 「ファイルを改善」 ⌘⇧F

 

🤔 AIプラグイン運用おすすめ(衝突回避パターン)

利用スタイル 構成 特徴・おすすめポイント
① コーディング中心型
(AI補完を重視)
Copilot + JetBrains AI(Copilot優先) Copilotの補完をメインに、JetBrains AIは「説明」「修正」時のみ使用。
⌥EnterをAI専用に割り当てると安定。
② 設計・レビュー重視型
(AI説明とチャットを多用)
JetBrains AI + Gemini(Copilotオフ) チャットでの説明・リファクタが中心。GeminiでAndroid特有の質問も可能。
⌥⇧A⌘⇧. の競合に注意。
③ Android特化開発型
(Geminiメイン)
Geminiのみ or Gemini + Copilot Android Studio統合が深く、ComposeやAPI質問が即答。
Copilotを補完専用に使うと最も安定。
④ 学習・試行型
(全部試すタイプ)
Copilot + JetBrains AI + Gemini(全併用) ショートカット競合が多発。どれを「補完用」「チャット用」にするか明確化必須。
設定から「Keymapのカスタム」を推奨。

 

🤔 AIプラグイン ショートカット競合リスク表

組み合わせ 競合リスク 主な衝突ショートカット 対策・回避策
Copilot + JetBrains AI ★★★☆(中〜高) ⌥Enter, Tab, ⌘. JetBrains側のAI提案を「右クリック呼び出し」に変更推奨。
CopilotをTab確定中心に設定。
JetBrains AI + Gemini ★★★(中) ⌥⇧A, ⌘⇧. どちらを「チャット起動」に使うか決める。
Geminiを ⌘⇧; にリマップ推奨。
Copilot + Gemini ★★(低〜中) Enter, ⌘I 競合は軽度。Copilotを補完専用・Geminiをチャット専用に分離。
Copilot + JetBrains AI + Gemini ★★★★(高) ⌘⇧I, ⌥Enter, Enter 全AIのショートカットを手動で再割り当て必須。
Preferences → Keymapで確認・上書きを推奨。

 

🤔 まとめ:

・同時導入するなら「補完」「チャット」「リファクタ」の役割を分ける。
・競合は特に ⌥Enter⌘⇧I に集中。
・キー設定は Keymap → Search: “AI” で全体を確認しておくのが安全。

Copilot:補完が最速で自然、Tab確定中心の軽快操作。
JetBrains AI:リファクタやドキュメント生成など開発支援が得意。
Gemini:Android Studioに最も深く統合され、自然言語操作が強力。


『AIで書いたコードは危険』と語る著名プログラマーたちのコメント

 

🤔 Jake Wharton

I really dislike all this 'auto complete sold as AI by big corpo' crap.

私はこの“大企業がAIとして売っているオートコンプリート”というクソみたいなものが本当に嫌いだ。

Don't blindly trust code generated by AI; always review and understand it.

AIが生成したコードを盲目的に信頼してはいけない。必ずレビューし、理解すること。

 

🤔 Andrew Ng

Just vibe coding is not going to help. Using and relying on generated code is dangerous. AI generated code can produce hallucinations.

vibe codingは役に立たない。生成されたコードを使って頼るのは危険だ。AIが生成するコードは幻覚を生じる可能性がある。

 

🤔 Martin Fowler

When I’m using AI for coding, I find myself constantly making little risk assessments about whether to trust the AI, how much to trust it, and how much work I need to put into the verification of the results.

AIを使ってコーディングをしているとき、私は常にAIを信頼するかどうか、その信頼度をどの程度にするか、結果の検証にどれだけの労力をかけるべきかを小さなリスク評価として行っています。

 

🤔 Kent Beck

I feel good about the correctness & performance, not so good about the code quality. When I try to write the code as a literate program there's ...

私は正確性とパフォーマンスには満足していますが、コードの品質にはあまり満足していません。コードをリテラルプログラムとして書こうとすると…

 

🤔 Robert C. Martin

The clean coder 'Uncle Bob' aka Robert C. Martin reflects on his career, the way he works and what advice he would give to his younger self if he were to start ...

クリーンコーダー“Uncle Bob”ことRobert C. Martinは、自身のキャリア、働き方、そして若い頃の自分にどんなアドバイスをするかについて振り返っています。

 

🧑🏻‍💻 まとめ

著名なプログラマー達は、AIをコーディングの補助ツールとして評価しつつも慎重な姿勢を見せています。

AIが生成したコードは盲信せず、品質管理の最終的な責任は開発者自身が負うべきだと彼らは強調します。

結論として、AIは便利なツールですが、その出力は常に人間の手でレビュー・検証される必要があります。

 

🤔 参考

👉 AI を使ったプロンプトに入れておきたい著名プログラマーの哲学的名言100