FriendlyMeals-Android

Android Dev Summit 2026で驚いたところ 今回は嬉しいことに機会があり現地参加できました :pray: 特に驚いたり重要だと思うところを太字にしておきます。 AI使って直してもらってるので、間違っているところがあったら教えてください :bow: Keynote youtube.com %%{init:{"flowchart":{"nodeSpacing":50,"rankSpacing":110}}}%% flowchart LR classDef K fill:#e3f2fd,stroke:#1e88e5,color:#0d47a1 classDef S fill:#fafafa,stroke:#e0e0e0,color:#9e9e9e,font-size:12px a[Android開発者の体験は<br/>毎月30億人に届く] b[AIで作り方が速くなった<br/>品質には開発者が要る] a==>|でいま起きているのは|b subgraph B[1 作り方を選べる] direction LR c[Android CLI + skills<br/>ナレッジベース] d[Bring Your Own Agent<br/>ACPでClaude Code等をStudioへ] e[Compose first<br/>右クリックでXML→Compose Canary] end subgraph X[2 アプリのエージェント体験] direction LR j[A2UI Compose<br/>エージェントがネイティブUIを返す] l[Gemini Nano 4 + ML Kit<br/>Agentic API / function calling] m[Android MCP<br/>AppFunctionsで機能を公開] n[Connected Apps<br/>Gemini / Searchから使われる] end subgraph H[3 ハードウェア] direction LR q[Googlebook<br/>5社のOEMと作るノートPC] r[XREAL AURA<br/>Android XRの有線XRグラス] end b==>|への答えの1つ目は|B b==>|2つ目は|X b==>|3つ目は|H f[LeakCanaryコマンドを数週間内に<br/>同じモデルでCLIなしと比べ<br/>約2倍速・トークン25%減] c-.->|のデモは|f g[skillsはevalで検証<br/>モデルが知らない領域に絞る] c-.->|の作り方は|g i[android prototype 仮称<br/>APKを軽量プロセスで複数サイズ実行] c-.->|の予告は|i h[Instagram Direct: Views比トークン33%減<br/>Shopify: 起動時間50%短縮] e-.->|の根拠は|h p[フライト予約デモ] j-.->|の例は|p s[機内モードで<br/>経費を値引き額に更新するデモ] l-.->|の例は|s l==>|のツールを作り直さず外に出すのは|m n==>|の接続方式の1つは|m o[Geminiに聞くと<br/>Android Dev Summitアプリが答える] n-.->|のデモは|o t[スマホ+大画面ユーザーは<br/>スマホのみより支出9倍] q-.->|の背景は|t u[adaptive skillで<br/>デスクトップ対応] q-.->|への対応は|u v[既存アプリがそのまま動く<br/>音楽を流しながら作業] r-.->|では|v w["年末まで$1,099から"] r-.->|の価格は|w k[XR SDK・エミュレータ<br/>Engine Hubがstable] r-.->|と同時に|k e==>|で作っていれば備えられるのは|H class a,b,c,d,e,j,l,m,n,q,r K class f,g,i,h,p,s,o,t,u,v,w,k S - 一言で言うと: Keynoteらしく、Android開発関連のアップデートのまとめという感じでした。 - Matthew McCullough（Keynoteの最初と最後に話した人） - Androidの開発者が作る体験は、毎月世界30億人に届いている。 - Android Studioにあなたのエージェントを持ち込めるように。 - Android ナレッジベース。 - Android CLI - Composeでtoken costが33%減ったという話。 Instagram Directの社内分析で、同じタスクをComposeとViewsで比べたときのエージェント1セッションあたりの値。 - android-developers.googleblog.com - Shopifyのnative化で50%早くなったという話 - Intelligence Experience - Adobe PremiereがMedia3とDawn/WebGPUで、マルチトラック4K動画編集とAIノイズ除去を作った話。Compose + Navigation3でadaptive対応もしたそう - Agent Tools - Skillをevaluationしている話。 - Android CLIでメモリリークを直すデモ - LeakCanary Command 来るらしい - android prototype（名前は検討中で仮称だそう）。android prototype jetpacker.apk のようにAPKを渡すと、ノートPC上の軽量プロセスでアプリが起動して操作できる。 - phone / foldable / desktop の複数サイズで同時に動かせる。エージェントも操作して動作確認できるそう。 - Bring Your Own Agent。ACP（Agent Client Protocol）で Android Studioからいろんなエージェントが使える。 - 実際にAndroid StudioからClaude Codeのサブエージェントが使えるデモ - Compose first - 2クリックでレイアウトXMLをComposeに！右クリックしてmigrate to composeでComposeに！ - Intelligence - Navigation3などのライブラリで、いろんなフォームファクタ対応を楽にしている話 - 新しいApp Stateライブラリ群（Composeの考え方でアプリの状態を管理する。複数のUI間でセッション状態を共有するなど）。alphaで、フィードバックを募集中だそう - A2UI ComposeでUI表示して、フライト予約するデモ - x.com - Gemini Nano ML Kit - ML Kit Agentic API - Function callできる。 - 機内モードで、エッフェル塔のチケットを経費に追加し、「割引で30ユーロだった」と言うとエージェントが経費を更新するデモ - x.com - Android MCPは、AppFunctionsで公開したAndroidアプリの機能を、Geminiなどのエージェントから利用するための仕組み。 - Connected Apps Platformでは、リモートのMCP serverと並ぶ接続方式として用意されている。アプリ側はAppFunctionsで実装し、Google Connected Consoleで登録・テストできる。Android MCPのConnected Appは、紐づけたPlayアプリの製品版リリースに合わせて審査・公開される。 - 公式の登録・公開手順 - Connected Apps Platform - GeminiでAndroid Dev Summitに聞くと、アプリにアクセスして答えてくれるデモ。こういうのができるのをConnected Appって呼ぶみたい。 - Googlebook laptop - スマホと大画面の両方を使うユーザーは、スマホだけのユーザーよりアプリへの支出が9倍らしい。 - 5社のノートPCメーカー（OEM）と組んで、ハイエンドのGooglebookを揃えたらしい。 - Antigravity CLI + Android CLIのadaptive skillで、Googlebook上で横に間延びしたアプリをデスクトップ対応にする例（Navigation3のlist-detail、キーボードショートカット、ツールチップなど） - Android XR - XREAL AURA Android XR。 - AndroidXRのデモ - 音楽流しながら使ったりなど - x.com - 年末までAURA $1,099で安く提供されるそう - Android XR Engine Hubがstableに（Unity / Unreal Engine / Godot向け）。XRのJetpack SDKとエミュレータもstable - まとめると - どうやってビルドするか - アプリのAI体験 (intelligent experiences) - ハードウェア Extend your app to Gemini and Search with the Connected Apps Platform youtube.com %%{init:{"flowchart":{"nodeSpacing":50,"rankSpacing":110}}}%% flowchart TD classDef K fill:#e3f2fd,stroke:#1e88e5,color:#0d47a1 classDef S fill:#fafafa,stroke:#e0e0e0,color:#9e9e9e,font-size:12px a[タップ操作からAIとの会話へ] b[AIとの会話、Geminiだけでは<br/>実際のタスクを<br/>実行する手がない] c[Connected Apps] d[ユーザーの意図をアクションに<br/>ブランド・UIはアプリのもの] a==>|で残る問題は|b b==>|を解決するのは|c c-.->|がすることは|d e[一度ツールを定義すれば<br/>Gemini / Searchに出せる] c==>|の利点は|e subgraph f[作り方は2つ] direction LR g[Remote MCP Server] h[Android MCP] end c==>|の作り方は|f i[Android / iOS / Webを<br/>まとめて対応するとき推奨] j[AppFunctionsで実装<br/>データが端末にしかないとき] g-.->|が向くのは|i h-.->|の実装と向く場面は|j subgraph k[MCPサーバーの4つのコツ] direction LR l[サーバーの<br/>instructions] m[read only / destructive<br/>のアノテーション] n[型付きスキーマと<br/>docstring] ui[UIリソースのmeta] end g==>|で守るのは|k p[確認を出すか<br/>取得は確認なし・予約や削除の前は確認] m==>|を手がかりに判断されるのは|p q[MCP Apps UIを<br/>sandbox iframeで描画] ui-.->|で実現するのは|q subgraph r[テスト] direction LR s[ローカル実行 +<br/>MCP Inspector] t[デプロイ<br/>例: Cloud Run] u[Gemini Developer Mode] s-->|の次は|t t-->|の次は|u end k==>|を押さえたら次は|r v[US向け / ツール呼び出し・レイテンシ<br/>リクエスト・レスポンス詳細<br/>eval・ベンチマークは今後] u-.->|で見られるのは|v w[アクセス申請<br/>US開発者向けプレビュー] cc[Google Connected Console] y[スキーマはスナップショット<br/>変更したら再デプロイ] z[審査に提出・テスターで確認<br/>→ 最終審査 → 本番公開] r==>|の次は|w w==>|が承認されると使えるのは|cc cc-.->|の注意は|y cc==>|での流れは|z class a,b,c,e,g,h,l,m,n,ui,p,s,t,u,w,cc K class d,i,j,q,v,y,z S - 一言で言うと: 基本はConnected Appsをサーバーで作ったMCPで登録していくという話でした。つまりGeminiのアプリとサーバーが通信するので、Android色は薄めでした。 - 何かをユーザーがするときに、"アプリのメニューをタップして使っていく"から"AIと会話"になっている。 - Connected apps: ユーザーの意図からアクションにする。 - Connected Apps Platformで、今はGeminiアプリとSearchに出せる。ほかの製品も今後増えるそう - 一回、MCP specなどでスキーマを作ったらどこにでも出せる - 最初のプレビューはUSの開発者だけが対象。段階的に広げていくそう。 - フォームでアクセスを申請する（開発者ガイドか、Play Consoleのホームから）。 - 承認されるとGoogle Connected Consoleが使えるようになり、そこで本番公開の準備をする。 - 下のGemini Developer Modeは、アクセスが承認されていなくても試せる。 - Gemini Developer Mode。 US向け。レイテンシやレスポンスの確認ができる。eval、ベンチマークなどの評価機能も今後出てくるそう - ただの情報の取得などは確認せずに実行して、bookなどの前は確認するなどを行うように。 - MCPサーバーのツールに read only / destructive のアノテーションを付ける。destructiveならプラットフォームが実行前にユーザーへ確認を出す。 - Geminiアプリでは、アプリごと・アクションごとに毎回確認するかユーザーが選べる。 - どうやってConnected Appを作るか - 2つの方法 MCP Server か Android MCPか。 remote MCPがおすすめ、他のプラットフォームでも使えるので。 - （セッション外の補足）2026年11月時点のドキュメントでは、1つのConnected Appで選べる接続タイプは1つだけで、後から変更もできない。「アプリが入っていればAppFunctions、なければサーバー」のような切り替えは1つのConnected Appではできない。 developer.android.com - テスト方法: - MCPサーバーをローカルで走らせて、MCP inspectorで確認する - gcloud run deploy(cloud run)などでdeployして確認する - Gemini Developer Modeで確認する - Developer Modeは、任意のMCPツールを呼んだりレスポンスのjsonを確認したりなど - アーリーアクセスプログラム登録 -> Connected Consoleで、Connected appでappを登録してMCPを登録する - Connected ConsoleはMCPスキーマのスナップショットを取るので、スキーマを変えたら再デプロイが必要だそう。 Migrating two decades of the Google Play app to Jetpack Compose youtube.com %%{init:{"flowchart":{"nodeSpacing":50,"rankSpacing":110}}}%% flowchart TD classDef K fill:#e3f2fd,stroke:#1e88e5,color:#0d47a1 classDef S fill:#fafafa,stroke:#e0e0e0,color:#9e9e9e,font-size:12px a[2007年からのPlayアプリ<br/>数百万行 / 200画面 / 500コンポーネント] b[2020年 開発速度・信頼性・<br/>性能が目標に届かなくなってきた] c[Composeを採用] a==>|で起きたのは|b b==>|ので|c d[Compose専用画面がインプレッションの97%<br/>主要画面のjankが14か月で30%改善] c-.->|の現在は|d subgraph e[段階的に移行] direction LR f[crawl<br/>低トラフィック画面<br/>設定など] g[walk<br/>高トラフィック画面の<br/>コンポーネント] h[jog<br/>高トラフィック画面全体<br/>FragmentがComposeViewを返す] i[run<br/>ActivityがComposeだけを持つ<br/>遷移もComposeで] f-->|の次は|g g-->|の次は|h h-->|の次は|i end c==>|の進め方は|e j[テーマがXMLスタイルと<br/>一致するかテスト] f-.->|でやったのは|j k[描画スタックが2つで一時的にjank増<br/>プリウォームで緩和] g-.->|の注意は|k l[AndroidFragmentで包んで表示] i-.->|で未移行の画面は|l n[MaterialThemeの<br/>オーバーレイで動的テーマ] c==>|で得たのは|n o[シード色から配色を生成<br/>重ければビルド時に生成] n-.->|の作り方は|o p[単方向データフロー] q[宣言的UI] c==>|の設計は|p c==>|の書き方は|q r[レース条件が消える<br/>並列ロードで遅延短縮] p-.->|の効果は|r s[LLMで質の高いコード生成] p==>|が支えるのは|s q==>|が支えるのは|s t[スクショに注釈<br/>コンポーネント名・デザイントークン<br/>関数シグネチャ] s-.->|のコツは|t subgraph u[品質の自動化] direction LR v[Code quality Lint<br/>不要な再コンポジションなど] w[Theming Lint<br/>色・タイポのハードコード禁止] x[コンポーネントカタログと<br/>専用エージェント] end s==>|の品質を守るのは|u class a,b,c,f,g,h,i,n,p,q,s,v,w,x K class d,j,k,l,o,r,t S - 一言で言うと: Google PlayでのCompose化の話。なんですが、どういう仕組み作りをしていったのかというかなり汎用的な話をしていたので面白かったです。適用できるアプリ多そうでおすすめです。 - 2020年ごろ、View/Fragmentでの開発速度・信頼性・パフォーマンスが目標に届かなくなってきたのでComposeを採用した。 - Google Playの主要画面（検索結果・ホーム・詳細）のjankが、過去14ヶ月で30%改善したそう - Google Play、Low Traffic PageからCompose化を始めたらしい。設定画面など。 - 次はHigh Trafficのコンポーネントを置き換えた。 - Google PlayでのCompose化方法 - 設定画面 -> コンポーネント -> ActivityなどがComposeだけを持つ, NavigationをComposeに, AndroidFragment()でFragmentを表示 - Google PlayのUnidirectional Data Flow - x.com - 何種類かのレース条件が丸ごとなくなったそう。データソースとUI変換を並列に実行しやすくなり、ストアの読み込み遅延も50msくらい縮んだそう。 - Code quality automation - Lintを用意するなどいくつかの方法でAIを使った開発でクオリティを担保した。 - 例: 不要な再コンポジションを見つけるFrequentlyChangingValueDetector、Scaffoldのpaddingを無視していないか見るScaffoldPaddingDetectorなどのLint。BoxWithConstraintsは警告にする - Theming automation - 色やtypographyのハードコードをLintで禁止。Material 2コンポーネントの利用や、レガシーなXMLから色を読むのも検出する仕組みを作ったそう Integrate your app with the Android intelligence system youtube.com %%{init:{"flowchart":{"nodeSpacing":50,"rankSpacing":110}}}%% flowchart TD classDef K fill:#e3f2fd,stroke:#1e88e5,color:#0d47a1 classDef S fill:#fafafa,stroke:#e0e0e0,color:#9e9e9e,font-size:12px a[モバイル時代: アプリを渡り歩く] b[インテリジェンス時代: 1つのプロンプトで<br/>エージェントが複数アプリを操作] a==>|から変わって|b subgraph c[2つの柱] direction LR d[In-app intelligence<br/>ML Kit / Firebase AI Logic] e[Intelligence system<br/>システムに深く統合] end b==>|に備える柱は|c f[Proactive assistance<br/>次の行動を提案] g[Prompted assistance<br/>エージェントに頼む] e==>|の形は|f e==>|の形は|g f-.->|に載るためにまず備えるのは|g h[直接API連携<br/>速く確実・見せ方を制御] i[タスク自動化<br/>エージェントが実際のアプリUIを操作・コード変更不要] g==>|で推奨されるのは|h g-->|の代替は|i j[エージェントが支払いなどの前で<br/>止まってユーザーに確認] i-.->|で欠かせないのは|j k[サーバーMCP] l[Android MCP<br/>基盤はJetpack AppFunctions beta<br/>Binder IPCで動く] h-->|の道は|k h==>|の道は|l m[暗号化データ・オフライン・センサー<br/>クラウドAPIがない<br/>例: Xiaomiギャラリーが<br>Geminiに写真を返す] l==>|が向くのは|m subgraph n[実装] direction LR o[AppFunctionを宣言 + KDoc<br/>KDocがエージェント向けの説明] p[パラメータは最小限<br/>任意はnullableで本体で既定値] q[app metadataに<br/>ドメイン・手順・制約] end l==>|の実装は|n r[Kotlinの既定値は効かずnull/0<br/>メインスレッドで呼ばれる<br/>失敗はAppFunctionExceptionを投げる] n-.->|で気をつけるのは|r s[android skills add appfunctions<br/>ジャーニー特定→コード生成→KDoc] s==>|が作るのは|n t[画面/Activityスコープの関数<br/>動的な有効化・アクセスレベル] n-.->|の応用は|t u[ユニットテスト + エージェント側テスト<br/>Connected Apps preview経由でGemini<br/>Play Consoleの内部テストトラック] n==>|を確かめるのは|u class a,b,d,e,f,g,h,l,m,o,p,q,s,u K class i,j,k,r,t S - 一言で言うと: Android MCP/AppFunctionsを使ってアプリからエージェントに機能を公開する方法 - Mobile Eraでは、やりたいことに対して、いろんなアプリを経由して行っていた。 - Intelligence Eraで、プロンプトで一気にいろんなアプリを操作して実行される。 - In app intelligence - アプリ自体を賢くする方。ML Kit経由でGemini Nano 4を使ったり、Firebase AI LogicでクラウドのGeminiを呼んだりなど - Intelligence system - アプリの機能をシステム（Geminiなどのエージェント）から使えるように、もっと深く統合する方。今回の主題はこっち - Proactive assitance - 次にやることを予測して、ロック画面・通知・キーボードなどにチップで提案する - アプリをここに載せる方法は語られず、今できるのは下のPrompted Assistanceに備えることだそう - Prompted Assistance - ユーザーがエージェントに頼んで、アプリをまたいだタスクをやってもらう形。タスク自動化（エージェントがUIを操作）より直接API連携が推奨だそう - Android MCPはローカルコンテキストやデバイス上であることが重要なときに価値があるそう。 - 例えば、Geminiアプリから、写真アプリがローカルの画像を返すなど - Android MCP deep dive: - goo.gle/jetpacker - deep diveのコード例は旅行サンプルアプリ（JetPacker）から取っていたそう - AppFunctionは特定の画面やActivityにスコープを絞って作れる。シグネチャだけ宣言してUI側でHandlerを実装し、Handlerのライフサイクルは使うcoroutine scopeに自動で紐づくそう - android skills add appfunctions - -> user jouneyを見つけて、コードを作って、エージェントが使うKDocを定義してくれる - android/appfunctions サンプル - android/appfunctions Inside Gemini Nano and Gemma 4 powering on-device intelligence youtube.com %%{init:{"flowchart":{"nodeSpacing":50,"rankSpacing":110}}}%% flowchart TD classDef K fill:#e3f2fd,stroke:#1e88e5,color:#0d47a1 classDef S fill:#fafafa,stroke:#e0e0e0,color:#9e9e9e,font-size:12px a[目標: モデルを大きくせず<br/>同じサイズのまま多くの能力] b[スマホの制約<br/>メモリ12〜16GB・帯域50〜80GB/s・電力] c[Gemma 4<br/>E2B / E4B / 12B / 大型 dense・MoE] a==>|を形にしたのが|c b==>|に1つずつ対処するのが|f subgraph d[4つの能力] direction LR d1[Vision<br/>可変アスペクト比・OCR・物体検出] d2[Audio<br/>Gemma 3nで導入] d3[Agentic reasoning<br/>計画・ツール呼び出し・JSON] d4[Text<br/>コード生成・長い文書] end c==>|が持つのは|d e[E2B / E4B はスマホで動く<br/>E2BでもGemma 3 27Bを<br/>推論・コード・エージェント系で上回る] c==>|のスマホ向けは|e subgraph f[小型モデルの最適化] direction LR g[Per-Layer Embeddings<br/>各層に専用のEmbedding] h[Multi-Token Prediction<br/>ドラフトが数トークン先読み<br/>本体が検証] i[Quantization Aware Training<br/>量子化前提で学習] end e==>|を支える技術は|f g2[必要なEmbeddingだけ読み込む<br/>実効2Bでメモリと帯域を節約] h2[本体のKVキャッシュを共有<br/>デコード遅延40%減・電力30〜40%減] i2[一部を2bitまで量子化<br/>モバイル量子化版は1GB未満] g-.->|の効果は|g2 h-.->|の効果は|h2 i-.->|の効果は|i2 j[AICore経由 = Gemini Nano 4<br/>ML Kitで手軽に使える<br/>最適化込み・アプリ間で共有・安全チェック] k[LiteRT<br/>アプリに同梱・ファインチューン可<br/>メモリと電力は自分で管理] f==>|をそのまま使える経路は|j j-->|より細かく制御したいときは|k l[デモ1: 完全ローカルの音声アシスタント E2B<br/>デモ2: オフラインでカメラ + ツール呼び出し E4B] c-.->|のデモは|l class a,b,c,d1,d2,d3,d4,e,g,h,i,j,k K class g2,h2,i2,l S - 一言で言うと: スマホで動くGemma 4の能力と、それを支える最適化（PLE、MTP、QAT）の話 - Gemmaの歴史、Gemma4には E2B・E4B・12B、大型のdense・MoEモデルがある。スマホ向けはE2B/E4B - EはEffective（実効パラメータ数）のE。後述のPer-Layer Embeddingsから来ている - できること - Vision、Audio(Gemma 3nで入った。小さいモデル（E2B・E4B）と12Bにだけ入っているらしい)、Agentic Reasoning(planとか、toolを呼んだりなどができる)、Text(コード生成など) - E4bはスマホで動く。 - 物体検出して、boxを描画できるらしい - スマホでどうやってうまく動くか。 - Gemmaの最適化 - PerLayerEmbeddings。メモリ削減。普通はEmbeddingで変換してからやるけど、Eモデルは各層で専用のEmbeddingを追加する - PLEは、通常 文字列 -> トークンベクトル -> Layer1 -> Layer2みたいに渡っていくだけだけど、各層用の追加のEmbeddingテーブルを持っていて、入力に必要な分だけ読み込んでLayer1やLayer2にも渡すらしい - パラメータ総数は大きいけど、メモリに読み込むのは実効パラメータ分（E2Bなら2B）だけなので、RAMと帯域を節約できる - Multi-Token Prediction。推論速度を上げる。複数のトークンを先読み。 - Quantization Aware Training。量子化を前提に学習することで量子化の性能を上げる。 - developer.android.com - huggingface.co - kaggle.com On-device intelligence: Optimized performance and quality using Android ML Kit APIs youtube.com %%{init:{"flowchart":{"nodeSpacing":50,"rankSpacing":110}}}%% flowchart TD classDef K fill:#e3f2fd,stroke:#1e88e5,color:#0d47a1 classDef S fill:#fafafa,stroke:#e0e0e0,color:#9e9e9e,font-size:12px a[オンデバイスAIの理由<br/>速度・コスト・オフライン・プライバシー] a2[試したケースでクラウド比2倍速い<br/>通信の往復がないため] a-.->|の速度の根拠は|a2 b[ML Kit GenAI API<br/>組み込むのはML Kitだけ] a==>|を手軽に得る手段は|b c[AICore<br/>安全チェック・モデル配布・ランタイム] b==>|の裏で複雑さを引き受けるのは|c d[AICore対応端末は175M台<br/>ML Kitは1000万DL超のアプリで本番採用] c-.->|の規模は|d subgraph e[Gemini Nanoの改善] direction LR e1[RAM 3.6GB→1.1GB<br/>2bit量子化・KVキャッシュ共有<br/>画像/音声エンコーダの遅延読み込み] e2[速度<br/>prefix cacheでsystem promptを再処理しない<br/>投機的デコードで社内の用途では平均2倍] e3[品質<br/>2Bが昨年の27Bに迫る<br/>MMLU Proは下・科学推論とツール利用は上] end c==>|で動くモデルの改善は|e g[既存: system instructions・複数画像<br/>thinking mode・構造化出力] f[新しい4機能<br/>Speech Translation / Embeddings<br/>Text to Speech / Function Calling] b-->|の既存機能は|g b==>|に加わったのは|f subgraph h[例: 詐欺の留守電を端末内で判定] direction LR h1[Intake<br/>音声翻訳 + 音声認識] h2[Triage<br/>Prompt API + Function Calling<br/>AppFunctionsと統合] h3[Retrieve<br/>マルチモーダルEmbedding<br/>+ AppSearch] h4[Audit<br/>構造化出力 + 音声合成] h1-->|の次に|h2 h2-->|の次に|h3 h3-->|の次に|h4 end f==>|などを組み合わせた例が|h i[tool callingではthinking modeで<br/>精度が13ポイント上がる] j[コードを実行するのはアプリ<br/>Nanoは問いを出すだけ] k[共通の語がなくても<br/>コサイン類似度で似たものを探す<br/>しきい値0.68は要調整] l["@Generable / @Guide を付けたKotlinクラス<br/>詐欺か・リスク0〜100・矛盾の種類"] h2-.->|のコツは|i h2-.->|の安全性は|j h3-.->|の仕組みは|k h4-.->|の出力の型は|l class a,b,c,e1,e2,e3,f,h1,h2,h3,h4 K class a2,d,g,i,j,k,l S - 一言で言うと: オンデバイスAIをいくつかのユースケースで気軽に使えるML Kit GenAI APIの紹介 - On deviceは速度 (2xはやくなりえる) 、コスト、オフライン、センシティブデータ - ML Kitはon device AIをシンプルにする - GenAI APIの採用: 1000万DL超のアプリ9本がすでに本番で使っているそう - 175M+ デバイスで AI Coreが使える。 - AICoreは、ML Kitの裏でモデル（Gemini Nano）のダウンロードや実行環境、入出力の安全チェックを引き受けている仕組み - prefix cacheで毎回system promptを処理しなくてよくなる - tool callingではthinking modeを使うのがおすすめ。Googleのテストでは精度が100点中13ポイント上がったそう。 - Gemma 4 2BでもGemma 3 27Bとベンチマーク上同じぐらいに動くようになったそう。 - 最近の4つの機能 - Speech Translation - Embedding - Text to Speech - Function Calling - Retrieve（デモの詐欺留守電チェック（Intake→Triage→Retrieve→Audit）のうち、注文情報などを検索できるようにしておく段階） - ML Kit、EmbeddingGenerationで似たもの探したりできる。 - @Generable を付けたKotlinのクラスを渡すと、出力をその型のオブジェクトで受け取れる（構造化出力）。 Build optimized Android Apps with Firebase AI Logic and Gemini Nano 4 youtube.com %%{init:{"flowchart":{"nodeSpacing":50,"rankSpacing":110}}}%% flowchart TD classDef K fill:#e3f2fd,stroke:#1e88e5,color:#0d47a1 classDef S fill:#fafafa,stroke:#e0e0e0,color:#9e9e9e,font-size:12px a[モバイルで生成AIを出す課題<br/>APIキー漏洩 / モデル名の埋め込み / データ保護] b[Firebase AI Logic] c[バックエンドなしで<br/>クライアントSDKからGeminiを直接呼ぶ] d[Gemini Developer API /<br/>Agent Platform Gemini API] a==>|を解決するのは|b b==>|の中心は|c b-.->|が安全に中継する先は|d subgraph s[セキュリティと監視] direction LR e[App Check] f[Server Prompt Templates] g[AI monitoring] end b==>|を本番で支えるのは|s h[Play Integrity / reCAPTCHA Enterprise<br/>未強制で様子を見てから強制] i[.promptでクラウドに置く<br/>モデル名・指示をリリースなしで更新<br/>Auth only / Template only<br/>Public Preview] e-.->|の証明手段は|h f-.->|の中身は|i j[サンプリングで<br/>レイテンシ・トークン数を可視化] g-.->|でできるのは|j subgraph t[コスト対策] direction LR k[ハイブリッド推論] l[Firebase Spend Caps] m[AI Logic triggers] end g==>|でトークン急増に気づいたら|t n[端末優先 / クラウド優先 / 端末のみ<br/>端末側はGemini Nano 4<br/>引数を1つ足すだけで<br/>使えなければクラウドへ自動で切替] o[サービス単位の予算で自動停止<br/>Preview・停止まで遅延があり<br/>超過分も請求される] p[generateContentの前後で<br/>入力確認・応答調整<br/>Preview] k-.->|の設定は|n l-.->|の挙動は|o m-.->|でできるのは|p q[オフライン / 無料 / プライバシー] r[材料抽出は端末内<br/>レシピ生成はクラウド] k-->|の利点は|q k-.->|のデモは|r u[Gemini Live API] v[双方向の音声会話<br/>WebSocketはSDKが処理] b-->|で使えるのは|u u-.->|でできるのは|v w["Firebase agent skills<br/>npx skills add firebase/agent-skills"] w-->|でエージェントに教えるのは|b class a,b,c,e,f,g,k,l,m,u,w K class d,h,i,j,n,o,p,q,r,v S - 一言で言うと: バックエンドなしでアプリから安全にGeminiを呼ぶFirebase AI Logicの話（App Check、Server Prompt Template、Spend Capsなど） - モバイルで生成AIを出すときの課題（APIキーは数分で抜かれる、など）を解決するのがFirebase AI Logic。アプリからのリクエストをGemini Developer APIかAgent Platform Gemini APIに安全にルーティングする。 - サンプル - FirebaseExtended/FriendlyMeals-Android - Firebase AI LogicのキーコンセプトはDirect Gemini Access。バックエンドを立てずに、アプリのClient SDKから直接Geminiを呼べるというところ。 - Securityをどうしてるか？App Checkでアプリからのアクセスだけに絞るようにしている。 - 開発中はdebug provider、本番はPlay IntegrityかreCAPTCHA Enterpriseに切り替える。サンプルでは if (BuildConfig.DEBUG) で分けていた。 - 最初はenforceせずにテレメトリを見て、問題なければenforceする。 - Server Prompt template - .promptフォーマットで書いてクラウドに置くので、リリースなしでいつでもアップデートできる。Public Preview。 - プロンプトだけでなくモデル名もコンソールで設定できるので、新しいモデルが出てもアプリのリリースなしで切り替えられる。 - Auth only（Firebase Authのユーザートークンでリクエストを認可する）やTemplate Only（Firebase Consoleから設定）もできる。AI monitoringを有効にすると最終的なプロンプトを見ることができる。 - Firebase Spend Caps！いまの時代必須な機能 - ただ厳密な上限ではなく、止まるまでの遅延で超えることがあり、超えた分も請求されるので注意。(Preview) - firebase.google.com - コスト最適化として紹介されたのはFirebase AI Logic triggers。generateContentの前後に関数を挟んで、ユーザーのチェックや入力のフィルタ、コンテキスト追加、レスポンスの調整ができる。 - Gemini Live APIでbidirectional voice conversationができるそう。 - npx skills add firebase/agent-skills - npx skills add firebase/agent-skills ではいる現状の Firebaseのskill一覧 - x.com Mastering on-device intelligence with ML Kit and LiteRT in Google Play services youtube.com %%{init:{"flowchart":{"nodeSpacing":50,"rankSpacing":110}}}%% flowchart TD classDef K fill:#e3f2fd,stroke:#1e88e5,color:#0d47a1 classDef S fill:#fafafa,stroke:#e0e0e0,color:#9e9e9e,font-size:12px a[端末内の古典的MLの悩み<br/>Turnkey APIか自前モデルか] b[性能 / ハードウェアの多様さ<br/>APKサイズ / モデルのカスタマイズ] a-.->|の背景にある課題は|b subgraph f[2つの入口] direction LR c[ML Kit<br/>Turnkey] d[自前モデル<br/>LiteRT] end a==>|は選ばずに両方使える|f e[LiteRT in Google Play services] f==>|の下で共有されるランタイムは|e g[APK約8MB減 / アプリ間で1つ<br/>Googleが更新 / GPU約1.4倍<br/>Android 7+・Wear OS 4+・AAOS 11+] e-.->|の利点は|g h[TFLite・LiteRTで25万アプリ<br/>YouTube Shortsのエフェクトなど] e-.->|の実績は|h i[CompiledModel API] e==>|で使う新APIは|i j[CPU・GPU・NPUを1つのAPIで<br/>CPUへの自動フォールバック<br/>NPUは現状同梱版のみ・対応中] k[旧GPU比1.4倍 / CPU比最大10倍<br/>ゼロコピー・非同期] i-.->|の特徴は|j i-->|のGPU性能は|k subgraph l[デモ: カメラ背景のスタイル変換] direction LR m[ML Kit<br/>セルフィーセグメンテーション] n[自前のスタイル変換モデル] o[合成して約30fps] end c-->|の例は|m d-->|の例は|n m-->|のマスクと|o n-->|の背景を|o p[PyTorch] q[litert-torchで変換<br/>LiteRT Quantizerで量子化] p==>|を.tfliteにするのは|q q==>|で用意するのが|d r[同梱版・Interpreter APIからの移行] s[依存をplay-services-litertへ<br/>初期化でEnvironment取得<br/>CompiledModel.createに渡す] t[コンポーネントごとに段階移行可<br/>サイズ減は同梱版を全部外してから] r==>|の手順は|s r-.->|の注意は|t r-->|の行き先は|i u[Android LiteRT skill] u-->|で自動化できるのは|r v[NNAPI対応<br/>2024年に非推奨] w[2027年から削除される見込み<br/>GPU・NPUへ移行] i-.->|への移行を促される旧APIの例は|v v==>|は|w x[出荷済みアプリは動き続ける<br/>Play servicesのランタイムは<br/>古いSDKのアプリもサポート継続] w-.->|の一方で|x class a,c,d,e,i,m,n,o,p,q,r,u,v,w K class b,g,h,j,k,s,t,x S - 一言で言うと: ML KitとLiteRT(+ Google Play Services)でできることと、それで作る写真加工アプリ。 - LiteRT - Googleのon-device inference runtime。 - これがGoogle Play Servicesで使えるように。8MBのapkサイズが節約でき、Runtimeがアプリ間で1個で済む、Googleがアップデートできる、1.4倍GPUで走らせられて速くできる、API level 24から。 - LiteRTは250Kアプリで動いてるそう。 - Googleのアプリでも動いてる。YouTube shortsのエフェクトなど。 - オンデバイスAIの課題: パフォーマンス、いろんなハードウェア（数百のSoC）で動くか、apkサイズ、モデルトレインなどカスタマイズ - Turnkey on devices - Turnkey（すぐ使える）な道がML Kit。バーコード・テキスト・翻訳などすぐ使えるvision/languageのAPIで、モデルはPlay servicesで配られ、MLの知識はあまりいらない。 - ML Kitでできないことは、LiteRTで自分のモデルを持ち込む（カスタム）。両方を1つのランタイムで使える。 - LiteRT CompiledModel API ハードウェアアクセラレーションを抽象化したAPI - カメラエフェクトなどが実装できる。 - LiteRT in Google Play services - WearOSやAndroid Automotive OSでも動く。スマホのコンパニオンアプリ経由でなく、時計や車の上で直接モデルを動かせる。 - OS制限はある（Automotiveは Android 11 から、Wear OSは Wear OS 4 から） - どう実装するか - カメラフレームから人物のマスクをML KitのSelfie segmentationで作り、背景にはLiteRT Compiled Modelでカスタムのスタイル（画風変換）をかけ、それを合成して1フレームにする。 - litert_torch（AI Edge Torchの新しい名前）でPyTorchのモデルをLiteRT用（TF Liteファイル）に変換する - litert_quantizerで量子化して、小さく速くする - LiteRT CompiledModelかなり速くなったそう - 古いGPUの処理から1.4倍。 - CompiledModelでGPUかCPUか指定できる。CPUでいいケースもあるそう。 - play-services-litertのcom.google.android.gms.litert.LiteRtを使う。 - Interpreter APIとCompiledModelを混ぜてマイグレーションできる。サイズは増えたままになってしまうが。 - LiteRTのAndroid skillが出た。device-ai/litert でインストールできる。既存アプリのアップグレード、新規アプリの雛形作り、Play services版への移行をやってくれる。 - LiteRTのNNAPI対応(2024年に非推奨)は2027年から削除される見込みだそう。GPUやNPUのアクセラレーションに移行しよう。 - Play servicesのランタイムは古いSDKで作ったアプリも引き続きサポートするとのこと。 - developers.googleblog.com Unlock agentic capabilities in your app with ML Kit GenAI youtube.com %%{init:{"flowchart":{"nodeSpacing":50,"rankSpacing":110}}}%% flowchart TD classDef K fill:#e3f2fd,stroke:#1e88e5,color:#0d47a1 classDef S fill:#fafafa,stroke:#e0e0e0,color:#9e9e9e,font-size:12px a[ML Kit GenAI] b[High-level API<br/>要約・画像説明・音声認識] c[Direct access<br/>Gemini Nanoへのプロンプト] a-->|の一方は|b a==>|のもう一方は|c d[これまでの端末内AIは<br/>詐欺検出など短く単発のタスク] e[Gemini Nano 4<br/>Function Callingをネイティブ対応] d==>|からアプリ内エージェントへ進めるのは|e f[一部のフラッグシップで利用可<br/>AICore developer previewで試せる<br/>2027年初めに1億台の予定<br/>Function Callingは今preview版のみ<br/>Nano 4対応端末へ順次] e-.->|の状況は|f e==>|を使うAPIは|c g[Function types /<br/>Conversation history types] h[関数実行・履歴保存・ループ・<br/>ガードレールを自前で書く] c-->|に追加されたのは|g g-.->|だけだと|h subgraph i[Agentic flows API alpha] direction LR j[Agent<br/>指示・ガードレール] k[AgentRunner<br/>ループを実行] l[AgentEvents<br/>テキスト・ツール呼び出しをUIへ] end h==>|を肩代わりするのは|i m[AppFunctions] m==>|でツールを渡す先は|i n[KDocの説明でツール同士の<br/>つなぎ方をモデルに伝える] m-.->|のコツは|n o[Access level self→Android trusted<br/>で同じ関数をシステムエージェントへ<br/>Gemini経由は現在limited beta] m-->|は一度書けば|o subgraph p[単発かセッションか] direction LR q[runSingleTurnAsync<br/>1回の入力で複数ステップ<br/>setMaxTurnsで上限] r[getOrCreateSession<br/>旅行IDごとに履歴を継続<br/>複数ターンの会話] end k==>|の呼び方は|p s[例: 声で45ドルのタクシー代を<br/>経費に追加] q-.->|のデモは|s t[履歴を自分で管理したい<br/>マルチエージェント / クラウド併用<br/>独自の圧縮] i-.->|が向かないのは|t t-->|なら使うのは|c subgraph u[3つのtips] direction LR v[ツールを絞り<br/>説明を明確に] w[最大ターンの<br/>ガードレール] x[対応を確認して<br/>クラウドか通常UIへ<br/>フォールバック] end i==>|でエージェントを作るときの|u class a,c,e,j,k,m,q,r,v,w,x K class b,d,f,g,h,l,n,o,s,t S - 一言で言うと: ML Kit GenAI APIでAIエージェント機能を使う話。 - ML Kit GenAIはHigh-level tasks(サマライズなど)とダイレクトアクセスがある。 - これまでのオンデバイスの用途は、詐欺(scam)っぽいものの検出や通話の要約など、短く単発のタスクだった。今回はそこからアプリ内エージェントへ。 - early 2027には Gemini nano 4がたくさんのユーザーで利用できるようになる。 - MLKitのDirect accessにFunction types と Conversation history typesが追加になった。 - MLKitにAgentic flow APIが追加に。 - デモ: 旅行アプリで音声で「Mountain Viewまでのタクシー代45ドルを経費に追加して」と言うと、経費追加などのToolを渡されたGemini Nanoがテキストでなくfunction callを返して、経費が追加される。 val agent = Agent.builder() ... .setMaxTurns(5) .enableAppFunctions() .build() val runner = AgentRunner(agent) val prompt = content { text(...) } runner.runSingleTurnAsync(prompt).textTokens().collect {...} - singleTurn っていうのはユーザーのクエリが1回という意味で、その中でツールを何回も呼べる。 setMaxTurns()はそのループの上限。 - val session = runner.getOrCreateSession() でセッション作れる - 普通にセッション作ったりturnの数指定して、複数のtoolを一気に呼んだりできるみたい。 - github.com/android/ai-samples/blob/b8dfa1825ef1d9… - AppFunctionを一度書くと、アプリ内のAgentにも渡せるし、システムレベルのAgentにも渡せる。 - 3 tips - toolの数は絞ったほうが良い。(focused) - max turnのガードレールは設定しよう - availablityをチェックしてfallbackしよう Building reliable text editing experiences in Compose youtube.com %%{init:{"flowchart":{"nodeSpacing":50,"rankSpacing":110}}}%% flowchart TD classDef K fill:#e3f2fd,stroke:#1e88e5,color:#0d47a1 classDef S fill:#fafafa,stroke:#e0e0e0,color:#9e9e9e,font-size:12px a[value / onValueChange] b[StateFlowなど非同期と組むと<br/>IMEとタイミングがずれる] c[文字落ち・重複・カーソル飛び] d[TextFieldState] e[Compose 1.7でstable<br/>callback版は1.13でsoft deprecate] a==>|の問題は|b b-.->|の症状は|c b==>|を同期更新で解決するのが|d d-.->|の状況は|e f[TextFieldBuffer] g["edit{}でもらうmutableなbuffer<br/>操作は1回のeditにまとめる"] d==>|のtextは外から読み取り専用で、編集に使うのが|f f-.->|の使い方は|g subgraph t[変換] direction LR h[InputTransformation] i[OutputTransformation] end f==>|のAPIをそのまま使えるのが|t j[ChangeListで変更箇所を見て<br/>拒否・書き換え] k[電話番号のハイフンなど表示だけ整形<br/>オフセット変換は自動] h-.->|は|j i-.->|は|k subgraph p[状況で選ぶ] direction LR p1[自己完結: rememberTextFieldState] p2[兄弟UIも使う: 共通の親] p3[ロジックが要る: ViewModel] p4[VMをCompose非依存に保つ:<br/>UI側に持ちsnapshotFlowでVMへ] end d==>|の置き場所は|p q[UiStateのStateFlowに入れない] r[参照が変わらず入力が通知されない<br/>作り直すと選択・undoが消える] p3==>|のとき|q q-.->|の理由は|r l[Rich Text編集API<br/>Compose 1.12から] m[AnnotatedStringは不変で<br/>毎キー入力で作り直しになる] n["addStyle + ExpandPolicy<br/>InsideOnlyなど境界での広がり方"] f==>|に追加されたのが|l l-.->|が必要な理由は|m l==>|の中心は|n s[検索ハイライト: OutputTransformationで<br/>表示だけにstyleを当て、stateは変えない] u["**で太字化: InputTransformationで<br/>styleがstateに残る"] l==>|の使い方は|s l-->|の使い方は|u v[マークアップテキストライブラリ<br/>開発中の予告] w[Markdown対応<br/>インクリメンタルなパースと描画] l-->|の次に予告されたのが|v v-.->|の特徴は|w class a,b,d,f,h,i,p1,p2,p3,p4,q,l,n,s,v K class c,e,g,j,k,r,m,u,w S - 一言で言うと: TextFieldの新しいAPIとその実践的な使い方 - TextFieldStateを導入。 - textは外からはReadOnlyで、.edit{}を呼ぶとTextFieldBufferがもらえて、それはMutable。 state.edit { insert(5, ",") delete(..) select(...) } - など。setTextAndPlaceCursorToEndみたいな関数もある。 - Input transformationは入力がstateに入る前に割り込んで、ChangeListで変更箇所だけ見て書き換えたり拒否したりできる（数字以外を弾くなど）。 - OutputTransformationで簡単に電話番号の - を入れるようなのがかける(前はVisualTransformationで入力↔表示のオフセット変換を双方向で自分で書いていた。今は自動で計算してくれる) - TextFieldStateどこでもつか？ - 普通にTextFieldの近くにrememberTextFieldState()持つ。 - 送信ボタンを押したときなどにstateからtextを取って、lambdaで呼び元に渡していく。 - 他のコンポーネントでテキストデータが必要ならそこまでホイストする。 - ビジネスロジックでテキスト入力を扱うなら、TextFieldStateはViewModelで保持する。 - UiState（StateFlow）の中にTextFieldStateを入れるのは避ける。mutableなので内部の変更がStateFlowに通知されない。 - ViewModelに直接持つのが推奨。 - どうやってEditableなStyleなテキストを作るか？ Rich Text edit API。 state.edit { addStyle(SpanStyle(..., start = 0, end = ..., policy = ExpandPolicy.InsideOnly)) insert(0, "xxxx") } - ExpandPolicy.InsideOnlyでその中でテキスト追加したらSpanの範囲が増えたりする。 - サンプル - github.com/androidx/androidx/blob/androidx-main/c… - TextFieldで検索してるものをハイライトしたい時はOutputTransformationでテキスト検索して、そこにstyleを当てる - Jetpack Compose公式でマークアップテキスト(Markdownなど)の表示をサポートする新ライブラリを開発中みたい。予告の段階。 Type safe keep rules and DEX optimization youtube.com %%{init:{"flowchart":{"nodeSpacing":50,"rankSpacing":110}}}%% flowchart TD classDef K fill:#e3f2fd,stroke:#1e88e5,color:#0d47a1 classDef S fill:#fafafa,stroke:#e0e0e0,color:#9e9e9e,font-size:12px a[Google Playの新しい品質要件<br/>DEXの縮小・最適化・難読化が25%超] b[top appsの41%が最適化25%未満] c[リフレクション] d[広すぎるkeepルール<br/>ライブラリ同梱のものも] e[1つの悪いルールで<br/>最適化が大きく下がる] a==>|に対して|b b==>|の背景にあるのが|d c==>|への対処を安全側に倒して生まれるのが|d d-.->|の影響は|e f[codegenで避ける] g[任意依存・サブクラスの動的生成<br/>フィールド走査など残る場面] c==>|への第一の対処は|f f-.->|でも残るのは|g h["@Keep / 手書きの狭いルール"] i["@Keepはサブクラスに効かない<br/>手書きは書くのも保守も難しい<br/>どちらも忘れやすい"] g-->|に従来使ったのは|h h-.->|の問題は|i subgraph t[新しいツール] direction LR j[R8 Config Analyzer] k[Jetpack Keep] l[Android CLI analyze] end d==>|を見つけて直す手段は|t m[analyzeReleaseR8ConfigでHTML<br/>ルールごとの保持数・重複・未使用] n[最終DEX前の値なので<br/>Play Consoleの値とは一致しない] j==>|は|m m-.->|の注意は|n o[R8 skill] j-->|をエージェントから実行し要所を示すのが|o p[lintFixで推定できるリフレクション箇所に<br/>annotationを付ける] q[条件付きの狭いkeepルールを生成] r["plugin ID androidx.annotation.keep<br/>AGP 8.7以上・通常のconsumer rulesも出力"] k==>|は|p p==>|から|q k-.->|の導入と互換性は|r g==>|に使うのが|k s[Playと同じロジックでローカル解析<br/>JSONで回帰チェック] u[ライブラリの広すぎるルール<br/>keep ratioを確認] l==>|は|s l-->|はライブラリにも使えて|u v[新規テンプレートにpackage scope<br/>AGP 9.2の改善・9.3にAnalyzer統合] a-.->|の達成を助ける最近の改善は|v class a,b,c,d,f,g,j,k,l,m,p,q,s K class e,h,i,n,o,r,u,v S - 一言で言うと: R8とその最適化を助ける新しいツール - top appsの41%は、Google Playの品質要件の基準（最適化25%）を下回っているらしい。13%は既にその3倍を達成している。 - Google Playの新しい品質要件で、DEXの縮小・最適化・難読化が25%を超える必要がある（2月から適用）。 - 新規アプリのテンプレートにpackage scopeが入るようになった（最初から最低限の最適化がかかるように）。 - AGP 9.2のR8改善で、コルーチンのプリミティブが2倍速くなったらしい。 - analyzeReleaseR8Configタスク（R8 Config Analyzer）で、keepルールが縮小・最適化をどれだけ妨げているかをhtmlレポートで確認できる。 - Reflectionは基本的には避けて、codegenを使う。 - ただ必要な場合がある、optinal dependency、ライブラリがあるときだけ動くみたいなやつなど。 - その場合もできるだけruleを絞る。コンストラクタのみなど。 - @Keep annotationだとサブクラスに効かないなど柔軟ではないし忘れたりする。 - annotation.keep plugin（Jetpack Keep）を入れて lintFix を走らせると、リフレクションしているコードを解析して必要なannotationを付けてくれる。 - annotation.keep pluginでリフレクションが必要なところでR8のkeepルールを生成できる - x.com - android analyze apkpathで、Play Storeと同じロジックのDEXサイズ・最適化率がローカルで出る。jsonにもできるそう。 - jsonで回帰チェックを自動化できる。 - x.com Building type-safe deep links with Jetpack Navigation3 youtube.com %%{init:{"flowchart":{"nodeSpacing":50,"rankSpacing":110}}}%% flowchart TD classDef K fill:#e3f2fd,stroke:#1e88e5,color:#0d47a1 classDef S fill:#fafafa,stroke:#e0e0e0,color:#9e9e9e,font-size:12px a[Nav3 recipes] b[専用APIを先に作らず<br/>実装方法をコードで見せる] c[コピペが要るhelperは<br/>ライブラリへ卒業させる] d[Deep Link API<br/>Navigation 3 1.2] a-.->|の方針は|b a==>|から|c c==>|で生まれたのが|d e[Intent] f[DeepLinkRequest] g[UriDeepLinkMatcher] h[MatchResult] e==>|から作るのが|f f==>|を照合するのが|g g==>|が返すのは|h d==>|の入口は|f i[KMP対応・テスト用に手で作れる] f-.->|の利点は|i j["URIパターン sessions/{id}<br/>プレースホルダ名をキーのプロパティ名に合わせる"] k[Kotlin Serializationで<br/>型付きNavKeyに変換] l[Int・enumなどに変換できなければ<br/>マッチ失敗 / 既定値で任意引数] g-.->|に渡すのは|j g==>|の変換は|k k-.->|の効果は|l m["複数マッチは maxOrNull で最適な1件"] n["sessions/keynote が<br/>sessions/{id} より優先"] h==>|はComparableなので|m m-.->|の例は|n o[matcherはモジュールごとにDIで集める] g-->|の管理は|o subgraph p[ひどいURLへの対応] direction LR p1[DeepLinkSerializerを継承して<br/>文字列から型へ変換] p2[UriDeepLinkMatcherを継承して<br/>引数を前処理] end k-->|で足りないときは|p q[合成バックスタック] r["withBackStack { listOf(Home, it.key) }"] s[最適な1件だけ遅延で構築] h==>|から戻り先を含めて作るのが|q q==>|の書き方は|r r-.->|の利点は|s t[filterでaction・MIMEを先に除外<br/>StaticKeyDeepLinkMatcher<br/>RequestExtras] d-->|の他の機能は|t class a,c,d,e,f,g,h,k,m,q,r K class b,i,j,l,n,o,p1,p2,s,t S - 一言で言うと: Nav3 での DeepLinkのカスタマイズ含めた実装方法 - nav3 recipesはユースケースのためのAPIを作るのではなく、どうやって作るのかを見せている。 - API Design - IntentをDeepLinkRequestで受けて、URIパターンごとにMatcher（UriDeepLinkMatcher）を作って照合すると、どの画面に行くか（NavKey）が返ってくる。 - Navigation 3のDeepLinkでは、複数のパターンにマッチした場合、maxOrNull() で最も適切なものを選べる。 - 例えば sessions/keynote と sessions/{session} がある場合、より具体的な sessions/keynote が優先される。 - 文字列のパターンだけでなく、Kotlin SerializationでキーのInt・enumなどの型に変換できるかも見てくれる。変換できなければマッチ失敗。 - UriDeepLinkMatcherをオーバーライドして、matchロジックをカスタマイズできる。 - Base64やJSONが埋め込まれたひどいURLでも、match argumentsをoverrideして、Kotlin Serializationに渡す前に引数を前処理できる。 - Navigation 3のDeep Linkでは、詳細画面からHomeに戻れるようにバックスタックを構築できる。 - withBackStack { listOf(Home, it.key) } で、Deep Link先の画面だけでなく、戻り先のHomeも追加できる。 Scaling input interactions beyond the touchscreen with Jetpack Compose youtube.com %%{init:{"flowchart":{"nodeSpacing":50,"rankSpacing":110}}}%% flowchart TD classDef K fill:#e3f2fd,stroke:#1e88e5,color:#0d47a1 classDef S fill:#fafafa,stroke:#e0e0e0,color:#9e9e9e,font-size:12px a[タッチ以外の入力<br/>キーボード・マウス・トラックパッド・スタイラスなど] b[フォームファクタで入力を決めつけない<br/>アクセシビリティのためにも対応する] c[標準コンポーネントでそのまま動き<br/>必要ならカスタマイズできる] a==>|に対応すべき理由は|b a==>|へのComposeの方針は|c subgraph p[Pointer Inputの処理] direction LR p1[MotionEvent → PointerInputEvent] p2[InternalPointerEvent<br/>前回との差分] p3[Hit Test → Hit Path Tree] p4[座標変換 → PointerEvent配信] end c==>|を支える内部処理は|p q[3つのPassで配信] r[Initial: 親→子<br/>Main: 子→親 クリックなど<br/>Final: 親→子 スクロール開始でクリック取消] p4==>|は|q q-.->|の向きは|r s[ラップトップ型トラックパッド] t[ポインタ種別をtouchからmouseへ<br/>Compose 1.12] u[疑似指をpan・scaleイベントに変換<br/>カーソル下の要素にだけ送る<br/>pan 1.12 / scale 1.13] v[scrollable・transformableは<br/>Composeを更新するだけで対応] c==>|の最近の例が|s s==>|の改善は|t s==>|の改善は|u u-.->|の恩恵は|v w[Indirect Input] cx[スマートグラス側面の<br/>横長で細いタッチパッド] y[IndirectPointerEvent] z[primaryDirectionalMotionAxis] A[前後のスワイプをフォーカスの次・前への移動にする<br/>縦リストも横リストもそのまま動く] B[プラットフォームにもAPIを追加<br/>デバイス側が主軸を指定] cx==>|から生まれたのが|w w==>|の型は|y y==>|が持つのは|z z==>|で|A z-.->|のために|B C["Glimmer: onIndirectPointerGesture<br/>onSwipeForward / onSwipeBackward<br/>対象か子孫にフォーカスが必要"] w-->|をグラスアプリで扱うのは|C D[タッチと同じ形のテストAPI<br/>名前にIndirectが付く] w-->|のテストは|D s-.->|とは使い方が違うのが|w class a,c,cx,p1,p2,p3,p4,q,s,t,u,w,y,z,A K class b,r,v,B,C,D S - 一言で言うと: Jetpack Composeのポインタ入力の仕組みと、トラックパッドやXRグラスなどタッチ以外の入力への対応 - touchscreen以外のinputもあるという話。Accessibilityのためにもサポートするべきという話がある。 - Trackpadをどうサポートするか。ラップトップ型はカーソル操作に変換され、Compose側にはマウスのようなポインタとして、hoverや右クリックなども含むクリックがmotion eventで渡ってくる。 - Composeはどうやってinput eventをやるか？ - ComposeのPointer Inputの内部処理。 - MotionEvent → PointerInputEvent → InternalPointerEvent（前回イベントとの差分を保持）→ Hit Test → Hit Path Tree更新 → 座標変換 → PointerEvent配信。 - Hit Path Treeでイベントの配送先を管理し、3つのPassで処理する。 - Initial：親→子（先行処理） - Main：子→親（クリックなど通常のジェスチャー処理） - Final：親→子（スクロール開始に伴うクリックキャンセルなど） - ComposeのIndirect Input。 - Android XRのグラス側面のスワイプなど、画面上の座標を持たない入力に対応。 - IndirectPointerEventはPointerEventに似ているが、primaryDirectionalMotionAxisを持つ。 - グラス上の前後スワイプを、フォーカスの次・前への移動として扱う。縦リストでも横リストでもそのまま動く。 - Indirect Inputでは、入力デバイスの主な移動軸をInputDevice.ViewBehavior.getPrimaryDirectionalMotionAxis()で取得できる。 - Compose GlimmerではonIndirectPointerGestureのonSwipeForward / onSwipeBackwardでスワイプを処理できる。 - テストはperformIndirectPointerInput{ click(Center) }みたいな感じ。 Agentic coding: A roundtable with industry leaders youtube.com - 一言で言うと: AIでPRは増えたが成果につながるかはまだ分からない中で、レビューや仕組みづくり、コストをどうするかを各社のリーダーが議論 - 開発速くなってるか？PR増えてる。outcomeにつながるかはわかっていない。 - レビューどうする？ 十分に検証できる世界なら、それでも100%人がレビューするのか？という議論。Agentがレビューしたりする。Agentをレビュー内で使うなど。 - レビューには教育の役割もあるという話も。 - slopを防いで、いいコードをどう出すか。段々モデルは良くなっている。 - 良い入力からは良い出力が出るので、AIでアーキテクチャ理解や仕様を固めるなど上流から良くすれば、コードの質が上がりレビューも減る、という話。 - feature flag・blue/greenデプロイ・行動トラッキング・インシデントなどのデータや仕組みはもうあるけど、バラバラのシステムにあって、忙しすぎてまとめられていなかった。1つのトレースにまとめられれば、PRがそのままマージされても安全、という話。 - エンジニアはまだAIの仕組みが分からず魔法っぽく感じているので、リーダーが「チームをレベルアップさせるには何が必要か」を考えるのは良い。変化が速いので学び続ける時間も要る。 - 速くなったのは Spring Boot の更新のような近代化作業で、機能のデリバリーはあまり変わっていない らしい。エンジニアリングはそもそもボトルネックではなかった。 - 心配なのは技術的なミスより、ビジネス判断のミス。行単位ではなく、意図をレビューすべきでは という話。 - 野心を、インフラが支えられる規模に合わせる。 10倍になったら耐えられるか？を先に考える。 - AIのspend limitとかはある？ 去年は実験の年、今年前半は「reasonablyに使う」感じだったけど、9月からtoken limitができたらしい。セッションの健全さ（ターン数など）も計測している。 - エンジニアにコストについては教えてあげたほうが教育的に良い。 まとめ Android Dev Summit 2026、現地でAI系を中心に見ました。(Android CLIやDev Tool、AppStateなどのセッションはまだ見られていません。) 印象に残っているのは、ユーザーの行動が「アプリを直接使う」から「GeminiなどのAIエージェントを通して使う」へ変わってきているという話です。今回登場したConnected Appsはアプリやサービスの機能を Gemini などのエージェントに提供する仕組みです。Androidアプリ側からエージェントに機能を提供する(Android MCP/AppFunctions)ことも、サーバー側から提供することもできます。サーバーがあるアプリなら、さまざまなプラットフォームで使えるサーバーのMCPで実装するのが良いという話で、Androidの実装ではなく、Pythonでサーバー実装をするデモもありました。 では、Androidアプリは無くなるのか？ というと - Android MCP/AppFunctionsは端末にしかないデータやセンサーなどを扱うアプリのためのものなので、端末ならではの、AndroidアプリでしかできないことをAndroid MCP/AppFunctionsで実装し、提供していく方向はありそうです。 - アプリをインストールして使うのはまだ一般的なので、ユーザーと接する場としてのアプリはすぐにはなくならないと思っています。 - (あとあと解決されると思うのですが、現時点のConnected Appsは、仕様上、1つのConnected Appに対して、サーバーのMCPかアプリ(Android MCP/AppFunctions)を使うかを後から変えられない、US限定のPreview、などが重なっていて、プロダクションのアプリで実際に使うのはまだ難しそうです。) - アプリ側でAIを使う話もかなりGoogleは力を入れていると感じていて、例えば、ML Kit, Firebase AI Logic, LiteRT, ADKなどをGoogleは開発し続けています。 こういう動きを早めに知っておくことは、今後の判断に役立つと思います。エンジニアとして今後の戦略を考えるのは難しいところはあるのですが、Googleもまだアプリを十分に力を入れる価値があるプラットフォームと考えているように見えます。今後を見守っていこうと思います。

Bringing Google Maps to Friendly Meals with Firebase AI Logic: Web Architecture & Implementation Guide Original: codingcat.dev Bringing Google Maps to Friendly Meals with Firebase AI Logicmarks an important milestone for full-stack web and AI engineers building on Firebase and Google Cloud. Following the official announcement by Marina Coelho on theFirebase Blog(2026-07-28), this hands-on CodingCat.dev implementation guide breaks down how to adopt these capabilities in modern TypeScript, Next.js, SvelteKit, React, and Angular applications. A couple of months ago, I shared how I used Firebase AI Logic to build a hands-free, real-time cooking assistant for the Friendly Meals Android app. It was great for answering my cooking questions while I had my hands covered in flour, and for adding ingredients to my shopping list in a conversational style. But then s Why Bringing Google Maps to Friendly Meals with Firebase AI Logic Matters for Full-Stack Web Developers When evaluating every new Firebase release for our production web apps and Google Developer Expert (GDE) architecture reviews, the first question is always how it improves developer velocity, runtime security, and end-user latency in the browser and on the server.A couple of months ago, I shared how I used Firebase AI Logic to build a hands-free, real-time cooking assistant for the Friendly Meals Android app. It was great for answering my cooking questions while I had my hands covered in flour, and for adding ingredients to my shopping list in a conversational style. But then something happened the other night as I was cooking dinner: I didn’t have most of the ingredients I needed for a recipe, and my shopping list was huge. So I wondered: what if I could tap a button to find nearby stores with these ingredients? Checking closing times, distance, and parking inside the app is far more convenient than filtering through Google Maps manually. Read through to learn how I added spatial intelligence to Friendly Meals usingGrounding with Google Maps via Firebase AI Logic. The power of location-aware AI Firebase AI Logicprovides secure, client-side SDKs that let mobile and web apps talk directly to Google’s generative models without setting up complicated server-side architecture. With the addition ofgrounding with Google Maps, you can now link Gemini’s intelligence directly to Google’s massive database of over 250 million real-world places. By grounding Gemini’s responses with Google Maps data, the cooking assistant achieves two things: - Real-time data access:Recommendations for stores, markets, or restaurants are anchored to actual, existing businesses. The model knows current operational statuses, business hours, and location specifics (like address and parking information). - Geographic personalization:By biasing the request with the user’s current latitude and longitude, the assistant’s advice becomes highly localized, which is great when you want to display the results ordered by how near a store is to the user. How Friendly Meals implements Maps grounding Let’s dive into the code for the Friendly Meals Android app, written in Kotlin, and look at the key changes required to create the Store Finder feature. Just like other features in this app, I want to keep the Store Finder feature flexible without forcing users to update the app when I want to try a new AI model, or a new prompt. I can achieve that by storing these pieces of information in aprompt template, in the Firebase console: By using prompt templates, I’m storing my prompt, input schema, model configurations and tools server-side. This way, I’m not only able to update my prompt and configuration without releasing a new app version, but I’m also protecting my intellectual property by not exposing it client-side. To use the prompt template in my Android app, I only need to reference the template ID when making the API call, and pass in the parameters defined in the template configuration. The Firebase AI Logic API takes care of executing the call to the chosen Gemini model and returning the response to my app. This is done in thefindStoresfunction: suspend ingredients: latitude: longitude: currentTime: dayOfWeek: ): // Initialize the AI model with the Google Maps tool val tools toolConfig retrievalConfig latLng languageCode } ) ) return // Call the generative model and get the response text val templateId inputs INGREDIENTS_FIELD to ingredients. DAY_FIELD to dayOfWeek, TIME_FIELD to currentTime ) ) val // Make sure the JSON is clean by replacing potential JSON headers val . . . // Convert JSON object to an object of the type StoreFinderResult json. } Log. emptyList } } companion //Remote Config Keys private //Template input fields private private private } To give Gemini access to real-time maps data, I provideTemplateTool.googleMaps()to the model initialization blocks. That involves retrieving the user’s latitude and longitude, which enables the app to return a highly localized list of stores. I’ll dive into how you can extract latitude and longitude data on Android apps in the next section of this blog. Once the model is initialized, I call thegenerateContentfunction passing in the template ID and the input parameters: the list of ingredients in the shopping list, retrieved fromFirestore, and the current day and time, retrieved using theLocalDateTimeJava library. When I get a response from Gemini, I extract the text from this response (which should be in JSON format), and make sure the JSON is clean by replacing potential JSON headers. I then convert this “clean” JSON to an object that my codebase can understand:StoreFinderResult. This is the object that I use to populate theCompose UIthat you saw at the beginning of this blog, which is built with abottom sheetcomponent. Tobuild location-aware Android appsthat can extract latitude and longitude data, first I need toadd the playServicesLocation dependency, then add some permissions to theAndroidManifest.xmlfile: Then, when the user taps on the Store Finder button, I call theRequestMultiplePermissionsfunction, which handles the flow of requesting the user to grant permissions if they haven’t done so yet. Once the permission is granted, I extract the current location with thegetCurrentLocationfunction: // This is the primary entry point in Google Play services for accessing device location on Android val LocationServices. } // Launcher to request multiple runtime permissions and handle the result val contract ) { permissions // Check permission results and default to false if not present val val // Fetch location if at least one permission level is granted if coroutineScope. val val // Asynchronously request the most recent current location val . . if // Triggers the call to the AI model to find stores onSuccess } // Triggers UI message if location services are disabled showError } } } } // Triggers the system permission dialog for both fine and coarse location permissionLauncher. arrayOf ) And that’s all you need to do to perform a successful call to Gemini, grounding its response in real-time data from Google Maps! Going to production As always, make sure you are protecting your apps withFirebase App Checkbefore deploying them to production. App Check attests that incoming traffic originates from your untampered Android app on a legitimate device. It helps protect your backend from abuse, such as billing fraud, phishing, app impersonation, and data poisoning. Check out theApp Check documentationto learn more about it. Bring grounding with Maps to your apps By pairing client-side code via Firebase AI Logic with the data depth of Google Maps, you evolve your AI features to interactive spatial flows that can guide users in the physical world. Head over to theFriendly Meals GitHub repositoryto review the codebase in full. If you want to check specifically the changes introduced for this feature,check out this pull request. Production Web Architecture & Security Checklist Whether you are deploying onFirebase App Hosting, Cloudflare Workers, or Vercel, shipping AI features to production requires defense-in-depth across three layers: - Enforce Firebase App Check & Attestation:Protect your web endpoints, Cloud Functions, Data Connect GraphQL resolvers, and Firebase AI Logic calls against unauthorized replay or billing abuse usingFirebase App Check with reCAPTCHA Enterprise. - Validate Locally with the Firebase Emulator Suite:Run deterministic integration tests against local Firestore, Auth, Functions, and Data Connect PostgreSQL emulators before promoting schema or rule changes to production. - Keep Server & Client Boundaries Type-Safe:Use the modular Firebase Web SDK and generated TypeScript bindings so SSR frameworks like Next.js, SvelteKit, and Angular serialize state cleanly without hydration flickers. Watch Our Related Firebase Video Tutorial on YouTube Want to see how we architect and debug Firebase web applications live? Watch our related CodingCat.dev sessionFirebase SQL with Data Connectbelow, and make sure toSubscribe to CodingCat.dev on YouTubefor weekly full-stack web and AI deep dives: {% youtube N25khadfUag %} Resources, Official Docs & Related CodingCat.dev Guides - Primary Release Source:Bringing Google Maps to Friendly Meals with Firebase AI Logic on the Official Firebase Blog(published 2026-07-28 by Marina Coelho) - Official Firebase Documentation:Firebase Developer Docs & Web SDK Reference - Related on CodingCat.dev:Zero-flicker Firestore SSR with React - Related on CodingCat.dev:Triple-layer security for Firebase web apps - Related on CodingCat.dev:Firebase SQL with Data Connect - Related on CodingCat.dev:Build a Custom No-Code App in 90 Minutes Frequently Asked Questions (FAQ) What are the key capabilities introduced in Bringing Google Maps to Friendly Meals with Firebase AI Logic? Bringing Google Maps to Friendly Meals with Firebase AI Logic (announced 2026-07-28) enhances the Firebase platform for Firebase, Google Cloud, Web Dev, AI, TypeScript, Security workloads. A couple of months ago, I shared how I used Firebase AI Logic to build a hands-free, real-time cooking assistant for the Friendly Meals Android app. It was great for answering my cooking questions while I had my hands covered in flour, and for adding ingredients to my shopping list in a conversational style. But then something happened the other night as I was cooking dinner: I didn’t have most of the ingredients I needed for a recipe, and my shopping list was huge. Developers can review the official release notes on theFirebase Blogalongside the implementation patterns in this guide. How do web developers use Bringing Google Maps to Friendly Meals with Firebase AI Logic with Next.js, SvelteKit, React, or Angular? Web developers can integrate these features using the modular Firebase JavaScript/TypeScript SDK, Firebase Data Connect web bindings, andFirebase App Hosting. Always pair client-side SDK initialization with Firebase App Check and strict Security Rules, and test locally with the Firebase Local Emulator Suite before deploying. Where can I watch video tutorials on Firebase Web and AI development? You can watch our hands-on Firebase video walkthroughs on theCodingCat.dev YouTube Channel, includingFirebase SQL with Data Connect, and browse our complete Firebase tutorial archive on CodingCat.dev.