このシリーズでは、Android と Google Play の製品情報で、日本の皆さんに特に重要な記事を見やすくお届けするために、グローバルで発表された直近のブログ記事の URL を、1 つのブログ記事にまとめます。
*リンク先は英語の記事になります。お手数ですが Chrome ブラウザの翻訳機能などを使って、投稿を日本語でご確認ください。
Android
Telecom の最新アルファ版で、VoIP アプリの体験にネイティブな視認性を (Bring Native Visibility to Your VoIP App Experience with Telecom's Latest Alpha)
FotMob がクロスデバイスのディスカバリーを活用し、過去最高の Wear OS 導入数を記録した方法 (How FotMob leveraged cross-device discovery to score record Wear OS adoption)
Wear OS 7 の新機能 (What's New in Wear OS 7)
Android for Cars の新機能：プラットフォームの統合とプレミアムな体験の解放 (What's new in Android for Cars: Unifying platforms and unlocking premium experiences)
Android UI 開発は Compose ファーストへ (Android UI Development is Compose First)
Android Studio I/O エディション：Android デベロッパー ツール の新機能 (Android Studio I/O Edition: What’s new in Android Developer tools)
Android Performance Analyzer のご紹介：Android プロファイリングの次なる進化 (Introducing Android Performance Analyzer : The Next Evolution in Profiling for Android)
Unity、Unreal、Godot 向け Android XR の最新アップデート (Android XR Updates for Unity, Unreal, and Godot)
Android XR SDK のアップデート：デベロッパー プレビュー 4 のご紹介 (Updates to the Android XR SDK: Introducing Developer Preview 4)
拡大を続ける Android エコシステムに向けたアダプティブ開発 (Adaptive development for the expanding Android ecosystem)
Android XR デベロッパー カタリスト プログラムで未来を構築しよう — 今すぐ応募 (Build for the future with the Android XR Developer Catalyst Program — Apply now!)
Android CLI がついに安定版 1.0 に：あらゆるエージェントを使った Android 開発を加速 (Android CLI Now Stable 1.0: Accelerate developing for Android using any agent)
Google TV でのアプリのディスカバリーとエンゲージメントの向上 (Increasing app discovery and engagement on Google TV)
Google AI Studio でネイティブ Android アプリを構築する (Build native Android apps in Google AI Studio)
Google I/O で Android デベロッパーが知っておくべき 17 のこと (17 Things to know for Android developers at Google I/O)
Google I/O ‘26：インテリジェンスな体験を構築するための Android 上の AI に関する主要アップデート(Top AI on Android updates for building intelligent experiences from Google I/O ‘26)
Google Play
I/O 2026：Google Play の新機能 (I/O 2026: What's new in Google Play)
日本は世界でも有数のアプリ / ゲーム市場を誇りますが、持続的なビジネス成長と多様化を実現するために、海外市場への進出が重要な戦略として、日本国内の開発者の大きな関心を集めています。Google Play は世界 190 ヶ国以上で展開するグローバル エコシステムです。私たちは、海外市場での飛躍を志す日本の開発者と世界中のユーザーを繋げる架け橋となるべく、今日 Google Play Accelerator Japan の募集開始を発表します。
本プログラムは、Android アプリを基盤とし、海外市場でのさらなる展開を目指す日本の開発者の成功を支援します。活気あるゲーム / アプリ エコシステムを育成するための新しいプログラムとして、世界基準のプロダクトを構築するために必要なツール、メンターシップ、そしてテクノロジーを提供していきます。
本プログラムは、10 週間に及ぶ短期集中型のアクセラレーター プログラムです。Google のエキスパートによるワークショップや個別メンターシップに加え、最先端の Google AI 活用支援、戦略的なビジネスサポートを提供します。
ワークショップ および セミナー：Google Play のデータを活用した市場分析、海外マーケティングの実践、そして実績を持つ開発者による事例共有
メンターシップ：Google 社内外のエキスパートによるグローバルなネットワークへのアクセス
Google AI 導入支援：Google の最新 AI テクノロジーを製品スタックに統合するためのアドバイスとサポート
ビジネス支援：リーダーシップ、「Go-to-Market」戦略などに関する実践的なトレーニング
ステージ：モバイルゲーム / アプリの海外展開において初期段階（展開を始めて時期が浅い、もしくは、海外展開をすでに実施しているものの海外でのユーザーベースや収益がまだ小さい）であること
技術：高い技術力を持ち、Google Play、Android、Google AI などのツールを活用している、または活用予定であること
市場性：今後の展開ポテンシャルを持ち、海外で展開するスケーラブルなゲーム / アプリ製品アイデアと成長モデルを構築していること
所在地：日本に本社を置き、登録されている法人、もしくは個人開発者
要件：Google Play に公開済みのゲーム / アプリがあり、すべてのポリシーを遵守していること、もしくは、プログラムを通じてゲーム / アプリを開発予定であること
コミットメント：CEO、CTO、または事業責任者など、ゲーム / アプリ開発における意思決定者 1 - 2 名がプログラムの全セッションに参加できること
世界市場を見据えた次なるステージへ。皆さまの応募をお待ちしております。
申し込み締め切り：2026 年 7 月 5 日
プログラム開始 ：2026 年 9 月
卒業式 / デモデイ：2026 年 11 月
応募はこちら： https://goo.gle/play-accelerator-japan
このシリーズでは、Android と Google Play の製品情報で、日本の皆さんに特に重要な記事を見やすくお届けするために、グローバルで発表されたブログ記事の URL を、1 つのブログ記事にまとめます。
* リンク先は英語の記事になります。お手数ですが Chrome ブラウザの翻訳機能などを使って、投稿を日本語でご確認ください。
Gemini 3 Flash で、アプリをよりスマートに進化させよう (Build smarter apps with Gemini 3 Flash)
モバイル専用からアダプティブの時代へ : 2025 年版アプリ開発の重要アップデート 3 選 (Goodbye Mobile Only, Hello Adaptive: Three essential updates from 2025 for building adaptive apps)
Media3 1.9.0 : 最新アップデートと新機能の紹介 (Media3 1.9.0 - What’s new)
Now In Android #123 (Now In Android #123)
Android Studio で Gemini を活用し Ultrahuman の新機能リリースを 15% 高速化 (Ultrahuman launches features 15% faster with Gemini in Android Studio)
Google Devs Japan の X (旧 Twitter) をフォローして、今後のアップデートをお見逃しなく！
毎月 数十億人もの人が Google Play ストアを訪れています。そして、これらの人々は、世界中のあらゆるバックグラウンドを持つ、大小さまざまな企業や個人の方々が開発した数百万ものアプリやゲームを Google Play ストア上で探しています。#WeArePlay (英語) は、このようなアプリやゲームのビジネスを構築する開発者の皆さんをご紹介する取り組みで、世界中 (英語) から毎月、さまざまな開発者の創業ストーリーを特集しています。 2022 年の夏には、アメリカ合衆国 (英語) をバーチャルツアーで回り、全 50 州のストーリーを紹介しました。続いて数か月前にはインド (英語) 、数週間前にはヨーロッパ (英語) の各国の開発者のストーリーを紹介しました。
そして本日、日本の新たな開発者の皆様のストーリーを公開します。第一弾として本日、中部、近畿、中国 / 四国地方のストーリーを公開しました。また今後、東京（8 月中旬）、九州 / 沖縄（9 月下旬）、北海道 / 東北（10 月下旬）、東京を除く関東（12 月上旬）と段階的に公開し、最終的には全国から合計 49 の開発ストーリーをご紹介予定です。
こちらのブログでは、本日公開された 21 のストーリーから３つをご紹介します。
まずはじめに、愛知県名古屋市の常川 友樹さんをご紹介します。東京から故郷の名古屋に戻った常川さんは、地元に新しい産業を興し、雇用を創出する会社を立ち上げたいと考えていました。幼い頃からゲームが好きだったことから、アプリやゲームの企画、開発および運営を行う、ワンダープラネットを設立しました。最初のヒット作『クラッシュフィーバー』は、鮮やかなアニメーションで描かれるパズルゲームで、仲間と一緒にプレイでき、チャット機能も備えています。従来のゲームにはなかった斬新な要素を次々に取り入れたことでファンを獲得し、世界的な人気を博しています。
次に、長野県佐久市の坂本 昌彦さんです。福島県南会津郡に住んでいた医師、坂本さんは、子供の診察のために遠方から苦労して医療機関を受診しにくる保護者の存在に気づきました。そこで地方の保育園を訪問し、症状や受診のタイミングを教える活動を始めます。その後、長野県佐久地域でも同様の活動を始め、この情報に誰でもアクセスできるようにするため、仲間とともに『教えて！ドクタープロジェクト』を立ち上げました。プロジェクトが提供するアプリでは、子供の体調の症状検索や、受診の目安、災害時の哺乳瓶の消毒方法など、子育てをする方のための情報を提供しています。
そして最後に、兵庫県神戸市の岡本 圭司さんです。スノーボードに情熱を燃やし、プロのスノーボーダーにまで上り詰めていた岡本さんは、滑走中の事故に遭い脊髄を損傷し、二度とスノーボードができないかもしれないという診断を受けました。将来の展望が見えず絶望していた岡本さんが、滑れない自分に何ができるだろうと始めたのが、スノースポーツ愛好家が全国のスキー場の地図にアクセスし、滑った距離などの記録ができるアプリ『yukiyama』の立ち上げです。その後『yukiyama』の成長とともに岡本さんのスポーツ人生も進展し、今ではパラリンピックに出場しています。
『YAMAP / ヤマップ 登山地図アプリ』の創業者である、春山 慶彦さんのストーリーの紹介動画も公開しています。こちらも併せてお楽しみください。
*春山さんのストーリーは、#WeArePlay のウェブサイト上で 2023 年 9 月に公開予定です。
本日公開されたすべてのストーリーは g.co/play/weareplay-japan でご覧いただけます。今後も 2023 年 12 月頃まで毎月新しいストーリーが公開されますので、ご期待ください。
Written by Tamao Imura - Google Developer Marketing Manager, Japan
この記事は Sachiyo Sugimoto による Android Developers Blog の記事 " Developer-Powered CTS (CTS-D) " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android の強みは多様なデバイスからなるエコシステムにあります。世界中の数十億のユーザーが、市場に出回っている 2 万 4,000 種類以上のデバイスを使っています。Android では、デバイスが一貫性のある安定したアプリ環境を提供し続けることができるように、初期リリースのころから Android 互換性プログラムを推進しています。
このプログラムで重要な位置を占めるのが、互換性テストスイート (CTS) です。CTS は 200 万件以上のテストケースのコレクションで、デベロッパーのアプリがさまざまなデバイスで確実に動作し、ユーザーに一貫したアプリ体験を提供できるようにするために、Android デバイスの実装をチェックします。
デバイス メーカーは、開発プロセス全体で自社デバイスに対して CTS を実行し、早い段階でバグを見つけて修正しています。このスイートは、長年にわたって拡張が重ねられ、新しいテストケースが追加されています。現在の CTS には 200 万件を超えるテストが含まれていますが、その数はまだ増え続けています。Android が進化するにつれて網羅すべき新しい領域が増えており、まだ十分にカバーできていない部分もあるため、それを埋めるテストを追加する作業が続いています。
ほとんどの CTS テストは Android エンジニアが記述していますが、アプリ デベロッパーには実際のデバイスの互換性問題に対して独自の視点があることも事実です。そこで、アプリ デベロッパーからの優れた提案を活用して CTS を拡張するため、デベロッパーの皆さんが作成して実行できる CTS-D という新しいテストスイートを追加します。
CTS-D は、アプリ デベロッパーの皆さんに開発に加わっていただく斬新な CTS モジュールであり、アプリ デベロッパーが現場で目にしている問題点に重点を置いたものです。デベロッパーはテストケースを作成して CTS-D に提供することで、そういった問題を見つけやすくすることができます。また、自分で CTS-D スイートを実行して互換性を検証することもできます。長期的には、Android デベロッパー コミュニティと密接に連携して CTS-D スイートを拡張していく予定です。
すでに多くの皆さんが独自のテストを作成し、さまざまなデバイスで互換性の検証をしていることは承知しています。そこで、皆さんと連携してそのテストを AOSP に組み込みたいと考えています。コミュニティからの提供を受けた最初のテストスイートは、こちらの CTS-D の初回コミットから確認できます。
つまり、CTS-D を通してこういったテストを広く利用できるようにすることで、デバイス メーカーやアプリ デベロッパーが問題を効率的に特定して共有できるようにします。
CTS-D はオープンソースで、AOSP で公開されています。そのため、すべてのアプリ デベロッパーが CTS-D を検証ツールとして使うことができます。CTS-D によって、アプリ デベロッパー、デバイス メーカー、Google 間とのそれぞれのコミュニケーションのオーバーヘッドを最小限にとどめ、問題を効率的に解決できるようになります。
あるデバイスが CTS-D テストに合格しなかった場合は、こちらの Issue Tracker テンプレートを使って問題を報告してください。報告されたデバイスで問題を検証した後、その解決に向けてパートナーと連携して作業を進めます。デバイス メーカーの皆さんにも、CTS-D を使って問題を見つけ、対策することを強くおすすめします。
CTS-D について何かアイデアをお持ちの方は、テストコードを AOSP に提供する前に、こちらの Issue Tracker テンプレートを使ってテスト提案をお送りください。Android チームが皆さんの提案を確認し、テストの適格性を検証します。現在、私たちの一番の関心は、電源管理領域のテストケースを追加することにあります。
CTS と同じく、新しい CTS-D のテストケースも適格性要件を満たす必要があり、実行できるのは以下の内容のみに限られます。
CTS-D についてもっと詳しく知りたい方は、こちらのチュートリアルをご覧ください。CTS-D に貢献する方法や、CTS-D の使い方を説明しています。なお、新しい CTS-D テストケースの審査には時間がかかる可能性がありますので、ご了承ください。皆さんが CTS-D を試してくださることを期待しています。Android の体験向上のために、ぜひご協力ください。
この記事は Jacob Lehrbaum による Android Developers Blog の記事 " Working Towards Android App Excellence " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
すばらしいアプリ体験は、ビジネスにもすばらしい成果をもたらします。実際、Google Play に5 つ星の評価を残した Android アプリユーザーの約 3 分の 1 が、アプリ体験の質*1つまり、スピードやデザイン、ユーザビリティに触れています。Google では、すべてのデベロッパーが優れたアプリの開発を実現し、ユーザーの獲得、維持、収益化を果たせるようなサポートを提供したいと考えています。
では、「優れたアプリ」とは何でしょうか。これは遠い目標のように聞こえるかもしれませんが、多くのアプリでも手が届くところにあります。その第一歩となるのは、ユーザーにフォーカスし続けることです。具体的には、直感的なユーザー エクスペリエンスでアプリの主要機能にできる限り早く到達できるようにすることです。しかし、これはまだ始まりに過ぎません。優れたアプリにはすべての画面や操作に一貫性があり、使うデバイスによらず快適に動作します。アプリ開発に携わっているあらゆるメンバーがアプリ体験に集中すれば、優れたアプリの開発が実現できます。
優れたアプリの開発を阻むものの 1 つが、曖昧で不明確な責任分担です。クラッシュや読み込み時間など、アプリの質を測る主な指標の中には、エンジニアリング チームなどの社内の 1 グループの責任であると見なされるものがあります。しかし、業界のトップクラスの組織の方々にどのようにして優れたアプリの開発を実現しているか聞いたところ、*2エンジニアリング、デザイン、プロダクト、ビジネスの各チームが共通の目的に向かって連携する、部門間の協力的なアプローチが重要であることが明確になりました。
では、優れたアプリ開発のための裏側にある内部的なベスト プラクティスはどのようなものでしょうか。
ビジネス側の立場に立って「競合他社のアプリは私たちのアプリよりも速いので、読み込み時間を 5 秒から 4 秒に短縮する必要がある」と私から言えるので会話がよりスムーズです。クロス プラットフォーム アプリのソフトウェア エンジニア
ビジネス側の立場に立って「競合他社のアプリは私たちのアプリよりも速いので、読み込み時間を 5 秒から 4 秒に短縮する必要がある」と私から言えるので会話がよりスムーズです。
クロス プラットフォーム アプリのソフトウェア エンジニア
優れたアプリは、ビジネスの成果につながります。新機能の追加はすばらしいことですが、それでアプリの起動時間が遅くなったり、デバイスの容量を使いすぎたりすると、アプリの使用頻度が減り、やがて削除される結果をうみます。多くの場合、エンジニアは品質問題がビジネスの成果に与える影響を定量化することで、全社的に品質を重視する体制を構築しています。具体的には、次の方法で定量化しています。
機能（ユーザー ジャーニーの各ステージ）を担当するチームを編成している企業は、サポートするそれぞれのオペレーティング システム全体で一貫した操作を提供し、新しいアプリや機能を市場に投入するまでの時間が短くなり、すべてのお客様に優れたアプリ体験を提供できる可能性が高くなります。多くの場合、このようなチームは、エンジニア、マーケティング、UX、プロダクトなどの機能を横断するグループです。そして、あらゆるデバイスやプラットフォームで、機能やユーザー ジャーニーのステージ*3を成功させる責任を担います。この構造により、優れた体験や機能レベルが実現できるだけでなく、機能領域を超えた統一目標ができます。また、縦割りを減らして、特定の目標に集中的に対処することにもつながります。
ビジネス目標を重視するチーム構成により、ユーザーに対するフォーカスが高まる
ユーザーの大半が特定の種類のデバイスを使っている場合、主なデバイスとして同じスマートフォンやタブレット、スマートウォッチを使えば、ユーザーがどのような体験をしているか理解が深まるでしょう。特にこれが当てはまるのは、多くユーザーの日々の体験に影響を与える意思決定が求められる組織の経営幹部です。たとえば、Duolingo はこれを自社の DNA に組み込んでいます。ユーザー ベースの大部分と同様の環境を作り出すために、CEO も含む、すべての Duolingo の社員は、エントリーレベルの Android デバイスのみを使っているか、あるいは使える状態にあります。
ビジネスを成長させるうえで、品質および優れたアプリの開発に対するユーザー中心のアプローチは欠かせません。優れたアプリの開発を実現する方法を詳しく学びたい方は、実用的なヒントを含むケーススタディをご覧ください。また、Android App Excellence (英語) のページにアクセスし、ぜひ App Excellence Summit に参加してください。（事前登録制です）
今後のブログ投稿では、優れたアプリの開発を実現する 2 つの要素について詳しく取り上げる予定です。具体的には、アプリ パフォーマンスとそれによるユーザー行動への影響、そして複数のデバイス間のシームレスなユーザー エクスペリエンスの開発です。こちらのページから Android デベロッパー向け ニュースレターに登録すると、次号の発行時に通知が届き、Android チームからの最新ニュースや知見を得られますので、ぜひご登録ください。
注
1. 2021 年の Google Play 内部データ
2. 2021 年の Google App Quality Research
3. アプリを使ううえで、それぞれのユーザーが体験する一連の手順を「ユーザー ジャーニー」と呼びます。ユーザー ジャーニーのステージの例として、インストール、オンボーディング、エンゲージメント、リテンションなどがあります
Reviewed by Tamao Imura - Developer Marketing Manager, Google Play
この記事は Sara N-Marandi による Android Developers Blog の記事 "What’s new in Android Privacy" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
人々は、自分にとって最も大事な個人情報や機密情報を信頼して託すことができる OS とアプリを求めています。プライバシーは、Android の製品理念の中核です。Google I/O の「What’s new in Android Privacy」セッションでお話しした通り、Android 12 は、プラットフォームをさらにいっそうプライベートなものにすることで、この既存の基盤を広げ続けています。
このリリースによって、ユーザーは、アプリにアクセスされるデータに関する透明性を確保でき、かつ、シンプルなコントロールで情報に基づく選択ができるようになります。Android は、アプリが自らが提供する機能で必要なデータにのみアクセスするように、アクセス権限のスコープを小さくすることにも投資しています。ユーザーのプライバシーを保護するために私たちが Android 12 で行った、これらの重要な変更について見てみましょう。
プライバシー ダッシュボード：ユーザーの皆さんからはアプリがどのようなデータを利用しているのか知りたいというご要望をよく受けています。新しいプライバシー ダッシュボードでは、位置情報、マイク、カメラへの過去 24 時間のアクセス記録を、シンプルでわかりやすいタイムラインで確認できます。また、Android 12 に搭載された新しいパーミッション インテント API により、アプリのデータ使用に関するより詳細な情報を共有することができます。プライバシー ダッシュボードは、Beta 2 から利用可能になります。
デベロッパーの皆さんには、現在のアプリやゲームのコードを見直し、サードパーティ製 SDK を含め、データへのアクセスの必要性を把握し、すべてのアクセスが正当な利用方法か確認することをお勧めします。これをサポートするために、Android 11 にデータアクセス監査 API を追加し、現在のデータアクセスを簡単に監視できるようにしました。この API を使用してコードのどの部分が個人データにアクセスしているか追跡することで、コードのマッピングを解明できます。プライバシー ダッシュボードは Android 12 Beta 2 でお試しいただけます。
図 1.プライバシー ダッシュボードと過去 24 時間の位置情報アクセス タイムライン
マイクおよびカメラ インジケータ：Android 12では、マイクとカメラへのアクセスに透明性を持たせています。今後は、アプリやゲームがマイクやカメラの映像にアクセスしたことを、ユーザーはリアルタイムで確認できます。また、ユーザーは、クイック設定で自分のデータにアクセスしているアプリを確認でき、不審なアクセスがあった場合は、アプリの許可ページに素早く移動して、許可を取り消すことができます。
デベロッパーはマイクやカメラの使用方法を見直し、アプリやゲームからの予期せぬアクセスを積極的になくす必要があります。例えば、ユーザーがアクセスを必要とする機能をクリックする前に、アプリがこれらのセンサーにアクセスしないようにしてください。マイクとカメラ インジケータは、Android 12 Beta 2で試すことができます。
図 2.マイクおよびカメラ インジケータとトグル
マイクおよびカメラ トグル：カメラにステッカーを貼ったり、携帯電話にオーディオブロッカーを取り付けたりしている人を見たことがあるかもしれません。Android 12では、ユーザーがアプリによる端末のマイクとカメラへのアクセスを迅速かつ簡単に遮断できる 2 つの新しいコントロール機能を導入します。ユーザーの安全性を確保するため、緊急通話は対象外となります。
ユーザーがセンサーをオフにしているにもかかわらず、アクセス許可を得ているアプリまたはゲームがマイクやカメラにアクセスを試みると、そのアプリやゲームの機能を使用するためにはセンサーをオンに戻す必要があることを知らせるメッセージが表示されます。アプリがアクセス権限のベスト プラクティスに従っている場合、トグル状態を組み込むために特別なことをする必要はありません。マイクおよびカメラトグルは、Beta 2 でお試しいただけます。
おおよその位置情報：過去 2 回のリリースにおいて、私たちは位置情報へのアクセス権限を細分化しました。まず、バックグラウンド アクセスとフォアグラウンド アクセスを分離しました。次に、「今回のみ」のオプションを追加して、バックグラウンド位置情報へのアクセスをさらに制限できるようにしました。ユーザーは積極的にこれらのコントロール機能を活用し、より頻繁に選択するようになっています。このオプションが与えられたユーザーは約 80% の割合で、フォアグラウンドの位置情報へのアクセス許可を選択しません。
Android 12 では、ユーザーが自分の位置情報の共有方法と共有先をさらにコントロールできるようになり、アプリやゲームへ提供される位置情報の精度について、「おおよその位置情報」を選択することで、明確に選択できるようになります。
デベロッパーの皆さんは、ご自身のアプリやゲームの位置情報の利用方法を確認し、その機能を提供するにあたってユーザーの正確な位置情報が必要ない場合は ACCESS_COARSE_LOCATION をリクエストすることをお勧めします。また、ユーザーが位置情報の精度を下げることも想定しておく必要があります。ユーザーがおおよその位置情報を選択した場合でも、アプリが動作することを確認してください。おおよその位置情報は、Beta 1で試すことができます。
ACCESS_COARSE_LOCATION
図 3.「おおよそ」と「正確」の選択肢がある位置情報アクセス権限リクエスト ダイアログ
クリップボード読み取り通知：クリップボードにコピーされたコンテンツには、ユーザーがよくコピーするメール、住所、パスワードなどの機密情報が含まれている可能性があります。Android 12 では、アプリがクリップボードから読み取るたびに、ユーザーに通知します。アプリが getPrimaryClip() をコールするたびに、画面下部にトーストが表示されます。クリップボードのデータが同じアプリから送られてきた場合は、トーストは表示されません。初回のコールで getPrimaryClipDescription() をチェックして、クリップボードのデータのタイプを調べることで、アクセスを最小限に抑えることができます。推奨されるベスト プラクティスは、ユーザーがアクセスの理由を理解している場合にのみ、クリップボードにアクセスすることです。クリップボード読み取り通知は Beta 2 でお試しいただけます。
getPrimaryClip()
getPrimaryClipDescription()
近くのデバイスを探す権限：Android 12 では、位置情報を使わない「近くのデバイスを探す権限」に新しいランタイムアクセス権限を追加することで、データへのアクセスを最小限にします。これまで、時計などのアプリやヘッドフォンを使うアプリやゲームは、ペアリングする近くの Bluetooth デバイスをスキャンするために、位置情報へのアクセス権限をリクエストしていました。これが原因で混乱が生じ、必要ではないときに位置情報データへのアクセス権限を与えてしまう、というお声がありました。Android 12 をターゲットとするアプリでは、デバイスをペアリングするなどの利用方法で、正確な位置情報へのアクセス権限から、近くのデバイスの検出を切り離すことができます。そのためには、新しい BLUETOOTH_SCAN 権限を使用して、usesPermissionFlags=neverForLocation を宣言します。デバイスがペアリングされると、アプリは新しい BLUETOOTH_CONNECT アクセス権限を使用して、そのデバイスと通信できます。なお、位置情報を取得するために Bluetooth スキャンを使用するアプリやゲームは、引き続き位置情報へのアクセス許可が必要です。近くのデバイスを探す権限は、Beta 1 で試すことができます。
BLUETOOTH_SCAN
usesPermissionFlags=neverForLocation
BLUETOOTH_CONNECT
アプリの休止状態（ハイバネーション）：昨年、Android に権限の自動リセット機能を追加しました。アプリが一定期間使用されなかった場合、Android が自動的に、ユーザーのデータにアクセスできないようにしますが、過去 14 日間で、850 万のアプリの権限がリセットされました。今年、権限の自動リセットをさらに発展させ、長期間使用されなかったアプリを自動的に休止状態に切り替え、デバイスのストレージ容量、パフォーマンス、安全性をより改善する機能を導入します。システムは、ユーザーが以前に許可した権限を取り消すだけでなく、アプリを強制停止してメモリやストレージ、その他の一時リソースを解放します。ユーザーは、アプリを起動するだけで、そのアプリを休止状態から戻すことができます。アプリの休止状態は Beta 1 でお試しいただけます。
Android 12 には、今までで最も野心的なプライバシー リリースが含まれています。これまで、デベロッパーの皆さんへの影響を考慮しながら、プライバシーを最優先にしたプラットフォームを構築するために、デベロッパー コミュニティの皆さんと連携してきました。皆さんからのフィードバックとご支援にお礼申し上げます。今回の変更点については、デベロッパー Web サイトをご覧ください。
Reviewed by Yuichi Araki - Developer Relations Team and Tamao Imura - Developer Marketing Manager, Google Play
今年の Google I/O はいかがでしたか？まだチェックしていない方は忘れずに Google 基調講演、デベロッパー基調講演、What's new in Android の 3 つのセッションをぜひご覧ください（※ 3 つとも日本語字幕対応）。美しいリップル（波紋）効果やストレッチ オーバースクロールを含む Android 12 Beta 1 、7 月に 1.0 の安定版になる Jetpack Compose、Material You の発表、ベータ版になった Android Studio Arctic Fox、Android デベロッパーに最も使われている言語である Kotlin（トップ 1,000 アプリの 80% が使用）や、Jetpack ライブラリがトップ 10,000 アプリのうち 84% 以上で使われている現状などをすべて確認できます。
まだご覧になっていない方は、ぜひご覧ください。また、この記事では皆さんが見逃してしまったかもしれないニュースをご紹介しましょう。今年の I/O のセッションはすべて日本語字幕に対応していますので、ぜひ切り替えてご覧ください。
What’s new in Jetpack セッションとブログ記事（英語）の要点は、CameraX、Hilt、Paging 3、ConstraintLayout、MotionLayout、Security Crypto、そして Fragment ライブラリが安定版に移行したことです。DataStore と Compose は現在ベータ版です。そして、Jetpack に以下の新しいライブラリが加わります。
さらに、WorkManager の新バージョンで現在アルファ版の 2.7 は、Android S SDK がターゲットになっており、プラットフォームの新しいフォアグラウンド制限が追加でサポートされています。詳しくは、Effective background tasks on Android セッションをご覧ください。
また、Navigation ライブラリを使っている方は、最新のアルファ版で複数のバックスタックがサポートされているので、ご確認ください。
Jetpack Compose が 7 月に 1.0 の安定版になるので、誰もが心躍らせていることでしょう。しかし、Compose を採用するときに、望まないのであれば、アプリのアーキテクチャを変更する必要はないことはご存知でしょうか。詳しくは、Using Jetpack libraries in Compose のセッションをご覧ください。Compose は、Navigation、Kotlin フロー、Hilt など、特に人気のあるライブラリに組み込めるようになっています。
さらに、Compose ではマテリアル デザインの実装も提供されます。その機能を活用する方法については、Build beautiful Material Design apps with Jetpack Compose セッションをご覧ください。
2 つの新しい Codelab も公開されています。Compose Navigation と Compose のテストです。Compose について体系的に学習する場合は、こちらのラーニングパスとワークショップをご覧ください。初めての Compose アプリを構築する方法を動画形式で基礎から説明しています。
Android 12 の最初のベータ版には、Android 5.0 でマテリアル デザインが導入されて以降、最大のデザイン変更が含まれています。これには、システムのテーマを使ってウィジェットに適用するダイナミック カラーなど、アプリ ウィジェットの動作の仕組みと外観の大幅な更新が含まれています。詳しくは、Refreshing widgets セッションをご覧ください。
また、システム全体にストレッチ オーバースクロール効果が新しく導入されますが、これは 1 つのスクロール コンテナにしか適用されないので、アプリの動作がどのようになるかを確認しておきましょう。
Android 12 で Bluetooth デバイスをスキャンするアプリは、neverForLocation 属性付きの新しい BLUETOOTH_SCAN パーミッションがあれば、位置情報パーミッションは必要なくなります。これにより、アプリの煩雑さが軽減されるだけでなく、LOCATION パーミッションが必要なアプリの数も減ることになります。
neverForLocation
LOCATION
位置情報と言えば、FINE_LOCATION パーミッションをリクエストした場合でも、ユーザーはアプリにおおよその位置しか渡さないように設定できるようになります。
FINE_LOCATION
Beta 2 に導入する予定のたくさんの新しいプライバシー機能についてもお知らせしました。ユーザーに表示されるプライバシー ダッシュボード、新しいマイクとカメラのインジケーターと切り替え機能、クリップボード読み取り通知などです。Android 12 におけるプライバシー関連のすべての変更については、What’s new in Android privacy セッションをご覧ください。
今回のベータ版には、パフォーマンス クラスも導入されています。これは、要求の厳しいユースケースや高品質のコンテンツをサポートできるデバイス向けの一連の機能で、現在は主にメディア機能を対象としています。
Android 12 Beta 1 は、エミュレータ、Pixel 3 以降のデバイス、またはデバイス パートナーが発売しているデバイスの一部で試すことができます。
たくさんの新機能が搭載された Android Studio Arctic Fox が Beta チャンネルで公開されています。Compose のサポート、Compose 開発を加速させるすばらしいツール、Layout Inspector の Compose サポート、組み込みのユーザー補助スキャナなどの機能が搭載されています。それだけでなく、折りたたみ式デバイスのエミュレータ、Android TV リモコン、Wear OS のペア設定ウィザードなど、サポート対象のデバイスも増えています。また、生産性を飛躍的に向上させるため、Background Tasks Inspector や Kotlin コルーチン デバッガ、Kotlin Symbol Processing のサポートも Android Studio に追加されました。
これらすべて、さらにその他の機能も、What's new in Android Development tools セッションでご紹介しています。
ConstraintLayout と MotionLayout の改善についてのさらに詳しい情報や、Android Studio で利用できる Compose ツールについては、What's new in design tools セッションをご覧ください。
Android 開発コミュニティで、Kotlin が採用される数が増えています。State of Kotlin on Android セッションの中で特にお伝えしておきたい新機能が、Kotlin Symbol Processing と、UI レイヤーからフローを収集する新しいライフサイクル API です。
Kotlin Symbol Processing（KSP）は、高速のビルドと、Kotlin エコシステムで最高級のシンボル処理を目指しています。KAPT による Java スタブ生成と、それに伴う長いビルド時間は不要になります。KSP は Kotlin コンパイラに組み込まれており、すべての Kotlin シンボルへのアクセスを提供します。また、KSP はベータ版に到達し、API サーフェスが確定しました。現在 KAPT を使っているプラグイン作成者の皆さんは、ぜひ KSP への移行を始めてください。私たちの Jetpack Room ライブラリもベータ版として KSP をサポートした結果、KAPT に比べて処理が 2 倍高速になりました。KSP についての話題は、先日の ADB ポッドキャストでも取り上げました。詳しく知りたい方は、ぜひお聴きください。
lifecycle-runtime-ktx ライブラリの最新版には、ライフサイクルに対応した repeatOnLifecycle API が含まれています。この API は、ライフサイクルがある状態に到達した場合やその状態を下回った場合に、コードブロックをキャンセルしたり再開したりします。この動作は、ビューがバックグラウンドにある場合に実行を停止してアップストリームのフローをアクティブに保つ launchWhenStarted API とは異なります。新しい API を使うと、特定のシナリオでリソースを無駄に消費しなくなるので、アプリの効率を高めることができます。
lifecycle-runtime-ktx
repeatOnLifecycle API
launchWhenStarted
この API によって、Android アプリのすべてのレイヤーで Flow を使うための完全なストーリーができあがりました。詳しくは、Migrating from LiveData to Kotlin’s Flow のブログ記事をご覧ください。
タブレット、Chrome OS デバイス、折りたたみ式デバイスなどの大画面デバイスをターゲットにしやすくするためのたくさんの機能をお知らせしました。たとえば、アップデートされた折りたたみ式対応の SlidingPaneLayout を使うと、一覧/詳細ビューを簡単に実装できます。また、横向き大画面用の新しい垂直ナビゲーション レール コンポーネントや、Button、TextField、Sheet のような極端に引き延ばされることが多いマテリアル コンポーネントの最大幅の値を導入し、新しいガイダンスも提供しています。詳しくは、こちらのセッションをご覧ください。
SlidingPaneLayout
Wear の次期バージョンが登場します。そこで、プレビュー エミュレータ システム イメージ、Android Studio から簡単に Wear エミュレータと他のデバイスをペア設定できるペア設定アシスタント、バーチャル心拍数センサーなどの新しいツールを準備しています。Ongoing Activities API とタイルによって、ユーザーがアプリとインタラクションを行う方法がさらに増えます。Samsung との共同作業で作成した新しいヘルスサービス プラットフォームは、現在アルファ版として組み込むことができます。また、カーブしたテキスト、ウォッチフェイス、ウォッチフェイスの追加機能、リモート インタラクションなど、Wear 向けの開発を容易にするその他の新しい Jetpack API も準備しています。詳しくは、Now is the time: What's new with Wear セッションで解説しています。
Android TV では、Cast Connect でストリームの転送と拡張が可能になり、Android 11 を実行する新しいエミュレータが利用できるようになりました。また、ADT-3 デバイスでは Android 12 Beta 1 を利用できます。8,000 万台を超えるアクティブな TV デバイスで稼働する Android の詳細については、What's new in Android TV and Google TV セッションをご覧ください。
Android に、アップデート可能な完全統合型の ML 推論スタックが搭載されることをお知らせしました。つまり、TensorFlow Lite for Android（TFLite）と Neural Networks API（NNAPI）が Google Play 開発者サービスを使って提供されるようになります。そのため、アプリの APK サイズを削減でき、新しい APK を公開しなくても、最新の高パフォーマンスなバージョンを活用できます。TFLite と NNAPI、そして関連するチップセット向けのドライバは、プラットフォームのバージョンとは独立してアップデートされるので、Android エコシステム全体でドライバと API の一貫性が向上します。また、TFLite 2.3 に互換性リストが追加され、どの部分を GPU やアクセラレータで実行するとモデルを高速化できるかがわかるようになっています。そのリストやモデルが提供するメタデータを使って、CPU、GPU、他のアクセラレータ バックエンドのどれで実行するかを判断する Automatic Acceleration についてもお知らせしました。Android のオンデバイス ML の新機能については、What's new in Android Machine Learning セッションをご覧ください。
これまで、CI サーバーで合格するテストがローカルの Android Studio では失敗する、あるいはその逆の事象を見たことがある方もいるかもしれません。このようなことが起きると、テストの信頼性が失われ、生産性に明らかな影響が出る可能性があります。その原因の 1 つは、Android Studio と Android Gradle プラグインが異なるバージョンの Android インスツルメント テストランナーを実装していることです。Android Studio Arctic Fox では、Android Studio のすべてのテストが Android Gradle プラグインで実行されるので、動作の一貫性が保たれます。
プロジェクト Nitrogen がどうなっているのか、気になっている方も多いでしょう。Nitrogen はもう存在しません。代わりに、統合テスト プラットフォーム（UTP）が登場しています。これは拡張可能なテスト実行環境で、Android Studio と Android Gradle プラグインから大規模な Android テストを実行します。
UTP によって実現できる機能の 1 つが、Gradle が管理する仮想デバイスです。これにより、Gradle DSL を使ってデバイスを定義できるようになります。もう 1 つの機能は、複数のデバイスで並列にテストを実行することにより、テスト実行の拡張性を向上させる機能です。さらに、テストが失敗したときのエミュレータのスナップショットを取得し、後ほどその状態を復元して何がうまくいかなかったのかを調査できるようにする機能もあります。
テストの詳細については、What's new in Android testing tools セッションをご覧ください。
I/O ではゲーム デベロッパー向けの内容はそれほど多くありませんでしたが、その大きな理由は、7 月 12-13 日に Google for Games Developer Summit の開催を予定していることです。登録は無料です。I/O では語られなかったゲーム開発に関するセッションをお届けする予定です。
長年にわたって、ポリシー、ポリシーの変更、ポリシー違反への対応について多くの質問が寄せられてきました。そのご要望にお答えして、Google Play Console に新しいポリシーとプログラムのセクションで、ポリシーとその適用情報が 1 か所で確認できるようになりました。
また、Google Play に新しい SDK コンソールが導入され、SDK プロバイダが非準拠や古い SDK バージョンなどの問題を報告できるようになります。AppBundle で公開する場合、Android Gradle プラグイン 4.0 以降では、アプリのどの SDK に依存関係があるかを自動的に報告できます。これにより、Play で SDK のアップデートが推奨される場合に通知などを行えるようになります。今年中には、アプリに適切な SDK を選択する際に役立つ新しいウェブサイトが Play に登場する予定です。
Play Billing 4.0 ライブラリのリリースにより、複数の数量の購入や、複数のプロダクトを 1 つのサブスクリプションの一部としてまとめるマルチライン サブスクリプションなどの新機能を利用できるようになります。既存の課金対応アプリは、今年の 11 月 1 日までに、少なくとも以前の Play Billing 3.0 ライブラリにアップデートする必要があります。新規アプリは、8 月 2 日までに Play Billing 3.0 以降に移行する必要があります。
ADB エピソード 163 では、Android グラフィック チームの Nat Duca と Sumir Kataria とADB チームで、シェーダー、GPU、Vulkan、OpenGL、ANGLE、ドライバ、ぼかし、ピクセルなどのトピックについてのトークをお届けします。もちろん、Chet のお気に入りの「色」についての話も登場します。
エピソード 164 は、Jetpack Compose について取り上げる新しい連載ミニシリーズ「AD/BC」の初回です。このシリーズでは、Android の未来の UI ツールキットについて、さまざまなトピックを掘り下げます。今回は、Nick と Chet が Adam Powell と Leland Richardson に、Compose のコンパイラやランタイム、データフローについて、そして Compose がデータの状態の変化に応じて Composable を呼び出すタイミングを判断するという素敵な機能について話を聞きました。
今回は以上です。今年の Google I/O はお楽しみいただけましたでしょうか。Jetpack、Android 12 とプライバシー、ツール、Kotlin、大画面、Wear OS、Android TV、オンデバイス機械学習、テスト、ゲーム開発、Google Play といったさまざまな最新情報が満載でした。グラフィックと Compose のポッドキャストもお聴きください。次回も Android デベロッパーの世界の最新アップデートをお届けします。お楽しみに。
