インディーゲームのコンテスト Google Play | Indie Games Festival 2021 の審査員をご紹介します。今年もインディーゲームに精通している審査員が、応募作品を様々な角度から審査します。
※（五十音順、敬称略）
安藤 武博
株式会社シシララ 代表取締役 ゲームDJ
ゲーム DJ・ゲームプロデューサー。1998 年、株式会社エニックス（現スクウェア・エニックス）入社。2015 年、株式会社シシララ設立。PlayStation® などの家庭用ゲームの他、スマートフォンゲーム、テレビ番組など様々なプラットフォームでプロデュースを手掛ける。19 年末、株式会社DONUTS ゲーム事業部長に就任。当フェスティバルでは、初回の 2018 年より審査員を務めている。
成沢 理恵
monoAI technology株式会社、モリカトロン株式会社、ちゅらっぷす株式会社、株式会社ArAtA、RingZero株式会社、Amusement Asset Associates株式会社 / 取締役
株式会社モバイルファクトリー / 社外取締役
国際基督教大学卒。
ゲームプロデューサー、Chief Entertainment Strategy Officer。
1998 年、株式会社エニックス（現スクウェア・エニックス）入社。現在は、東京、福岡、神戸、沖縄など7社のゲーム会社の取締役、顧問を務める。PlayStation® や Nintendo Switch などの家庭用ゲームの他、スマートフォンゲーム、デジタルトランスフォーメーション、テーマパークなど、エンターテイメント全般に渡るプロデュースを手がける。
Zen Chao
Asobu / Founder
Makers Fund / Japan Lead
東京・渋谷にクリエイターコミュニティ「Asobu」を設立。Asobu は、定期的なクリエイター の会合やゲームクリエイターへのさまざまなサポートを通じて、日本における独立系のゲーム制作を活性化し、先導することを目的としています。チャオは過去 10 年間、技術、メディア業界に従事してきましたが、創造性と革新への強い思いから、現在は、世界中の独立系ゲームスタジオやインタラクティブ エンターテインメントのスタートアップ企業への支援、投資に取り組んでいます。
簗瀬 洋平
ユニティ・テクノロジーズ・ジャパン株式会社 クリエイター・アドボケイト（学術）
ゲームデザイナー、シナリオライター、研究者。「ワンダと巨像」「Folks Soul -失われた伝承-」「魔人と失われた王国」などの開発に携わる。研究プロジェクト「Unlimited Corridor」では第20回文化庁メディア芸術祭エンターテインメント部門優秀賞を受賞。著書に「消極性デザイン宣言」など。
森 通治【集英社ゲームクリエイターズCAMP賞審査員】
株式会社集英社 新規事業開発部 ゲーム事業・映像事業開発課 ゲームクリエイターズCAMP プロデューサー
2008年、Apple Japan, Inc. 入社。教育機関、エンタープライズ市場向けの事業開発・パートナー事業推進を担当。2015 年に集英社に入社。デジタル事業部にて電子コミックの事業推進、プロモーション企画、社内ウェブサービスやマンガアプリのグロース支援、週刊少年ジャンプ50周年企画などを担当。2019 年に新規事業開発室の設立に伴い異動。現在「集英社ゲームクリエイターズCAMP」の立ち上げをはじめ、ゲーム事業の立ち上げ、プロジェクト推進を担当。
集英社ゲームクリエイターズ CAMP 賞
【過去の支援例】
新規ゲームの共同開発の資金支援（※ 過去実績: 1000 万円 ~ の支援事例あり）、ジャンプ IP の活用した企画、既存タイトルへのプロモーションやパブリッシングの支援、集英社のメンターシップ、など
大島 孝幸【TOHO Games 賞審査員】
東宝株式会社 映像本部 映像事業部 部長
アニメ製作の TOHO animationレーベル、音楽ドキュメンタリー、
DVD・Blu-ray、EC「ゴジラ・ストア」など多岐に渡る映像関連ビジネスを統括。
2018 年から取り組み始めたゲーム事業も担当している。
TOHO Games 賞
詳細は後日ウェブサイトでお知らせします。
五十嵐 郁
Google Play Partnerships ゲーム部門 パートナー デベロップメント マネージャー
Google Play にて事業開発とゲームアプリ開発企業とのパートナーシップを担当。クリエイティブな作品に出会えることを楽しみにしています。
キム チョンサ
Google Play Partnerships ゲーム部門 日本統括部長
Google Play Partnerships ゲーム部門の日本統括部長として事業開発とゲーム開発企業とのパートナーシップ全般を担当。「デベロッパーコミュニティのためのエコシステム作り」が一貫してモチベーションの源泉であり、インディーゲームフェスティバルでは素晴らしいゲームに出会えることを楽しみにしています。
※審査員は変更になる場合がございます。最新の審査員情報は、ウェブサイトでご確認ください。
ゲームをもっと多くの人に知ってもらいたい、ゲームビジネスの成功のチャンスを手にしたい、そんなインディーゲーム デベロッパーの皆さんから熱量の高い素敵なゲームを多数ご応募いただきました。結果発表は、8 月上旬を予定しています。
Posted by Tamao Imura - Developer Marketing Manager, Google Play
この記事は Purnima Kochikar による Android Developers Blog の記事 "Allowing developers to apply for more time to comply with Play Payments Policy" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
私たちは日々デベロッパーの皆さんと連携しながら、Google Play があらゆる人にとって安全、安心でシームレスな体験を提供できるよう、そして、デベロッパーの皆さんが持続可能なビジネスを構築できるように努めています。昨年 9 月に、Google Play の課金システムの使用が、いつ必須になるかということをデベロッパーの皆さんに示すため、お支払いに関するポリシーの明確化を行いました。大多数のデベロッパーの皆さんはその当時からすでにこのポリシーを遵守していましたが、課金システムを統合するために技術的な作業が必要なデベロッパーに対しては、必要なアップデートを完了するため 1 年間（2021 年 9 月 30 日まで）の猶予期間を設けました。
この記事は Greg Hartrell による Android Developers Blog の記事 "Updates from the Google for Games Developer Summit" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
昨年は、Android と Google Play が新たなステージに到達し、多くの人が自宅で安全に、更に多くのゲームを楽しむようになりました。私たちは、Google Play をユーザーにとってよりよい場所にし続けることで、ゲーム デベロッパーが世界中の様々なユーザーとつながることができる、より豊富な機会を提供してきました。その結果、世界中で Android の月間アクティブ端末数は 30 億台、Play の月間アクティブ ユーザー数は 25 億人に達し、合計 1400 億回のインストールが行われています。
Google はあらゆる人のための開発を支援しています。つまり、大規模なゲームスタジオから、世界中で楽しい画期的なゲームを開発している小規模なインディー ショップまで、すべてのデベロッパーが適切なタイミングでゲーマーにアプローチできるお手伝いをしています。
Game Developer Summit では、ゲームビジネスのライフサイクル全体に関連する幅広いツールやソリューションの最新情報を発表しました。具体的には、ゲーム開発をより容易にする新ツール、ゲームを更に多くのマルチスクリーン上で実行することを可能にする、成長中のエコシステムに関する最新情報、Google Play で市場開拓を成功させる新たなチャンスなどについてお知らせしました。
ここでは、イベントでお話しした内容と、今日から実践できることついて、もう少し詳しくお伝えします。
Google for Games Developer Summit のすべてのセッションの情報は、モバイル セッション トラック（各セッション動画には日本語字幕が付きます）から確認できます。また、Android ゲーム開発の最新リソースを入手できる g.co/android/games をブックマークしておきましょう。
Reviewed by Chongsa Kim - Head of Japan Games Business Development, Yuichi Araki - Developer Relations Team, Hidenori Fujii - Google Play Developer Marketing APAC
この記事は Dom Elliott による Android Developers Blog の記事 "The future of Android App Bundles is here" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
2018 年 5 月に Android App Bundle をローンチしてから、デベロッパー コミュニティがこの新基準を広く採用し、リリースの効率化や高度な公開機能によるメリットを活用しているのを見てきました。現在では、100 万以上のアプリが実際に App Bundle を使っています。そこには、Adobe、Duolingo、Gameloft、Netflix、redBus、Riafy、Twitter など、Google Play のトップ 1,000 のアプリやゲームの大半が含まれています。
このメリットをより多くのユーザーに提供し、すべてのデベロッパーにとっても有益な、最先端の Android のアプリ公開形式に注力するため、2021 年 8 月より、Google Play で新しいアプリやゲームを公開する際に Android App Bundle の使用が必須となります。これにより、標準の公開形式が APK から App Bundle になります。
まだ App Bundle に切り替えていない方のために、皆さんが見逃しているメリットについて説明します。
リリースの種類
変更前
2021 年 8 月に必須となる
項目
Google Play 上の新規アプリ
APK
Android App Bundle（AAB）
拡張ファイル（OBB）
Play Asset Delivery または
Play Feature Delivery
既存アプリのアップデート
変更なし
新規 Instant
エクスペリエンス
Instant app ZIP
Instant 対応 Android App Bundle（AAB）
Instant
エクスペリエンスの
アップデート
再度のご案内となりますが、App Bundle の要件は新規アプリに適用されます。現在のところ、既存アプリや managed Google Play ユーザーを対象に公開されている限定公開アプリは対象外です。最後になりましたが、App Bundle の普及に貢献してくださっているたくさんのデベロッパーの皆さんに感謝いたします。今後、さらなる改善と新機能をお届けできることを楽しみにしております。以下では今回の移行に際し、よくお寄せいただく質問への回答を紹介します。
- - -
Android App Bundle に関するよくある質問と回答
APK と比べ、App Bundle を使う場合はどのくらいの作業が必要になりますか？
ほとんどのアプリでは、わずかな作業だけで APK の代わりに AAB をビルドできます。ほとんどの場合、ビルド時に別のオプションを選び、いつもどおりテストするだけです。App Bundle はオープンソースのフォーマットで、Android Studio、Gradle、Bazel、Buck、Cocos Creator、Unity、Unreal Engine、その他のエンジンなど、主要なビルドツールでサポートされています。Play Core Native や Play Core Java & Kotlin SDK でも、任意のコーディング環境を利用して、オプションの高度な App Bundle 機能を簡単に利用できます。
App Bundle で拡張ファイル（OBB）がサポートされないのはなぜですか？ゲームで Play Asset Delivery を使う必要があるのはなぜですか？
APK でユーザーに追加リソースを配信するには、別のファイル（OBB）が必要です。しかしながら、OBB は署名されておらず、アプリの外部ストレージに保存されるため、あまり安全ではありません。しかし、 Play Asset Delivery（PAD）を使用することで、サイズが 150 MB を超えるゲームでも、OBB ではなくゲーム全体を 1 つの App Bundle として Google Play Store で公開できるようになります。公開プロセスがスムーズになり、柔軟な配信モードが利用できることに加え、PAD には以前の拡張ファイルを上回るメリットがあります。アセットの差分パッチが大型アプリ向けに最適化されるので、アップデートに必要なデバイスのストレージが OBB よりも大幅に少なくなります。そのため、fast-follow を使うことで、インストール率やストアのコンバージョン率が上がります。さらに、最大 80% のデバイスで ASTC がサポートされているので、テクスチャ圧縮形式のターゲット指定を使ってサポート対象のデバイスに ASTC を配信できます。これにより、利用可能なハードウェアやデバイスのストレージを効率的に利用しつつ、幅広い Android デバイスをターゲットにすることができます。
App Bundle を使う場合、今後も複数の配信チャンネルやアプリストアで公開できますか？
可能です。これを実現する方法はいくつかあります。すべての場所で同じアプリ署名鍵を使うことも、チャンネルによってアプリ署名鍵を使い分けることもできます。Google Play 用の一意なアプリ署名鍵を使うこともできます。また、ローカルですべての配信チャンネル用のアーティファクトをビルドして署名することも、Google Play から配信用 APK をダウンロードして別のチャンネルで使うこともできます。Google Play Console の App Bundle エクスプローラまたは Play Developer API のいずれかを使用して Google Play からダウンロードした配信用 APK は、Play アプリ署名鍵で署名されます。
新しいアプリをリリースしようとしています。アプリ署名鍵を自分で決めることはできますか？
可能です。このオプションは Google Play Console で利用できます。新しいアプリを作成するときには、Google が使うアプリ署名鍵の提供方法を選択できます。アプリ署名鍵のコピーは、ローカルで保持できます。たとえば、Play バージョンと同じ鍵を使って署名し、他のチャンネルで配信する署名済みのバージョンを生成できます。近日中に、Play Console でのアプリの初回リリースが少しばかり簡単になる予定です。具体的には、初めてオープン トラックに公開する前であれば、操作を誤った場合でもアプリ署名鍵を変更できるようになります。
Google Play でアプリを配信する場合、アプリが意図したとおりにユーザーに配信されていることを確認するにはどうすればよいですか？
いつでも、Play Console の App Bundle エクスプローラか、Play Developer API を通して、Play ストアからアーティファクトをダウンロードして検証できます。さらに、新しいオプション機能である App Bundle のコードの透過性機能を使うと、デバイスで実行されるコードが、デベロッパーがビルドして署名したオリジナルのコードと一致するかどうかを検証できます。
既に Google Play でアプリを公開しています。既存のアプリ署名鍵のコピーを提供せずに Play アプリ署名を使うことはできますか？
現在のところ、Play アプリ署名を使うには、既存のアプリ署名鍵のコピーを提供する必要があります。既存のユーザーに配信する際に、Google Play でアップデートに署名するため、Google Play がコピーを保持する必要があるためです。これはほとんどのデベロッパーにとって適した方法で、100 万以上のアプリが Play アプリ署名を実際に利用しています。近日中に、鍵のアップグレードを行って Play アプリ署名をオプトインする追加オプションを既存アプリ向けに追加する予定です。このオプションを選択すると、すべての新規インストールとそのアップデートの際に、Play アプリ署名で新しい一意の鍵が使われます。ただし、これを動作させるには、App Bundle をアップロードする際に、古い鍵で署名した以前の APK もアップロードする必要があります。これが必要なのは、Google Play が既存ユーザーへのアップデート配信を継続できるようにするためです。
アプリ署名鍵は変更できますか？
可能です。アプリによっては、Play Console で新規インストール用のアプリ署名鍵のアップグレードをリクエストできます。Google Play では、新規インストールとアプリのアップデートの署名に新しい鍵が使われます。一方、鍵のアップグレード前にアプリをインストールしたユーザーへのアップデートでは、以前のアプリ署名鍵が使われます。近日中に、Play アプリ署名鍵のアップグレードにも APK 署名スキーム v3 の鍵ローテーションのサポートを追加する予定です。これにより、鍵のアップグレードが現実的なオプションとなるアプリが増え、アップグレードした鍵で署名されたアプリがさらに多くのユーザーに届くようになります。
Reviewed by Hidenori Fujii - Head of APAC Developer Marketing, P&E
この記事は Luke Jefferson, Raz Lev による Android Developers Blog の記事 "Play Dev ID requirements + 2-Step Verification" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
ここ数年間で、Google Play は大きな成長を遂げています。仕事、趣味にかかわらず、世界中のあらゆる規模のデベロッパーが開発する Android のアプリやゲームは、人々にとって欠かすことのできない生活の一部になっています。
Google Play の安全性とセキュリティを保ち、デベロッパー コミュニティによりよいサービスを提供するため、追加の身元要件と 2 段階認証プロセスという 2 つの新しいセキュリティ対策を導入します。これにより、アカウントのセキュリティが強固になり、皆さんのニーズを把握しやすくなります。
現在、新しい Google Play デベロッパー アカウントを作成すると、メールアドレスと電話番号の入力が求められます。
今回のアップデート以降、デベロッパー アカウントのアカウント所有者は追加で以下を求められます。
連絡先情報が追加されることで、お使いの Google Play デベロッパー アカウントに関する、重要な情報やアプリのアップデートなどの情報をお知らせできるようになります。さらに、すべてのアカウントが、実際の連絡先を持つ実在の人物によって作成されたことを確認できるので、Google Play ストアをすべてのユーザーにとって安全な状態に保ちやすくなります。
この情報は一般公開されることはなく、本人確認と連絡の目的のみに利用します。
デベロッパー コミュニティについてさらに知るということに加えて、セキュリティを向上させ、アカウントをより安全に保つための措置を講じるため、Google Play Console へのログイン時に Google の 2 段階認証プロセスを必須にします。2 段階認証プロセスは、アカウント、アプリ、ユーザーを守るための追加の保護手段です。
2 段階認証プロセスの詳細とアカウントへの設定方法をご確認ください。
Google Play デベロッパー アカウント所有者は、本日よりアカウントの種類の入力と連絡先情報の確認を行うことができます。現時点では、アカウントの種類の入力は省略可能ですが、アカウント所有者が連絡先情報を更新するときは入力が必須になります。
2021 年 8 月より、新しいデベロッパー アカウントすべてにおいて、登録時にアカウントの種類の選択と連絡先情報の確認が必要になります。新しいデベロッパー アカウントの所有者は、2 段階認証プロセスも必須になります。
今年中に、すべての既存のデベロッパー アカウント所有者も、アカウントの種類の選択、必須情報の提供、連絡先情報の確認が必要になります。2 段階認証プロセスによるログインも必須になる予定です。
以上の変更と併せて、アカウントを健全な状態に保ち、重要な情報を見逃さないためのベスト プラクティスを改めてお伝えします。
Reviewed by Naoki Oyama - Developer Support Lead, Google Play, APAC and Hidenori Fujii - Head of APAC Developer Marketing, P&E
この記事は Purnima Kochikar による Android Developers Blog の記事 "Continuing to boost developer success on Google Play " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
今年 3 月にお知らせしたように、デベロッパーが持続可能なビジネスを構築できるよう支援することは、Google Play のミッションです。先月の Google I/O ではそのミッションに基づき、ユーザーにアプリやゲームを見つけてもらいやすくする措置や、新しい 15% のサービス手数料ティア適用への登録を Goolge Play Console 上で開始することなど、複数のアップデートを発表しました。
※日本語字幕に対応しています
私たちは引き続き、様々なタイプのデベロッパーの皆さまが Google Play で成功するための様々な支援策を模索しています。そして、本日は追加で共有したいお知らせがございます。
ユーザーは、使用するデバイスに関わらず、魅力的なコンテンツを求めています。そして、最近リリースしたタブレット向けの Entertainment Space （英語） 、サムスン製のスマートウォッチが Wear OS を搭載するという発表、Android Auto （英語）プラットフォームのアップグレード、Google TV （英語）での新しいディスカバリー エクスペリエンスなどを通じて、これまで以上にデベロッパーがデバイスを跨いでユーザーにアプリを提供し、アピールできる機会が増えています。
Google Play は、モバイル以外の様々な重要なフォーム ファクタにもサービスを拡張できるよう、デベロッパーの皆さまを積極的に支援してきました。実際に長年にわたり、革新性あふれるエクスペリエンスを構築するための支援プログラムを提供してきました。
そして、2021 年 6 月 24 日（現地時間 6 月 23 日）より、さらに多くのデベロッパーの皆さまがベストなメディア エクスペリエンスを様々なデバイス上で実現するための支援策として、Play メディア エクスペリエンス プログラムを全世界で開始しました。ここでのメディアとは、以下の 3 種を指します。
上記の統合を通して、Google Play は、デベロッパーの皆さまが開発・提供しているアプリがユーザーに新たに発見されたり、再エンゲージメントしたりすることで、Google Play での成長を加速できるようサポートします。さらに、プログラム期間中はサービス手数料を 15% に引き下げます。これらの対応はすべて、デベロッパーの皆さまが最高の体験を構築できるようサポートするためのものです。
このプログラムにご興味のあるデベロッパーの方は、プログラムのガイドラインを確認のうえ、関心がある旨をお知らせください（英語でのご登録が必要です）。 参加資格を満たした皆さまには、追って詳しい情報をお伝えします。
なお、Play メディア エクスペリエンス プログラムは、その他既に存在する多数のデベロッパー向け支援プログラムのひとつです。ニュース パブリッシャー向けの 「Google で購読」、エンタープライズ 向けの各種 プログラム、Play Points などと同様に、ユーザーに向けたサービス内容を継続的に改善しつつ、投資を続けるデベロッパーの皆さまのニーズを満たすことを目指しています。
7 月 13 日、14 日（現地時間 7 月 12 日、13 日）にオンラインで開催する Google for Games Developer Summit では、Google が提供するプロダクトの最新情報をお伝えします。Android、Google Play、Cloud、Firebase、Google 広告など、優れたゲームの開発や、ユーザーへの効果的なアプローチに役立つセッションを 20 以上ご用意しています。
私たちは引き続き、皆さまのフィードバックに耳を傾けています。Google Play のすべてのステージで、皆さまのビジネスをサポートする為のさらなる方法を模索することを楽しみにしています。
この記事は Paris Hsu による Android Developers Blog の記事 "Android Studio Arctic Fox (2020.3.1) Beta" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android Studio Arctic Fox のスプラッシュ画面
注：昨年末に発表した通り、Google では Android Studio のベースとなっている IntelliJ IDE の番号と整合性を持たせるために、バージョン番号体系を変更し、2020.3 となりました。その他にも独自のパッチ番号とわかりやすいコードネームを割り当てることで、覚えやすく簡単に参照できるようにしています。最初に Arctic Fox（現在ベータ版）、次に Bumblebee（現在カナリー版）のように、アルファベット順にコードネームを使用していきます。
デザイン、デバイス対応と管理、デベロッパーの生産性向上に重点を置いた Android アプリ開発用の公式 IDE 、Android Studio の最新リリース Arctic Fox (2020.3.1) Beta ❄️🦊を 2021 年 5 月 19 日（現地時間 5 月 18 日）に発表しました。現在 Beta チャンネルで公開していますのでダウンロードすると Google I/O 2021 で発表したすべての新機能を実際に使うことができます。
この 1 年間、さまざまな課題に対応しなければなかったにもかかわらず、革新的なすばらしいアプリを作り続けてきた世界中のデベロッパーコミュニティに触発されて、次の主に 3 つのテーマを強化する統合ツールの提供とアップデートに取り組んできました。
まとめると、今回のアップグレードは見逃せない内容になっています。✨ このベータ版には、これまでお伝えしてきた以外にも上記のテーマに関連した機能や改善が多数含まれていますので、以下の記事や動画をご覧ください。あるいは、記事のチェックを飛ばして、Android Studio Arctic Fox (2020.3.1) Beta を Beta チャンネルでダウンロードし、最新機能を今すぐ実際に使用してみてください。Android Studio の次期バージョンでも、引き続きデベロッパーの皆さんにとって最も重要なことに注力できるよう、フィードバックをお寄せください。
What's new in Android development tools (I/O 2021)
Android Studio Arctic Fox (2020.3.1) Beta の新機能を 3 つの主なテーマ別にすべてご紹介します。
Compose プレビュー
Layout Inspector の Compose 対応
プレビューとガターにある「デバイスへのデプロイ」アイコンを使用
これまでの内容をまとめると、Android Studio Arctic Fox (2020.3.1) Beta には、以下の新しい機能強化と新機能が搭載されています。
I/O では、上記の一覧に記載されていない他の新機能もご覧になったかもしれません。それらの機能については、Beta チャンネルでリリースする準備が整わなかったため、Android Studio (2021.1.1) Bumblebee Canary に搭載されます。
今回のリリースに合わせて、Android Studio チームは Android Studio に関して複数のセッションで発表を行いました。以下の動画をご覧いただくと、提供される最新機能や Android Studio の使用に関する役立つ情報を確認できます 📺。なお、すべての動画で日本語字幕に対応しています。ぜひ切り替えてご覧ください。
Android Studio Arctic Fox (2020.3.1) は重要なリリースとなっています。今が Beta リリースをダウンロードおよびチェックして、ワークフローに新しい機能を組み込む絶好の機会です。ベータ版リリースでは、ほぼ安定した機能を提供しますが、どのベータ版リリースにも言えるように、バグが残っている可能性があります。問題が見つかった場合は修正しますのでご連絡ください。Android Studio をすでにお使いの場合は、ナビゲーション メニューから Beta チャンネルでアップデートをチェックしてください（[Help] > [Check for Update [Windows/Linux] , Android Studio] > [Check for Updates [OS X]]）。ベータ版にアップデートすると、最新バージョンの Android Studio と Android Emulator にアクセスできます。
気に入った点、問題点、あったらいいなと思う機能に関するフィードバックをお寄せください。バグや問題が見つかった場合はご連絡ください。Android Studio 開発チームの Twitter と Medium もぜひフォローしてください。
Reviewed by Yuichi Araki - Developer Relations Team and Tamao Imura - Developer Marketing Manager, Google Play
この記事は Florina Muntenescu による Android Developers Blog の記事 "What's new in Jetpack" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android Jetpack は、デベロッパーがベストプラクティスに従って、ボイラープレート コードを削減し、Androidのバージョンやデバイス間で一貫して動作するコードを書くためのライブラリ、ツール、ガイダンスを統合したものです。現在、Google Play の トップ 1000 アプリのうち 84 % がJetpack を利用しています。この記事では、Jetpack の最新のアップデートをまとめてご紹介します。
CameraX ライブラリは、デバイス固有の互換性の修正や回避策を含む、OS のバージョンを超えてカメラ機能にアクセスするための統一された API サーフェスを提供します。最新の改良点は、露出補正のサポートや、カメラの状態や機能に関するより詳細な情報へのアクセスなど、多数寄せられた機能要望にお応えした内容となっています。さらに、FPS レンジなどのカメラ設定を、カメラを動作中に Camera2Interop 経由で変更できるようになりました。また、ハイダイナミックレンジのプレビュー、ズーム比の調整、Android の Do Not Disturb モードへの対応など、最新のデバイスや OS の機能にも対応しています。特に重要なのは、パフォーマンスへの取り組みで、特に古いデバイスにおいて、画像の取り込みや初期化が高速化されています。
Hilt は、Dagger 上に構築されている、Jetpack 推奨の依存関係注入ソリューションです。安定版への移行の一環として、Hilt の ViewModel サポートはコア Hilt Android API に移され、SavedStateHandle が ViewModelComponent で利用可能なデフォルトの依存関係として追加されています。また、Hilt は Navigation および Compose と統合されています。適用範囲を宛先またはナビゲーション グラフ自体とした注釈付き Hilt ViewModel を取得できます。複数のデベロッパーの皆さんが、すでにアプリで Hilt を使い始めています。そのケーススタディは、こちらのブログ記事 (英語) をご覧ください。
ViewModel
SavedStateHandle
ViewModelComponent
Paging ライブラリを使用すると、データの小さなチャンクをロードおよび表示してネットワークとシステムのリソース消費を改善できます。このリリースでは、全体を Kotlin で書き直すことによって コルーチンおよび Flow を完全にサポートし、RxJava および Guava プリミティブを使用した非同期ロード、リポジトリおよびプレゼンテーション層の全体的な改善を提供します。
3.0 リリースでは Paging 2 と比べて使い勝手が大幅に改善され、書き直しは部分的および段階的移行を念頭に計画されたため、デベロッパーの皆さんはご自身のスケジュールに合わせて移行できます。詳細および実践については、Paging 3.0 のドキュメントおよび Paging 3.0 のCodelab をご覧ください。
Jetpack のレイアウト設計を柔軟に行うためのシステム ConstraintLayout、モーションおよびウィジェット アニメーションの管理を目的とした MotionLayout は現在安定版です。MotionLayout では、折りたたみデバイス、イメージ フィルタ、モーション エフェクトがサポートされています。デザインツールの新機能について詳細は、こちらの Google I/O セッションをご覧ください。
ConstraintLayout
MotionLayout
Security Crypto ライブラリを使うと、ファイルや SharedPreferences を安全かつ簡単に暗号化できます。SharedPreferences を暗号化するには、EncryptedSharedPreferences オブジェクトを適切なキーとスキームで作成し、このオブジェクトを標準の SharedPreferences オブジェクトのように使用します。
SharedPreferences
EncryptedSharedPreferences
val prefs: SharedPreferences = EncryptedSharedPreferences.create( context, "prefs_file_name", mainKey, prefKeyEncryptionScheme = AES256_SIV, prefValueEncryptionScheme = AES256_GCM,)// Use the resulting SharedPreferences object as usual.prefs.edit() .putBoolean("show_completed", true) .apply()
context,
"prefs_file_name",
mainKey,
prefKeyEncryptionScheme = AES256_SIV,
prefValueEncryptionScheme = AES256_GCM,
)
// Use the resulting SharedPreferences object as usual.
prefs.edit()
.putBoolean("show_completed", true)
.apply()
この1年間、Fragment ライブラリは内部の実装を整理して明文化されていない動作を削減するための大規模な変更を行いました。これにより、デベロッパーの皆さんは、アプリやゲームのベスト プラクティスに倣って信頼できるテストを記述しやすくなりました。これは、Navigation で複数のバックスタックをサポートするなど、将来的なライブラリの改善のための基礎となるもので、厳密化された API に対応するためには、いくつかの作業が必要になるかもしれません。実際に、ライブラリを更新した後のテストには細心の注意を払う必要があります。特に注意が必要なケースについては、Fragmentのリリースノートをご確認ください。
最新リリースでは、ActivityResult の統合も行われ、フラグメントから Activity の結果を登録することが可能になりました。 Fragment には、柔軟性があまり高くない onAttachFragment メソッドの代わりに、新しい FragmentOnAttachListener インターフェースも追加されています。Fragment または FragmentActivity でこのメソッドを上書きする既存のコードは引き続き機能しますが、新しいコードが柔軟性の高くない手法を誤って採用するのを防ぐため、onAttachFragment を非推奨にしました。
onAttachFragment
FragmentOnAttachListener
Fragment
FragmentActivity
// Obtain the fragment manager.May be a childFragmentManager,// if in a fragment, to observe child attachment.val fm = supportFragmentManagerval listener = FragmentOnAttachListener { fragmentManager, fragment -> // Respond to the fragment being attached.}fm.addFragmentOnAttachListener(listener)
// if in a fragment, to observe child attachment.
val fm = supportFragmentManager
val listener = FragmentOnAttachListener {
fragmentManager, fragment ->
// Respond to the fragment being attached.
}
fm.addFragmentOnAttachListener(listener)
ライブラリの機能が完成すると、安定化のためにベータ版に移行します。現時点では、重要な問題やコミュニティからのフィードバックに対してのみ、API を変更しています。
DataStore は、シンプルで非常に有用な API サーフェスを維持しながら、SharedPreferences の欠点を解決する堅牢なデータ ストレージ ソリューションを提供します。DataStore は、Flow と RxJava による Kotlin のコルーチンのようなベストプラクティスをサポートします。DataStore では、Preference DataStore 経由でキーと値のペアを格納したり、Proto DataStore 経由でプロトコル バッファがバックアップする型付きオブジェクトを格納できます。さらに、Kotlin Serialization のような独自のシリアル化ソリューションをプラグインすることもできます。
アルファ版ライブラリは、現在開発中のライブラリです。API の追加、変更、削除が行われる可能性がありますが、ライブラリのコンテンツはテストされていますので、高い機能性を備えています。
AppSearch は高性能で機能豊富なフルテキスト検索機能を提供する新しいデバイス内検索ライブラリです。SQLite と比較すると、AppSearch は複数の言語をサポートし、クエリ結果のランク付けがシンプルで、大きなデータセットのインデックス作成や検索の遅延がより少なくなります。
AppSearch 1.0.0-alpha01 は LocalStorage をサポートしています。これによって、アプリケーションは「ドキュメント」と呼ばれる構造化されたデータを管理し、それに対してクエリを実行することができます。アプリケーションは、「スキーマタイプ」を使って、構造がどのようなものかを定義します。例えば、メッセージは、件名、本文、送信者などのデータを持つスキーマタイプとしてモデル化することができます。
ビルダーを使用してスキーマ タイプのドキュメントを作成し、ストレージに追加します。"body:fruit" とクエリを実行すると、メッセージの本文に用語「fruit」があるすべてのドキュメント検索できます。
Android S では、AppSearch はアプリケーションのデータを他のアプリケーションと安全に共有し、追加のネイティブ ライブラリへのリンクを不要にすることで、アプリケーションのバイナリサイズを削減できる PlatformStorage も提供します。ライブラリがまだ Android S SDK を対象としていないため、現時点では Jetpack で PlatformStorage は使用できません。
デバイス全体の検索に統合するための Android S の中央ストレージ
Room は推奨されているデータ永続化レイヤであり、プラットフォーム上での使い勝手と安全性が向上します。
Room 2.4.0-alpha は自動移行をサポートしています。データベース スキーマが変更された時に、@AutoMigration を宣言して、どのバージョンからどのバージョンに移行したいかを示すと、Room が移行を生成してくれるようになりました。より複雑な移行を行う場合は、引き続き Migration クラスを使用できます。
@AutoMigration
Migration
@Database(- version = 1,+ version = 2, entities = { Doggos.class },+ autoMigrations = {+ @AutoMigration (from = 1, to = 2)+ } )public abstract class DoggosDatabase extends RoomDatabase { }
- version = 1,
+ version = 2,
entities = { Doggos.class },
+ autoMigrations = {
+ @AutoMigration (from = 1, to = 2)
+ }
public abstract class DoggosDatabase extends RoomDatabase { }
Room 2.3.0 安定版では、 Kotlin Symbol Processing が試験的にサポートされ、Kotlinコードのベンチマークでは、KAPTに比べて2倍の速度向上が見られました。また、enumとRxJava3のサポートも組み込まれています。
またRoom は、の実行時にコールバックを提供する QueryCallback クラスが導入され、ロギングなどのタスクがシンプルになりました。また、新しい@ProvidedTypeConverter アノテーションが導入され、型コンバータの作成がより柔軟になりました。
QueryCallback
@ProvidedTypeConverter
WorkManager ライブラリは、アプリが終了またはデバイスが再起動しても実行される延期可能な非同期タスクをスケジュールする方法として Android で推奨されています。すべてのタスクが確実に実行されるようにタスク照合の信頼性が向上し、さらに特定の Android OS バージョン向けのさまざまな回避策も提供されています。
WorkManager の機能の最新バージョンでは、マルチプロセス アプリのサポートが強化されています。作業リクエストのスケジュールを 1 つのプロセスに統合することで、多数のリクエストをスケジュールする際のデータベースの増大を抑制してパフォーマンスを向上するメリットがあります。
Android S SDKを対象としたバージョン 2.7（現在アルファ版）では、Android OS の新しいフォアグラウンド制限への追加サポートに対応しています。詳しくは、Effective Background Tasks on Android セッションをご覧ください。
Android Studio Arctic Fox で利用可能な Background Tasks Inspector は、最新のライブラリを使うと WorkManager のジョブを簡単に表示してデバッグできます。
Background Tasks Inspector
アプリ内の目的地間を移動するための Jetpack のフレームワークである Navigation ライブラリは、複数のバックスタックをサポートし、ボトムナビゲーションバーのように目的地が同じ深さにある場合にも簡単に対応できるようになりました。
Macrobenchmark ライブラリは、アプリの起動やスクロール パフォーマンスなどの統合された動作まで、Jetpack のベンチマーク範囲を拡張します。このライブラリは、継続的な統合テストでメトリクスを追跡するためにリモートで使用することも、プロファイリングの結果をAndroid Studioから表示するためにローカルで使用することもできます。詳細については、Google I/O のセッションをご覧ください。
Google アシスタントともっと密接した統合を希望しているデベロッパーのために、Google Shortcuts ライブラリは、既存の ShortcutInfo クラスを通じて、Google アシスタントやその他の Google サービスにアクションを公開する方法を提供します。
ShortcutInfo
ShortcutManager を介して一度に最大 15 個のショートカットを送信し、他のサービスの中から Google アシスタントに表示させ、音声やその他のインタラクションで利用できるようにします。
ShortcutManager
これを実装するには、ショートカットに Intentと機能バインディングを定義します。このバインディングは、Google サービスがユーザーに提供する最善の方法を見出すのに役立つ重要な情報を提供します。
// expose a "Cappuccino" action to Google Assistant and other servicesShortcutInfoCompat siCompat = ShortcutInfoCompat.Builder(ctx, "id_cappuccino") .setShortLabel("Cappuccino") .setIntent(Intent(ctx, OrderCappuccino::class.java)) .addCapabilityBinding( "actions.intent.ORDER_MENU_ITEM", "menuItem.name", asList("cappuccino") ) .build()ShortcutManagerCompat.pushDynamicShortcut(ctx, siCompat)
ShortcutInfoCompat siCompat =
ShortcutInfoCompat.Builder(ctx, "id_cappuccino")
.setShortLabel("Cappuccino")
.setIntent(Intent(ctx, OrderCappuccino::class.java))
.addCapabilityBinding(
"actions.intent.ORDER_MENU_ITEM",
"menuItem.name",
asList("cappuccino")
.build()
ShortcutManagerCompat.pushDynamicShortcut(ctx, siCompat)
アプリ内でユーザーが作成したすべてのコンテンツには 🎉 が含まれ、最新の絵文字をサポートすることは、あなたのアプリまたはゲームを ✨ にするために重要な要素です。API 19以降で最新の絵文字をサポートする EmojiCompat ライブラリは、従来の :emoji:emoji アーティファクトに代わる新しいアーティファクト emoji2:emoji2 に移行しました。新しい emoji2 ライブラリでは AppStartup ライブラリを使用た 🪄 自動設定が追加されています（ 🐻❄️を表示するためのコード 👩🏿💻 は必要ありません）。
emoji2:emoji2
emoji2
AppCompat では、AppCompat 1.4 以降から emoji2 が追加されています。あなたのアプリまたはゲームがAppCompat を使用している場合、ユーザーは追加設定なしで最新の絵文字 ⭐ を見ることができます。AppCompat を使用していないアプリまたはゲームは emoji2:emoji2-views を追加できます。カスタム TextViews の場合は、emoji2:emoji2-views-helpers のヘルパーを使用するか、AppCompat のビューをサブクラス化することで、最新の絵文字をサポートすることができます。
emoji2:emoji2-views
TextViews
emoji2:emoji2-views-helpers
Jetpack Compose は、Android のネイティブ UI 開発用の最新ツールキットです。Android での UI 開発をシンプルにし、高速化します。Jetpack Compose は現在ベータ版で、7 月に安定版に移行する予定です。ここに掲載されているライブラリや皆さんがすでに使用している可能性のあるライブラリの多くは、Jetpack Compose との統合を目的とした機能を導入しています。Activity から ViewModel、Navigation、Hilt まで、これらすべてのライブラリを使うと、アプリに Compose をスムーズに導入できます。これらの使い方に関する詳細については、この Google I/O セッションをご覧ください。
Jetpack は、折りたたみ式デバイス、大画面デバイス、Wear デバイスなど、さまざまな形状での作業をしやすくします。大画面デバイスに対応するアプリ開発のための新しいガイドラインを導入し、、WindowManager や、SlidingPaneLayout などの Jetpack ライブラリを改善しています。詳しくは、こちらのブログ記事をご覧ください。
WindowManager
SlidingPaneLayout
以上、Jetpack の新機能を（比較的）簡単にご紹介しました。各ライブラリのアップデートの詳細については AndroidX リリースノートをご覧ください。また、Google I/O セッションでは、一部のライブラリについての詳細についてご説明しています。
この記事は 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 サイトをご覧ください。
この記事は Madan Ankapura による Android Developers Blog の記事 "Improve your app mileage with Android for Cars App library" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
4 月に、Jetpack の一部として Android for Cars App Library の最初のバージョンを発表し、デベロッパーが Google Play ストアでナビゲーション、駐車場、充電スポットのアプリを公開できるマイルストーンに到達したことをお知らせしました。
そして先日 2021 年 6 月 18日（現地時間 6 月 17 日）、デベロッパーに以下の機能を提供するバージョン 1.1 がアルファ版になりました。
すべての変更点のリストは、リリースノートをご覧ください。自動車用のアプリ開発を始めるには、最新版のデベロッパー ドキュメント、自動車向け品質ガイドライン、デザイン ガイドラインをご覧ください。
以上のライブラリ機能は、デスクトップ ヘッドユニットでのテストにのみ利用できます。これらの機能が自動車で実行できるようになった際は、改めてお知らせします。
今後の早期アクセスプログラムに参加したいデベロッパーの方は、こちらのフォームからご登録ください。また、g.co/androidforcars にアクセスすると、早速今日から Android for Cars App Library を使ってみることができます。ぜひお試しください。
Reviewed by Jake Hirakawa - Partner Development Manager, Android Auto and Hidenori Fujii - Head of APAC Developer Marketing, P&E
