[go: nahoru, domu]

この記事は Chromium Blog の記事 "Chrome 87 Beta: WebAuthn in DevTools, Pan/Tilt/Zoom, Flow Relative Shorthands and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2020 年 10 月 15 日の時点で Chrome 87 はベータ版です。

DevTools の WebAuthn タブ

Web Authentication のテストは、コードをテストするデバイスが必要なので長らく困難でした。Chrome 87 より、DevTools の新しいパネルを使って認証のエミュレートやデバッグができるようになります。この DevTools のパネルは、[More options]、[More tools]、[WebAuthn] の順に選択すると表示されます。詳しい使用方法は、DevTools の新機能(Chrome 87)の WebAuthn のセクションをご覧ください。

カメラのパン、チルト、ズームの制御

部屋単位のビデオ会議ソリューションでは、ソフトウェアがカメラでミーティングの参加者を映せるよう、カメラをパン、チルト、ズームする機能が搭載されます。Chrome 87 より、MediaDevices.getUserMedia()MediaStreamTrack.applyConstraints() のメディア トラック制約を使って、ウェブサイトからカメラのパン、チルト、ズーム機能にアクセスできるようになります。

この機能は、ユーザーが明示的にアクセス許可を与えた場合にのみ操作できます。新機能の詳しい使い方やデモは、カメラのパン、チルト、ズームを制御するをご覧ください。

CSS flow-relative の省略形と offset プロパティ

物理プロパティを論理プロパティで補完するというのが、長年にわたる CSS のトレンドになっています。中国語の縦書きテキストやアラビア語など、ヨーロッパ式以外のテキストでは、左から右や上から下に読むことを想定した言語のプロパティは動作しません。最新の CSS では、テキストの軸(方向)を扱うルールは、start や end のように flow-relative(テキストの方向に相対的)な語句を使って提供されています。

Chrome でこれを最初に実装したのは、CSS Logical Properties and Values 仕様によるおおまかな flow-relative 機能の実装でした。Chrome 87 では、この省略形が導入され、
このような論理プロパティと値が少しばかり書きやすくなります。具体的には、これまで複数の CSS ルールで書いていたことを 1 つのルールで書けるようになります。たとえば、margin-block-startmargin-block-end という別々のルールを、1 つの margin-block プロパティを使って書けるようになりました。

現在 Chrome でサポートされているすべての flow-relative の省略形の一覧や、その使い方の説明については、flow-relative の省略形による論理レイアウトの拡張をご覧ください。その他の CSS 関連のアップデートについては、下の CSS のセクションをご覧ください。

完了したオリジン トライアル

オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。

Cookie Store API

Cookie Store API は、HTTP Cookie を Service Worker に公開するとともに、document.cookie に代わる非同期的な仕組みを提供します。

今回のリリースに追加されたその他の機能

Cross-Origin Isolation

Chrome 87 では、Cross-Origin Isolation に関する多数の変更が行われています。Chrome は、Cross-Origin Isolation エージェント クラスタのエージェント クラスタキーとして、サイトではなくオリジンを使うようになります。Cross-Origin Isolation エージェント クラスタでは、document.domain の変更はサポートされなくなります。この変更と合わせて、window.crossOriginIsolated も導入されます。これは、Cross-Origin Isolation が必要な API の使用が許可されているかどうかを示すブール値です。サポートされる API は以下になります。

詳しくは、Making your website "cross-origin isolated" using COOP and COEP をご覧ください。

Same-Origin iframe のドキュメント アクセスを制限する iframe 属性

disallowdocumentaccess プロパティを追加し、同じ親ドキュメント内の Same-Origin から iframe 間のクロスドキュメント スクリプティングを許可しないようにします。これにより、Same-Origin の iframe を別々のイベントループに入れるようにもなります。

isInputPending()

長時間実行されるスクリプトによって、ユーザーの入力がブロックされることがあります。アプリでユーザーのアクションとレスポンスの間にタイムラグが発生すると、ユーザー エクスペリエンスが悪化します。これに対処するため、Chrome に isInputPending() というメソッドが追加されました。このメソッドには、長時間実行するオペレーションから navigator.scheduling を通して呼び出すことでアクセスできます。メソッドの使用例は、ドラフト版の仕様に掲載されています。

Service Worker の Range リクエスト ヘッダー

ここ数年の間に主要なブラウザで利用できるようになった HTTP 範囲リクエストを使うと、サーバーがクライアントにリクエストされた範囲のデータをチャンク形式で送信できます。この機能は、大きなメディア ファイルで特に有効です。スムーズな再生を実現し、一時停止や再開の機能を改善できるので、ユーザー エクスペリエンスを向上できます。

従来、範囲リクエストと Service Worker はうまく連携できませんでした。そのため、デベロッパーは回避策を構築せざるを得ませんでした。Chrome 87 より、Service Worker からネットワークに範囲リクエストを渡しても、通常どおり動作するようになります。

範囲リクエストに関する問題の説明や、Chrome 87 の変更点については、Service Worker で範囲リクエストを扱うをご覧ください。

Stream API: Transferrable Streams

Transferrable Streams で、postMessage() の引数に ReadableStreamWritableStreamTransformStream オブジェクトを渡せるようになります。Stream API では、データ ストリームの作成、構成、使用のためのユビキタスで相互運用可能なプリミティブが提供されます。ストリームは、Web Worker に渡して使うのが一般的です。この流れるようなプリミティブにより、作業を別のスレッドにオフロードできます。

ワーカーに作業をオフロードすることは、スムーズなユーザー エクスペリエンスを提供する上で重要なことですが、人間工学的に不自然になる可能性があります。Transferrable Streams は、このストリームの問題を解消します。ストリーム自体を転送すると、データは透過的にバックグラウンドにクローンされます。

遷移関連のイベント ハンドラ

ontransitionrunontransitionstartontransitioncancel イベント ハンドラ属性を利用すると、要素、Document オブジェクト、Window オブジェクトに 'transitionrun''transitionstart''transitioncancel' イベントに対応するイベント リスナーを追加できます。

WakeLockSentinel.released 属性

WakeLockSentinel オブジェクトに released という新しいプロパティが追加されます。このプロパティは、sentinel が既にリリースされているかどうかを示します。デフォルトは false で、release イベントがディスパッチされると true になります。この新しい属性によって、ウェブ デベロッパーはロックのリリース タイミングを確認できるようになり、手動でトラッキングする必要はなくなります。

CSS

フォント メトリックをオーバーライドする @font-face 記述子

新しい @font-face 記述子ascent-overridedescent-overrideline-gap-override に追加され、フォントのメトリックをオーバーライドできるようになりました。これにより、ブラウザやオペレーティング システム間の相互運用性が改善され、OS やブラウザによらず同じサイトで同じフォントが常に同じ外見になります。また、別のグリフで同時に提示される 2 つのウェブフォント間のメトリックを合わせます。さらに、フォールバック フォント用にフォントのメトリックをオーバーライドしてウェブフォントをエミュレートし、Cumulative Layout Shift(ページのレイアウトのずれ)を最小限に抑えます。

テキスト修飾と下線プロパティ

Chrome でいくつかの新しいテキスト修飾と下線プロパティがサポートされます。これらのプロパティを使うと、下線がテキストのベースラインに近すぎる場合や、下線が途切れる位置が早すぎる場合に対処できます。これは、text-decoration-skip-ink プロパティが導入されたことで起こるようになった問題を解決するものです。新しいプロパティは、text-underline-positiontext-decoration-thicknesstext-underline-offsetfrom-font キーワードです。

quotes プロパティが 'auto' 値をサポート

CSS2 では、ブラウザが quotes プロパティのデフォルト値を定義することが許可されていました。これまで、Chrome はそれに従っていました。Chrome 87 は CSS Generated Content Module Level 3 に従い、'auto' キーワードがデフォルト値になります。この仕様では、要素や親要素のコンテンツ言語に基づいてタイポグラフ的に適切な値を引用符に使用する必要があります。

JavaScript

このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 8.7 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。

Atomics.waitAsync()

Chrome は、Atomics.wait() の非同期版である Atomics.waitAsync() をサポートします。プログラマーが Atomics.waitAsync() を使うと、Atomics.wait() と同じように SharedArrayBuffer の位置で待機できますが、返されるのは Promise になります。

Atomics.wait() はスレッドをブロックするので、ブロックが許可されていないウェブブラウザのメインスレッドでは使用できません。この仕組みは、SharedArrayBuffers を通してメインスレッドとワーカー スレッド間の調整を行うことで、人間にとって使いやすい形を実現します。

サポートの終了と機能の削除

このバージョンの Chrome では、以下のサポートの終了および機能の削除が行われます。現在サポートが終了している機能および以前に削除された機能のリストは、ChromeStatus.com をご覧ください。

iframe の allow 属性のコンマ区切り

<iframe> タグのアクセス許可ポリシー宣言で、アイテム間の区切り文字としてコンマを利用できなくなります。代わりにセミコロンを使うようにしてください。

-webkit-font-size-delta

Blink は、ほとんど使われていない -webkit-font-size-delta プロパティをサポートしなくなります。フォントサイズを調整したい場合は、代わりに font-size を使うようにしてください。

FTP のサポート終了

Chrome では、FTP URL のサポートを終了して削除する作業が進んでいます。Google Chrome の現在の FTP 実装は、暗号化接続(FTPS)やプロキシをサポートしていません。ブラウザからの FTP の利用率はかなり低く、既存の FTP クライアント機能の改善に注力するのは現実的ではありません。また、影響するすべてのプラットフォームで、機能の豊富な FTP クライアントが利用できます。

Google Chrome 72 以降では、FTP によるドキュメント サブリソースのフェッチと、トップレベル FTP リソースのレンダリングのサポートが削除されています。現在、FTP URL を開くと、リソースの種類によって、ディレクトリ一覧またはダウンロードが表示されます。Google Chrome 74 以降のバグにより、HTTP プロキシを経由した FTP URL へのアクセスがサポートされなくなっています。FTP のプロキシ サポートは、Google Chrome 76 で完全に削除されました。Chrome 86 では、FTP がプレリリース チャンネル(Canary 版とベータ版)で無効になり、安定版のユーザーの 1% でも試験的に無効化されました。

Google Chrome の FTP 実装に残された機能は、暗号化されていない接続でのディレクトリ一覧の表示とリソースのダウンロードのみとなっています。

なお、サポート終了のスケジュールは以下のようになっています。

Chrome 87

デフォルトで、FTP サポートは 50% のユーザーに対して無効化されますが、フラグを使うと有効化できます。

Chrome 88

FTP サポートが無効化されます。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は David Schinazi - Chrome QUIC テックリード、Fan Yang - Google Front End QUIC テックリード、Ian Swett - ウェブ パフォーマンス テックリード マネージャーによる Chromium Blog の記事 "Chrome is deploying HTTP/3 and IETF QUIC" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

QUIC は、TCP や TLS などの機能を組み合わせた新しいネットワーク転送プロトコルです。HTTP/3 は、ウェブ トラフィックの大半を扱っているプロトコルである HTTP の最新バージョンです。HTTP/3 は QUIC 上でのみ動作します。


QUIC はもともと Google によって開発され、2013 年に初めて発表されました。その後、このプロトコルは成熟し、現在は Google のトラフィックの 3 分の 1 以上を扱うほどになっています。Google は 2015 年に QUIC を IETF(インターネットのプロトコルを管理する標準団体)に提唱し、IETF は QUIC にたくさんの変更を加えて改善してきました。現時点では、Google QUIC と IETF QUIC という、似て非なる 2 つのプロトコルが存在しています。Google の QUIC チームは当初から IETF プロセスに関与していましたが、IETF QUIC の実装が進む間も Chrome では Google QUIC が使われ続けています。ここ 5 年間にわたり、私たちは IETF の変更に追従して Google QUIC を進化させるために膨大な作業を続けてきました。現在の最新版の Google QUIC バージョン(Q050)は、多くの点で IETF QUIC と共通しています。しかしこれまで、大多数の Chrome ユーザーは、いくつかのコマンドライン オプションを有効化しなければ IETF QUIC サーバーと通信できませんでした。


本日からは違います。TCP と TLS 1.3 で HTTP を使う場合よりも、IETF QUIC を使う方が圧倒的にパフォーマンスがいいことがわかっています。特に、Google 検索にかかる時間は 2% 以上短くなります。YouTube の再バッファリング時間は 9% 以上も短くなり、クライアントのスループットは PC で 3% 以上、モバイルで 7% 以上増加します。そこで、Chrome で IETF QUIC(具体的には、ドラフト バージョン h3-29)のサポートがリリースされることをお知らせします。現在、Chrome 安定版ユーザーの 25% が h3-29 を使っており、今後数週間で、パフォーマンス データを監視しながらその数を増やす予定です。Google QUIC Q050 をサポートするサーバーが IETF QUIC にアップデートできるように、Chrome は IETF QUIC h3-29 と Google QUIC Q050 の両方をサポートする予定です。


Chrome 85 はまだ IETF QUIC 0-RTT をサポートしていないので、数か月後に IETF QUIC の 0-RTT サポートがリリースされれば、パフォーマンスの数値はさらに向上するはずです。


続く IETF ドラフト 30 および 31 には互換性に影響を与える変更はないため、今のところ over-the-wire 識別子を変更する予定はありません。つまり、IETF 仕様の変更には追従するものの、変更は h3-29/0xff00001d という名前で展開する予定です。そのため、Chrome との相互運用性を確保したいサーバーは、確定版の RFC が完成するまで h3-29 のサポートを続けることを推奨します。ただし、IETF が今後のドラフトで互換性に影響する変更を行った場合は、Chrome でもこの判断が再考される可能性があります。


このブログの執筆者一同は、このお知らせにつながる懸命な作業を行ってくれた Google の QUIC チーム全員に感謝します。私たちがともに成し遂げたことを誇りに思っています。IETF で QUIC に貢献してくださった皆さんと、Google の QUIC チームの元メンバー全員にも感謝を捧げます。皆さんがいなければ、ここでお知らせしたことは実現できませんでした。





Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chrome、シニア プロダクト マネージャー、AbdelKarim Mardini による Google Online Security Blog の記事 "New Password Protections (and more!) in Chrome" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
多くの場合、パスワードは私たちのデジタル生活にとって防御の第一線です。私たちは現在、Android デバイスと iOS デバイスの両方のパスワード セキュリティを向上させる作業を行っています。具体的には、Chrome に記憶させていたパスワードが侵害されたかどうか、そしてもし侵害されていた場合は、その解決方法を通知します。

Chrome はユーザーのパスワードの侵害状況を確認するため、暗号化を施した特別な形式でユーザー名とパスワードを Google に送信します。Google はその情報を使って、侵害が判明している認証情報のリストと突き合わせますが、暗号化した情報からユーザー名とパスワードを取得することはできません。

ウェブサイトのパスワードが侵害されていた場合はユーザーに通知しますが、パスワードを変更する関連フォームを見つけるのは時間がかかることがあります。そこで、".well-known/change-password" URL をサポートします。これにより、Chrome でパスワードの侵害のアラートが表示されると、ユーザーは適切な「パスワード変更」フォームを直接開けるようになります。

この改善に加えて、モバイル版の Chrome にも安全確認を提供します。次のリリースでは、iOS と Android の Chrome に安全確認を導入し、侵害されたパスワードの確認に加え、セーフ ブラウジングが有効になっているかどうか、現在実行している Chrome のバージョンが最新のセキュリティ保護でアップデートされているかどうかの通知を行います。また、iOS 版の Chrome に保存したログイン情報は、他のアプリやブラウザでも自動入力できるようになります。

Chrome 86 では、ユーザーのセキュリティを向上させるたくさんの追加機能もリリースされる予定です。詳しくは、以下の説明をご覧ください。

Android のセーフ ブラウジング保護強化機能

今年、PC 向けにセーフ ブラウジング保護強化機能をリリースしました。これにより、Chrome ユーザーはさらに高度なセキュリティ保護を受けることもできます。

セーフ ブラウジング保護強化機能をオンにすると、Chrome は Google のセーフ ブラウジング サービスとリアルタイムにデータを共有し、先回りでフィッシングやマルウェア、その他の危険なサイトから保護します。ウェブサイトやダウンロードのリアルタイム チェックを有効にすると、予測フィッシング保護によって、フィッシング サイトにパスワードを入力してしまうユーザーは約 20% 減少します。

iOS でのパスワード自動入力の改善

先日、フィッシング攻撃に対する保護として、タッチしてパスワードを自動入力する機能を Android 向けにリリースしました。iOS でもセキュリティを強化するため、パスワードを自動入力する前に生体認証の手続きを追加します。iOS では、Face ID、Touch ID、スマートフォンのパスコードのいずれかを使って認証できます。さらに、[Settings] で Chrome の自動入力を有効にしている場合は、Chrome Password Manager を使って iOS のアプリやブラウザに保存済みのパスワードを自動入力できます。


混合フォームの警告と混合ダウンロードのブロック

更新(2020/10/07): 当初、混合フォームの警告は Chrome 86 でリリースされる予定でしたが、遅延して Chrome 87 になる見込みです。

安全な HTTPS ページの中にも、安全でない機能が含まれる場合があります。今年より Chrome では、安全なページに安全でないコンテンツが含まれる "Mixed Contents" をブロックする保護が行われるようになりました。しかし、HTTPS ページには、その他にもユーザーのセキュリティ リスクとなるものがあります。たとえば、安全でないリンクからのダウンロードの提供、安全でない形でデータを送信するフォームの使用などです。

このような脅威に対するユーザー保護を強化するため、PC と Android の Chrome 86 に混合フォームの警告を導入し、HTTPS ページに埋め込まれた安全でないフォームを送信する前にユーザーに警告します。

さらに、Chrome 86 では、安全なページで安全でないダウンロードを始めると、ブロックされたり警告されたりすることがあります。現時点では、この変更はよく悪用されるファイル形式に対してのみ行われます。しかし将来的には、安全なページでは形式によらず安全なダウンロードのみを開始できるようになる予定です。詳しくは、混合ダウンロードを段階的にブロックする Chrome の計画をご覧ください。

デベロッパーの皆さんは、ユーザーの安全とプライバシーを守るため、安全な接続を使うようにフォームやダウンロードをアップデートしてください。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Chet Haase による Android Developers - Medium の記事 "Now in Android #27" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。




Android 開発の最新ニュースやトピックをご紹介する Now in Android。今回は Android Studio 4.1、MAD Skills シリーズ、Kotlin Vocabulary の追加、Play 請求サービスのサブスクリプション、生体認証、MotionLayout タグ、最近公開されたブログ記事・動画・関連ドキュメント、ポッドキャスト エピソードをご紹介します。

Android Studio 4.1: 現在安定版
先日、Android Studio 4.1 の安定版ビルドがリリースされました。このリリースについては、安定版前のリリースが進んでいるときのエピソードでもお伝えしましたが、いくつかの注目機能について振り返ってみましょう。

  • Database Inspector: IDE からオンデバイス データベースの状態を確認したり、変更を行ったりできます(Jetpack Room または直接 SQLite クエリを使います)。

  • 新しいプロジェクト テンプレート: マテリアル デザイン コンポーネントを使うようにアップデートされています。

  • 統合エミュレータ ウィンドウ: 別のウィンドウでなく、IDE 内で直接エミュレータを実行できます。「統合」せずして統合開発環境と呼ぶことはできません。

  • Dagger/Hilt コード ナビゲーション: ガター部分にアクションが追加され、そこをクリックすると、コードの Dagger や Hilt の型について詳しく確認できます。

  • ML モデルのバインディング: Studio がインポートした TensorFlow Lite モデル用のコードを生成してくれるので、アプリのコードから簡単にモデルを利用できます。

このリリースの詳細は、Yacine Rezgui の動画や Scott Swarthout のブログ記事(英語)Android Studio リリースノートで確認できます。または、ダウンロードしてお試しください。




新連載シリーズ MAD Skills



Modern Android Development(最先端の Android 開発)について取り上げる、 MAD Skills という新シリーズを立ち上げました。このシリーズでは、言語(Kotlin)、ツール、(Android Studio)、API(Jetpack のサブセット)、配信(Android App Bundle)などのさまざまな MAD について紹介する動画やブログ記事を公開します。数週間ごとに、具体的なトピックを扱うミニシリーズがスタートする予定です。




10月第 2 週から、Navigation コンポーネントについてのシリーズをお届けします。第 1 回のエピソードでは、私が API やツールの概要についてお話しします。第 2 回のエピソードでは、ダイアログを開く方法を紹介します。10 月第 3 週は、SafeArgs とディープリンクを扱うエピソードを投稿する予定です。

これまでに投稿された動画は MAD Skills プレイリスト(英語)で確認できます。毎週新しいエピソードが投稿されるので、随時こちらをご覧ください。いつまで続くのかと言うと… まだ予定は未定です。ただ、取り上げるべき技術コンテンツはたくさんあるので、しばらく続くことになるでしょう。

記事形式でコンテンツを読みたい方のために、記事で説明していない内容について取り上げた動画を公開するときは、Medium の Android Developers にも記事を投稿します。今後の MAD 記事にご注目ください。

Kotlin Vocabulary


好評の Kotlin Vocabulary シリーズに、いくつかの新しいエピソードが追加されました。

デフォルト引数

Florina Muntenescu ブログ記事(英語)動画を投稿し、Kotlin の デフォルト引数 の仕組みについて解説しています。デフォルト引数は、Kotlin の強力な言語機能です。オーバーロード関数の数を減らし(4 つではなく 1 つのコンストラクタだけで View.java を実現できることを想像してみてください)、一般的に妥当なデフォルト値が存在する場合にコードを簡単に呼び出せるようになります。



by の活用: Kotlin の委譲


Murat Yener ブログ記事(英語)動画を投稿し、Kotlin の 委譲機能について説明しています。委譲は、別のコードに処理を渡すときに使います。この記事では、 クラス委譲 (クラスの処理を完全に別のクラスに委ねる場合)と プロパティ委譲 (プロパティの基本的な get/set 機能を別のオブジェクトに委ねる場合)の例を示しています。

Kotlin は、インフラと言語キーワード(by)だけでなく、いくつかの組み込み委譲機能(by lazy など)も提供しています。しかし、記事で取り上げているのは、「仕組み」の段階までとなっています。組み込みの委譲に関する説明は、今後の記事でご紹介します。




Play 請求サービスのサブスクリプション

定期購入者の獲得と維持に関して、Caren Chang が Play 請求サービスの新しい機能と要件をサポートする方法を説明する記事を投稿しました(英語)この変更は、11 月 1 日より適用されます。アプリで定期購入商品を販売している方は、対応が必要になる可能性がある点について確認しておきましょう。

編集部注:定期購入プラットフォームに関するすべての変更点について、日本語で解説しています




必ず要件をご確認の上、対応期限である 2020 年 11 月 1 日までに各機能のテストをお済ませください。

生体認証

Isai Damier が Android の生体認証に関する 2 回シリーズの記事を投稿しました。
パート 1 では、生体認証の組み込みを検討すべき理由について説明しています。たとえば、ユーザーがアプリに頻繁にログインしなければならない場合、生体認証を提供すると必要な操作をすばやく簡単に行えます。インストール後に一度だけログインすればいいアプリなら、(おそらくパスワードによるログインは面倒なので)生体認証は従来のパスワードによるログインに比べて、ユーザーのセキュリティを向上させつつ便利なログインの仕組みを提供する方法になるかもしれません。


編集部注:Android 11 の画面ロックと生体認証を含む認証機能については「Android 11 のロック画面と認証の改善」で詳しくご説明しています。


Motion Tags: KeyPosition

Motion Tags シリーズに、KeyPosition について説明したエピソードを投稿しました。KeyPosition タグは、MotionLayout アニメーションのレイアウト情報を指定します。これまでのエピソードは、Motion Tags プレイリストからご覧ください。



ADB (Android Developers Backstage) ポッドキャスト 新エピソード



Android Developers Backstage に新しいエピソードが投稿されています。以下のリンクまたはお気に入りのポッドキャスト クライアントでご確認ください。


Tor NorbyeRomain Guy、そして私が、フレームワーク チームの Ryan Mitchell から、aapt2 ツールの動作の仕組みなど、リソースについて話を聞きました。

またお会いしましょう
今回は以上です。次回も Android デベロッパーの世界の最新アップデートをお届けします。お楽しみに。



Reviewed by Takeshi Hagikura - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing APAC

この記事は Frank van Puffelen による The Firebase Blog の記事 "Firebase Summit 2020: A Two Day Virtual Event" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Frank van Puffelen
デベロッパー プログラム エンジニア
Firebase Summit 2020 バナー

スペインのマドリードで Firebase Summit 2019 を開催し、Firebase の最新情報をお伝えしたり、プロダクトに関するフィードバックに耳を傾けたりしてから 1 年が経ちました。その後、私たちが知る世界は変わってしまいましたが、Firebase のミッションは変わりません。そのミッションとは、モバイルアプリやウェブアプリの構築や運用を容易にして、デベロッパーの皆さんの成功をサポートすることです。

私たちは、アプリ開発の高速化、ユーザーの分析機能の提供、そしてスケーリングに役立つツールを構築するため、作業を続けています。今年はバーチャルで開催される Firebase Summit で、そのようなアップデートについてお知らせできることを楽しみにしています。太平洋標準時の 10 月 27-28 日、両日とも午前 9 時 30 分(日本時間の翌日午前 2 時 30 分)から開催されます。モバイル端末やノートパソコンを準備して firebase.google.com/summit を開くだけで、どこからでも視聴できます。

直接皆さんとお会いできないのは残念ですが、今年は今まで以上に多くのデベロッパーが参加してくれることを楽しみにしています。

次に、この 2 日間で期待できることをご紹介します。

Firebase のプロダクトやサービスについての最新情報を得る

10 月 27 日午前 9 時 30 分(太平洋標準時)の基調講演では、アプリの構築や運用に Firebase がどう役立つかについてお話しします。基調講演後にはチャットで質問を受け付け、#AskFirebase で Firebase チームがライブで回答します。

最新リリースのモニタリング、ユーザー エンゲージメントの向上、アプリの収益最適化などのトピックを扱う 11 のテクニカル セッションにもご期待ください。各セッションは 2 日間にわたってライブ配信されるので、視聴しながら他のデベロッパーや Firebase チームとチャットできます。さらに、都合のいい時間にオンデマンドで視聴することも可能です。

専門技術を強化する

ハンズオンの学習体験として、Flutter と Firebase を使ってアプリをゼロからコーディングする様子をライブでお見せします。また、新しいデモの他、チュートリアル動画や詳しい手順が付いた Codelab を試して、Firebase を使ったウェブアプリの構築方法などの人気トピックについて学ぶこともできます。

Firebase Summit の詳細については、これから数週間でさらに詳しくお知らせする予定です。それまでの間、最新情報を受け取るためにイベントのページに登録し、Firebase YouTube チャンネルも登録しておきましょう。また、Twitter をフォローして会話に参加してください。



Reviewed by Takuo Suzuki - Developer Relations Team

この記事は Justin Schuh - Chrome エンジニアリング、ディレクターによる Chromium Blog の記事 "Progress on Privacy Sandbox and building a more private web" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 


昨年、一連のオープンな標準を作成してウェブのプライバシーを抜本的に強化する新しい取り組み(プライバシー サンドボックスと呼ばれています)についてお知らせしました。プライバシー サンドボックスでは、ユーザーのデータを保護して煩わしいクロスサイト トラッキングを防ぐプライバシー保護の仕組みについて、ウェブ コミュニティとともに検討しています。その目的は、今後も人々の期待に応える豊かで良質なコンテンツやサービスを実現しつつ、プライバシーや安全性の保証をさらに強化することによって、オープンウェブの活力を維持することです。本日は、この長期的な取り組みの進捗状況についてお知らせします。ウェブのブラウジングにおけるプライバシーを強化するために、皆さんも引き続きご協力をお願いします。

1 月には、サードパーティー Cookie を廃止してプライバシーを保護するオープンな標準を作成するという方向性についてお知らせしました。それ以降、Google他社は、詐欺からの保護、広告の選択、コンバージョンの測定などのユースケースについて、ウェブサイトをまたがってユーザーの活動をトラッキングできない形で対処するいくつかの新 API を提案しています。これらのソリューションのうちのいくつかは、ウェブ コミュニティからの意見に従って Chrome のオリジン トライアルとして試験運用版によるテストが可能になっています。
  • Click Conversion Measurement API は 9 月からテスト可能になりました。この API の目的は、広告のクリックが別のサイトのコンバージョン(購入や登録など)につながったかどうかをマーケティング担当者が把握できるようにすることです。それぞれのサイト間でユーザーの ID が結びつけられることはありません。
  • トラスト トークンは 7 月からテスト可能になりました。この目的は、詐欺対策を含む、ユーザーの正当性を評価するさまざまなユースケースをサポートすることです。
API をプロダクトやサービスに組み込みたい方は、Chrome のオリジン トライアルでこれらの API などにアクセスできるように登録してください。エコシステムのステークホルダーは、ぜひこれに参加して、フィードバックや結果を共有してください。ウェブのコア アーキテクチャを変更するウェブの標準を作成して実用化するのは、複雑なプロセスです。そのため、協力関係に基づいた長期的なアプローチをとっています。

また、現在のウェブ技術の安全性とプライバシーをさらに強化するための作業も続けています。
  • 今年、Chrome はクロスサイト トラッキングの制限を始めました。具体的には、SameSite ラベルを含まない Cookie はファースト パーティー専用として扱い、Cookie をサードパーティー コンテキストで利用するには HTTPS ラベルをつけて HTTPS でアクセスすることを必須にしています。このアップデートは、EdgeFirefox でも導入に向けた作業が続いています。これにより、サードパーティー Cookie を必要としない登録ドメインの 99.9% に Cookie が送られなくなり、ウェブの大半のサイトでプライバシーとセキュリティが向上します。
  • Chrome の来年初頭のリリースでは、ユーザーの特権認証情報を盗んでアカウントに悪意のある操作を行うタイプのネットワーク攻撃への保護も強化される予定です。 
さらに Chrome では、フィンガープリンティングなどの詐欺的で煩わしいトラッキング技術による影響を受けにくくする変更をロールアウトしています。
  • 9 月には、ユーザー名やアクセス トークンなどの情報が意図せず共有されることを防ぐアップデートをロールアウトしました。ユーザーがあるサイトから別のサイトに移動したとき、デフォルトで遷移先サイトに送信される元のページの URL 情報を減らしています。
  • 同じく 9 月に、Chrome の Secure DNS サポートを拡張し、PC に加えて Android も対象に含めました。Secure DNS は、ウェブをブラウジングする際のユーザーの安全性とプライバシーの向上を目的としています。具体的には、ユーザーの現在のプロバイダが DNS-over-HTTPS をサポートしている場合、自動的に DNS-over-HTTPS に切り替えます。
  • ユーザーがキャッシュの仕組みを使ってアクセスしたサイトを別のサイトから確認できる機能は、近日中にクローズする予定です。
いつものように、ウェブ標準コミュニティの提案が皆さんのニーズに合致するように、ぜひ GitHub からフィードバックをお送りください。ニーズを満たしていない場合は、GitHub やメールで W3C グループに問題を送信してください。ウェブでビジネスを行っている方は、技術ベンダーがこのプロセスに関与していることや、皆さんの利益を代表するトレード グループが積極的に関与していることを確認してください。

信頼性の高いサステイナブルなウェブを一緒に構築する取り組みに参画していただけることに感謝します。ウェブ ブラウジングのプライバシーを強化する取り組みの進展については、今後も投稿を通してお知らせいたします。 



Reviewed by Eiji Kitamura - Developer Relations Team

この記事はプログラム マネージャー、Maria Tabak、Erin McKean – Google Open Source プログラム オフィスによる Google Open Source Blog の記事 "Announcing the latest Google Open Source Peer Bonus winners!" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 

 今年の Google Open Source Peer Bonus の受賞者を発表します!

Google Open Source Peer Bonus プログラムは、オープンソースにひときわ貢献した外部のオープンソース貢献者を Googler がノミネートして表彰する制度です。従来、このプログラムは主にデベロッパーを表彰することに主眼を置いてきました。年を経るとともにこのプログラムは進化を遂げ、ソフトウェア エンジニアだけでなく、テクニカル ライター、ユーザー エクスペリエンスやグラフィックのデザイナー、コミュニティのマネージャーやマーケティング担当者、助言者や教育者、運用やセキュリティのエキスパートなど、オープンソースのあらゆる部分に貢献した方が表彰されるようになりました。


今回は 90 名の受賞者が選ばれ、その出身国はなんと 5 大陸の 24 か国にのぼります。具体的には、オーストラリア、オーストリア、カナダ、中国、コスタリカ、フィンランド、フランス、ドイツ、ガーナ、インド、イタリア、日本、モザンビーク、ニュージーランド、ナイジェリア、ポーランド、ポルトガル、シンガポール、スペイン、スウェーデン、スイス、ウガンダ、イギリス、アメリカです。

今回のラウンドでは、受賞者の大半はコードの貢献が評価されましたが、ノミネートされた方の 40% 以上がツールやコミュニティ、ドキュメントに関する作業に携わっていました(複数の領域での作業が認められた貢献者も存在します)。

受賞者のうち、氏名を公表して謝意をお伝えすることを承諾してくださった方を以下にご紹介します。


受賞者プロジェクト
Xihan LiA Concise Handbook of TensorFlow 2
Alain SchlesserAMP Plugin for WordPress
Pierre GordonAMP Plugin for WordPress
Catherine HouleAMP Project
Quyen Le HoangANGLE
Kamil BregulaApache Airflow
László Kiss Kollárauditwheel/manylinux
Jack NeusChrome OS Release Branching tool
Fabian Hennekechromium
Matt GodboltCompiler Explorer
Sumeet Pawnikarcoreboot
Hal Sekicovid19
Derek ParkerDelve
Alessandro ArzilliDelve
Matthias SohnEclipse Foundation
Luca MilanesioEclipse Foundation
João Távoraeglot
Brad Cowiefaucetsdn
Harri HohteriFirebase
Rosário Pereira FernandesFirebase
Peter SteinbergerFirebase iOS、CocoaPods
Eduardo SilvaFluent Bit
Matthias SohnGerrit Code Review
Marco MillerGerrit Code Review
Camilla LöwyGLFW
Akim DemailleGNU Bison
Josh Bleecher SnyderGo
Alex BrainmanGo
Richard MusiolGo
Roger PeppeGo、CUE、gohack
Daniel MartíGo、CUE、多数の個別リポジトリ
Juan LinietskyGodot Engine
Maddy MyersGoogle Research Open-COVID-19-Data
Pontus Leitzlergovim、gopls
Paul Jollygovim、gopls
Parul RahejaGround
Pau FreixesgRPC
Marius BrehlerIREE
George Nachmaniterm2
Kenji Urushimajsrsasign
Jacques ChesterKNative
Markus ThömmesKnative Serving
Savitha RaghunathanKubernetes
David Andersonlibdwarf
Florian WestphalLinux kernel
Jonas Bernoullimagit
Hugo van Kemenade多数のオープンソース Python プロジェクト
Jeff LockhartMaps SDK for Android Utility Library
Claude VervoortMoodle
Jared McNeillNetBSD
Nao Yonashironginx-sxg-module
Geoffrey BoothNode.js
Gus CaplanNode.js
Guy BedfordNode.js
Samson GoddyOpen Source Community Africa
Daniel DylaOpenTelemetry
Leighton ChenOpenTelemetry
Shivkanya AndhareOpenTelemetry
Bartlomiej ObecnyOpenTelemetry
Philipp WagnerOpenTitan、Ibex、CocoTB
Srijan ReddyOppia
Chris SOppia
Bastien GuerryOrg mode
Gary KramlichPidgin Lead Developer
Hassan Kibirigeplotnine
Abigail DogbePyLadies Ghana
David HewittPyO3
Yuji KanagawaPyO3
Mannie YoungPython Ghana
Alex BradburyRISC-V LLVM、Ibex、OpenTitan
Lukas Taegert-AtkinsonRollup.js
Sanil RautShaka Packager
Richard Hallowsstylelint
Luke EdwardsSvelte および Node Libraries
Zoe CarverSwift Programming Language
Nick LockwoodSwiftFormat
Priti DesaiTekton
Sayak PaulTensorFlow
Lukas GeigerTensorFlow
Margaret Maynard-ReidTensorFlow
Gabriel de MarmiesseTensorFlow Addons
Jared MorganThe Good Docs Project
Jo CookThe Good Docs Project、GeoNetwork、Portable GIS、Various Open Source Geospatial Foundation コミュニティ
Ricky Mulyawan SuryadiTink JNI Examples
Nicholas MarriottTmux
Michael Tüxenusrsctp
Seth BrenithV8
Ramya RaoVS Code Go
Philipp HanckeWebRTC
Jason DonenfeldWireGuard


受賞者の皆さん、おめでとうございます!皆さんの今後のオープンソースへのサポートや貢献に期待しています!


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Steve Suppe による Android Developers Blog の記事 "Optimize your app publishing process with new Google Play Console features" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



アプリやゲームの公開は、アプリのライフサイクルの中でも特に重要な瞬間です。本番リリースを安定させ、テストリリースをすばやく公開し、マーケティングに関してのメッセージに適切に掲載するなど、すべてをスムーズに行う必要があります。そのためには、 アプリのステータスが見えることが重要です。Google Play でアプリの審査がいつ行われ、いつ承認され、いつ公開できる状況になるのかを把握できれば、リリース スケジュールを立てやすくなります。

新しい Google Play Console の 2 つの新機能で、それを可能にしました。[公開の概要] ページでは、アプリの公開が完了するまでの流れを把握しやすくなりました。また、管理対象の公開を利用すると、Google Play でアプリのアップデートを公開するタイミングを細かく制御できます。11 月 2 日に新しい Play Console が全ユーザーに適用されると、これらの機能がリリースのタイミング管理の推奨方法になります。この記事では、アプリの公開管理機能を詳しくご説明します。

公開の概要
新しい [公開の概要] ページには、リリースやストアの掲載情報などに対する最近の変更がすべて表示されます。これには、現在審査中の変更や、Google Play が処理中の変更も含まれます。大規模なチームに所属している方は、すべての変更を 1 か所で管理して同時に公開できるようになります。

公開の概要は、デベロッパーのアクティビティ ログとは異なり、Google Play での表示上の変更や、アプリの審査に関わる、国・地域やアプリのコンテンツ等の変更しか表示されません。

[審査中の変更] セクションでは、まだ公開されていない変更をすばやく確認できる


変更は、変更の種類やリリース トラック別に整理されているので、一目で簡単に把握できます。

管理対象の公開

旧 Play Console の時間指定公開機能をよくご存知の方も多いでしょう。新しい Play Console では、「時間指定公開」が「管理対象の公開」に変わりました。これにより、公開の操作がさらにわかりやすく、思いどおりに動作するようになります。


管理対象の公開を有効にすると、審査で変更が承認されて処理が完了した後に自動的に公開されるのではなく、[確認して公開] 後にのみ公開されるようになります。公開を確定すると、数分以内にアップデートが Google Play に公開されます。これにより、リリース予定日よりもかなり早く変更を送信でき、公開日に対する制御を失わずに確認や変更の時間がとれるようになります。

どの変更が審査、承認されたかを確認する


管理対象の公開がオンになっている場合、[公開の概要] ページに 2 つのセクションが表示されます。1 つは承認されて公開の準備が整っている変更、もう1つはまだ審査中の変更です。
加えて、多くの方から寄せられたいくつかの改善要望にも対応しています。

  •  一部の変更がまだ審査中であっても、承認済みの変更のみを公開できるようになっています。これまでの時間指定公開では、すべての変更が承認されるまで、どの変更も公開できませんでした。

  • 管理対象の公開は、審査中の変更や公開準備が整った変更がある場合も含め、いつでもオンまたはオフにできます。管理対象の公開を使うために審査が終わるのを待つ必要はなくなります。

  • 時間指定公開は [公開] をクリックするとオフになり、使用するたびに再度オンにする必要があります。管理対象の公開は、デベロッパーが手動でオフにするまでオンのままになります。


管理対象の公開がオンになっているかどうかは、左側のナビゲーション メニューで確認できる


近日中に、左側のナビゲーションの [公開の概要] の隣に管理対象の公開アイコンが表示されるようになります。これにより、Play Console のどこからでも管理対象の公開がオンかどうかを確認できます。

新しい Play Console の公開機能について詳しく知りたい方は、Play Academyこちらのコース(英語)をご覧ください。まだ新しい Play Console を試していない方は、play.google.com/console にアクセスして、ぜひ管理対象の公開をお試しください。



Reviewed by Naoki Oyama - Partner Development Associate, Mai Kato - Product Excellence Lead, Google Play and Hidenori Fujii - Google Play Developer Marketing, APAC



あらゆるアプリーケーション、サービスで、AI を活用し新たな価値を創造することが重要な時代になってきています。そこで、Google は、データ サイエンティスト、アプリケーション開発者向けに、最新の Google Cloud AI や、機械学習サービスの活用例などを紹介する 「Google Developers ML Summit」をオンラインで開催します。


TensorFlow、Cloud AI などの活用事例、機械学習モデルの開発や利用、また、データ サイエンティスト / 機械学習エンジニアを繋げるプラットフォーム「Kaggle」 についてご紹介します。


合わせてスピーカーを募集しています。奮ってご応募ください。(締切 : 10 月 19 日(月)9:00 AM)


■ 日程
2020 年 12 月 3 日(木) (アプリ開発)
2020 年 12 月 4 日(金) (クラウド、データ サイエンス)
※ 時間は変更になる場合があります。


■ 詳細・お申し込みはこちら
http://goo.gle/mlsummit-b1


■ プログラム
10 月末公開予定




Posted by Takuo Suzuki - Developer Relations Team

この記事は Haining Chen, Vishwath Mohan, Kevin Chyn, Liz Louis による Android Developers Blog の記事 "Lockscreen and Authentication Improvements in Android 11" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


スマートフォンはますます高速化し、高機能になっています。そして、私たちの記憶力を補ったり、世界とつながり、友人や家族やその先のコミュニティと連絡を取り合うための主なインターフェースになり、私たちの暮らしの中で重要な役割を果たしています。この進化に合わせて、私たちが最も個人的な情報をスマートフォンに保存し、管理するようになったことも自然な流れです。そして私たちは、さまざまな形でスマートフォンをデジタルな自分や実際の自分の拡張として扱うようになっています。

スマートフォンに個人情報を預ける、その信頼を得て守ることこそ Android セキュリティ チームの最優先事項です。チームは Android デバイスがユーザーデータのプライバシーや機密性を尊重することを重視しています。その作業の土台となるのが、いわばデバイスの正面玄関となるロック画面です。つまり、ロック画面はデバイスを所有している特定のユーザーだけが個人データにアクセスできることを保証します。

このブログ記事では、Android デバイスのロック画面操作に関する最近の改善点について説明します。さらに、もう少し一般的な認証についても触れたいと思います。とりわけ、生体認証と環境という 2 種類の認証方式について重点的に取り上げます。この 2 つは潜在的に大きな可能性を秘めていると同時に、適切に設計されなければ重大なリスクにもなり得ます。

階層化認証モデル

ロック画面と認証の改善点について詳しく説明する前に、いくつかの背景情報をお伝えします。この情報は、今回の改善点における相互の関連性を把握するために役立ちます。今回の変更は、階層化認証モデルのフレームワークに当てはめてみるとイメージしやすいはずです。階層化認証モデルとは、Android に搭載されているすべての認証方式を概念的に分類し、相互の関連性や、この分類に基づく制約をまとめたものです。

このモデル自体はかなりシンプルで、認証方式を 3 つに分類しています。階層が上がるほどセキュリティのレベルは下がり、それに比例して制約が増えます。第 1 階層では、ユーザーが機能を利用するために第 1 の認証方式の再入力を求められるのは、特定の状況下(たとえば、起動ごとや 72 時間ごとなど)のみであるため、制約は最も少ないと言えます。第 2 階層と第 3 階層の制約はさらに強くなります。最初に第 1 の認証方式が登録されていないと設定および利用できないうえに、機能を制限するさらに強い制約が存在するためです。

  1. 第 1 階層 - 知識ファクタ:
    最初の階層は、知識ファクタ、すなわちユーザーが知っていることを利用する方式です。たとえば、PIN(暗証番号) やパターン、パスワードなどです。推測しにくい複雑なパスワードなど、エントロピーの高い優れた知識ファクタは、最高レベルの身元保証を提供できる可能性があります。

    Android では、デバイスがハードウェア機能と指数バックオフによって総当たり攻撃に対する保護を提供しているため、知識ファクタは特に有用です。つまり、Android デバイスでは、5 回失敗するたびにハードウェア機能によるタイムアウトが適用されるため、攻撃者が PIN やパターン、パスワードを繰り返し予測することはできません。知識ファクタを利用するすべてのユーザーには、ファイルベースの暗号化(File Based Encryption、FBE)や暗号化デバイス バックアップなどを使用できるという追加のメリットもあります。

  2. 第 2 階層 - 生体認証: 第 2 階層は主に生体認証で構成されます。これは、 ユーザー自身で認証する方式です。第 2 の認証方式の例として、顔や指紋による認証があげられます。生体認証は利便性が高くなりますが、デバイスでユーザーの身元を確認する方法としてのセキュリティは低くなる可能性があります。Android の生体認証については、次のセクションで詳しく取り上げます。

  3. 第 3 階層 - 環境: 最後の階層は、 ユーザーの所有物を利用する方式です。その 1 つが物理トークンです。たとえば、Smart Lock の信頼できるデバイスを使う場合、許可リストに登録された Bluetooth デバイスとペアリングしてスマートフォンをロック解除します。また、デバイス周辺の物理環境に固有のものを使うこともできます。たとえば、Smart Lock の信頼できる場所では、スマートフォンを許可リストに登録された場所に運ぶことでロックを解除できます。
第 3 の認証の改善

信頼できる場所や信頼できるデバイス(そして一般的な第 3 の方式)を使うと、便利な方法でデバイスの内容にアクセスできます。しかし、これらに共通する根本的な問題は、最終的にユーザーの身元確認機能の精度の低さに集約されます。たとえば、信頼できる場所を使っているスマートフォンのロックは、ユーザーの自宅のそばを通り過ぎるだけで解除できるかもしれません。また、既製のソフトウェア無線と多少のスクリプトを使えば、比較的簡単に GPS シグナルを偽装することもできます。信頼できるデバイスも同様で、許可リストに登録された Bluetooth デバイスにアクセスできれば、ユーザーのスマートフォン内のすべてのデータにアクセスできることになります。

そこで、Android 10 の環境階層に大幅な改善が加えられ、第 3 階層は積極的にロックを解除する仕組みからロック解除を延長する仕組みに変わっています。この新しいモードでは、第 3 階層でデバイスのロックを解除できなくなりました。その代わり、最初に第 1 の方式か第 2 の方式を使ってデバイスのロックを解除している場合、最大 4 時間にわたってロック解除状態を継続します。

Android の生体認証の詳細

生体認証の実装には、幅広いセキュリティ特性があります。そこで、次にあげる 2 つの重要な要素を利用して特定の実装のセキュリティを判定しています。

  1. 構造上のセキュリティ: カーネルやプラットフォームの侵害に対する生体認証パイプラインの耐性を表します。カーネルやプラットフォームが侵害され、未加工の生体認証データが読み取られたり、パイプラインに合成データを注入されたりしても認証結果に影響が及ぶことがない場合、パイプラインは安全であると見なされます。

  2. なりすましの可能性: なりすまし受け入れ率(Spoof Acceptance Rate、SAR)で測定します。SAR は Android P で初めて導入された指標で、なりすましに特化した攻撃に対する生体認証の耐性を測定することを目的としています。SAR の詳細や測定方法については、生体認証を用いたロック解除のセキュリティ測定をご覧ください。
この 2 つの要素を使い、セキュリティの高い順に並んだ 3 つのクラスのいずれかに生体認証を分類します。
  • クラス 3(以前の「強」)
  • クラス 2(以前の「弱」)
  • クラス 1(以前の「便利」)

各クラスには、一連の制約が紐付いています。この制約は、それぞれの使いやすさとセキュリティのレベルのバランスをとることを目指したものです。

制約は、生体認証が第 1 階層の認証にフォールバックするまでの時間と、許可されているアプリ統合で表されています。たとえば、クラス 3 の生体認証はタイムアウトまでの時間が最も長く、すべてのアプリ統合オプションを利用できます。一方、クラス 1 の生体認証はタイムアウトまでの時間が最も短く、アプリ統合オプションは提供されません。概要を下の表に示します。完全版を確認したい方は Android Compatibility Definition Document(CDD)をご覧ください。

1 App Integration(アプリ統合)とは、API をアプリに公開すること(例: BiometricPrompt/BiometricManager、androidx.biometric、FIDO2 API などの統合によって)を意味します。

2 Keystore Ingegration(キーストア統合)とは、キーストアを組み込むこと(例: アプリの認証バインドキーをリリースするなど)を意味します。

メリットと注意点

生体認証を利用すると、高レベルのセキュリティを維持しつつ、ユーザーに利便性を提供できます。ユーザーは生体認証を利用するために第 1 の認証方式を設定する必要があるので、ロック画面の採用が促進されます(生体認証を提供しているデバイスは、そうでないデバイスに比べてロック画面の採用が平均 20% 高くなっています)。これにより、ロック画面が提供するセキュリティ機能のメリットを活用できるユーザーが増えます。具体的には、ユーザーの機密データへの認証されていないアクセスを防ぐことができ、暗号化バックアップなどの第 1 の認証方式によるその他のメリットも受けることができます。さらに、生体認証は、肩越しにのぞき見るショルダー サーフィン攻撃によって PIN やパターン、パスワードを入力するのを見た攻撃者が認証情報を再現しようとする試みを減らすうえでも役立ちます。

ただし、生体認証を使うことによるトレードオフ(発生し得るリスク)をユーザーが理解することが重要です。特に大切なのは、完璧な生体認証システムはないということです。これは Android だけでなく、すべてのオペレーティング システム、フォームファクタ、テクノロジーに対して言えることです。たとえば顔を使った生体認証の実装なら、ユーザーに似た家族やユーザーの 3D マスクでロックが解除できてしまうかもしれません。指紋を使った生体認証の実装なら、ユーザーの潜在指紋を使ってなりすませるかもしれません。このようななりすまし攻撃を緩和するため、なりすまし対策や Presentation Attack Detection(PAD)テクノロジーの開発が進められていますが、これらは緩和策であり、予防策ではありません。

生体認証の利用による潜在的なリスクを緩和するための Android の取り組みとして、Android P で導入されたロックダウン モードがあります。必要な場合、Android ユーザーはこの機能を使って一時的に生体認証や Smart Lock(信頼できる場所や信頼できるデバイスなど)、ロック画面の通知を無効化できます。

ロックダウン モードを使うには、まず第 1 の認証方式を設定し、その後に設定でロックダウン モードを有効化する必要があります。ロックダウン モードを有効化するための厳密な設定はデバイスのモデルによって異なりますが、Google Pixel 4 デバイスでは [Settings] > [Display] > [Lock screen] > [Show lockdown option] にあります。これを有効化すると、ユーザーは電源ボタンを押して電源ボタン メニューのロックダウン アイコンをクリックすることで、ロックダウン モードを起動できます。ロックダウン モードのデバイスは、第 1 の認証方式(PIN、パターン、パスワードなど)を使ってデバイスのロックを解除すると、ロックダウン解除状態に戻ります。

BiometricPrompt - 新 API
Android の生体認証が提供するセキュリティ保証のメリットを活用してもらい、生体認証をアプリに簡単に統合してユーザーの機密データの保護を強化できるようにするため、Android P で BiometricPrompt API を導入しました。

BiometricPrompt API を使用すると、さまざまなメリットが得られます。最も重要なことは、この API を使うと、アプリのデベロッパーが方式を意識せずに、さまざまな Android デバイスで生体認証を利用できることです(つまり、BiometricPrompt は、デバイスでサポートされているさまざまな生体認証方式の単一統合ポイントとして利用できます)。一方で、認証が提供する必要があるセキュリティ保証(フォールバックとしてのデバイス認証情報と合わせてクラス 3 またはクラス 2 の生体認証を必須とするなど)を制御することもできます。これにより、(ロック画面の他に)防御の第 2 階層でアプリデータを保護できることに加え、ユーザーの機密データを尊重することにもつながります。さらに、さまざまな Android デバイスのさまざまな方式の生体認証で一貫したユーザー エクスペリエンスを提供するため、BiometricPrompt は永続的な UI を提供しています。一部の情報(タイトルや説明など)をカスタマイズするオプションも存在します。

次のアーキテクチャ図に示すように、フレームワーク API やサポート ライブラリ(下位互換性を確保するための androidx.bitmetric)のどちらかを通して、Android デバイスのアプリに生体認証を組み込むことができます。注意すべき点は、FingerprintManager が非推奨になっていることです。デベロッパーには、方式を意識しない認証としてBiometricPrompt に移行することが推奨されています。

BiometricPrompt の改善点

Android 10 では、BiometricManager クラスが導入され、デベロッパーはこれを使って生体認証の利用可否を照会できます。また、BiometricPrompt 向けに指紋認証や顔認証が統合されています。

Android 11 では、BiometricManager.Authenticators インターフェースなどの新機能が導入されています。これを使うと、デベロッパーはアプリで受け入れる認証タイプを指定したり、BiometricPrompt クラスで利用ごとの認証キーをサポートしたりできます。

詳しくは、Android 11 プレビューAndroid 生体認証システムのドキュメントをご覧ください。BiometricPrompt API の詳しい使用方法については、ブログ記事 Using BiometricPrompt with CryptoObject: how and why や、Codelab Login with Biometrics on Android をご覧ください。



Reviewed by Yuichi Araki - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing, APAC

この記事は Nadine Wang による Google Ads Developer Blog の記事 "Announcing the Google Ads API is out of beta" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 


 Google Ads API が一般公開版になったことをお知らせします。これにより、以前のパフォーマンスの問題がすべて解消され、本番環境のアプリケーションで安心して Google Ads API を使えるようになります。バッチ処理を誰でも利用できるようになりました。

AdWords API のサポートも継続されます。サポートの終了予定については、あらためてお知らせします。AdWords API と完全に同じ機能を利用できるようにするため、今後のリリースでさらに機能追加を続ける予定です。

さらに詳しく知りたい方へ
まずは、以下のリソースをご覧ください。 ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。

 

この記事は Fei Xiang による Google Ads Developer Blog の記事 "Conversion Category Changes in AdWords API, Google Ads API, and Google Ads scripts" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 


 2020 年 5 月より、Google 広告アカウントにログインすると、コンバージョン アクションごとに新しいコンバージョン カテゴリにアップグレードすることを求められる場合があります。更新されたコンバージョン カテゴリを活用すると、ビジネスにとって重要な意味を持つコンバージョン アクションをさらにきめ細かく分類できます。詳細については、こちらの Google 広告ヘルプセンターの記事をご覧ください。

上記の候補の承認が完了していない場合、2020 年 10 月 15 日より自動的に適用されます。Google Ads API、AdWords API、Google 広告スクリプトのユーザーには、次の変更が適用されます。

Google Ads API をご利用の場合は、ConversionActionCategoryEnum で新しいコンバージョン カテゴリが既に利用できる状態になっています。その他に必要な対応はありません。

AdWords API をご利用の場合は、新しいバージョンの AdWords API はリリースされないため、新しいコンバージョン カテゴリタイプは既存の ConversionTracker.Category 列挙型値に変換されます。変換は、以下のマッピングに基づいて行われます。

新しいコンバージョン カテゴリ ConversionTracker.Category
カートに追加 LEAD
決済手続きの開始 LEAD
購入 PURCHASE
サブスクライブ(有償) PURCHASE
サブスクライブ(無償) SIGNUP
通話リード LEAD
オフライン リード LEAD
リードフォームの送信 LEAD
予約 LEAD
見積もり依頼 LEAD
経路検索 LEAD
離脱のクリック LEAD
連絡先 LEAD
ダウンロード DOWNLOAD
重要なページの表示 PAGE_VIEW
エンゲージメント DEFAULT
来店DEFAULT
店舗での販売PURCHASE
その他 DEFAULT


そのため、AdWords API を使って(レポートやサービス経由で)コンバージョン カテゴリタイプを取得している場合は、依然として上記のマッピングに基づいて既存のコンバージョン カテゴリタイプが返され続けます。これらは、Google 広告の UI で使われる移行された新しいタイプとは異なります。

AdWords API ユーザーは、今後も既存のカテゴリタイプを使ってコンバージョン アクションを作成できます。AdWords API は、機械学習モデルに基づいて作成されたコンバージョンを新しいカテゴリタイプに自動変換します。コンバージョン アクションにカテゴリタイプを設定するコードのサンプルは、AdWords API デベロッパー サイトに掲載されています。

Google 広告スクリプトをお使いの場合は、レポート フィールド ConversionCategoryName を選択またはフィルタする際に、上記の表のマッピングに基づいて AdWords API で使われるものと同じ既存のカテゴリタイプが表示されます。

ご質問やさらにサポートが必要なことがありましたら、フォーラムからご連絡ください。
- Google Ads API チーム、Fei Xiang 

この記事は Thanet Knack Praneenararat による Google Ads Developer Blog の記事 "Google Ads API v2 sunset reminder" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 


 Google Ads API ベータ版 v2 は、2020 年 10 月 21 日に提供を終了します。それ以降、v2 API へのすべてのリクエストは失敗します。API アクセスに影響がないように、必ず 2020 年 10 月 21 日までに新バージョンに移行してください。

移行に役立つさまざまなリソースを準備しています。

アップグレードの際に疑問に思うことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。


 

この記事は Chet Haase による Android Developers - Medium の記事 "Now in Android #26" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



Android 開発の最新ニュースやトピックをご紹介する Now in Android。今回は ターゲット API 要件、AndroidX、Android Basics コース Unit 2、Play Store と Billing の記事、ゲーム デベロッパー向けのテクスチャ マッピング、RecyclerView、パフォーマンス、認証、最近公開されたブログ記事・動画・関連ドキュメント、ポッドキャスト エピソードをご紹介します。

アプリのアップデートでターゲット API 29 以降が必須に

11 月 2 日より、すべてのアプリのアップデートは API レベル 29 以降をターゲットにする必要があります。ほとんどのアプリは既にこのアップデートを完了されていますが、まだ未対応の方は今が絶好のタイミングです。


AndroidX リリース

AndroidX では、いつものようにアルファ版ベータ版RC 版でいくつかの中間バージョンのアップデートが行われています。しかし、安定版がリリースされたライブラリもありますのでご活用ください。

  • Media 1.2.0: このリリースでは、AudioAttributesCompat のサポートの改善、Mediarouter を使う場合のボリューム コントロールのサポート、Media2 との相互運用性に関する修正が行われています。

  • Exif 1.3.0: このバージョンでは、いくつかの重要なバグ(メモリ不足状態を引き起こすものなど)の修正に加え、WebP ファイルに EXIF メタデータを書き込む機能が追加されています。

コース: Android Basics in Kotlin



Android Basics in Kotlin コースの Unit 2 が公開されました。このコースを受講すると、開発経験がなくても、無料でソフトウェア開発、Android、Kotlin のすべてを同じコースで学ぶことができます。

  • Unit 1: Kotlin Basics for Android では、クラス、オブジェクト、条件文などの基礎的内容や、Android アプリでイメージやテキストを使う方法について解説します。

  • Unit 2: Layouts では、XML レイアウト、マテリアル デザイン、ユーザーの入力の受け取り、RecyclerView の使用など、UI の考え方を紹介します。これらの機能などを搭載した 2 種類のアプリを作ります。

Google Play の最新情報と関連記事

Google Play についての最新記事が公開されました。デベロッパーの皆さんは、ぜひご確認ください。

Google Play ストアと課金システム

Google Play ストアを使って配信を行っているアプリ、ゲームのデベロッパーに向けて、Sameer Samat (Vice President、 Product Management)が Play ストアを利用する際の要件やポリシーを改めてまとめた記事を公開しました。たとえば、Play ストアや他のアプリストアでの配信、デジタル商品のアプリ内購入に Google Play の課金システム を使う際の留意点などについて説明しています。


また、Google Play の課金システムやそれに関連したポリシーについてさらに詳しくご理解いただけるよう、Mrinalini Loew がよくいただく質問とそれらに対する回答を公開しました。


さらに Google Play の課金システムの実装方法について詳しく知りたい方は、Caren Chang のシリーズ記事をお読みください。(英語)



Google Play Console
Play Console を使っている方なら、新しいバージョンのコンソールを見たことがあるはずです。新しい Play コンソールは、6 月にベータ版を公開しました。一般的なベータ版プロダクトと同じように(少なくとも理想どおりに進めば)、Play Console は今から 1 か月後の 11 月 2 日にベータ版が 終了し、安定版がリリースされます。そして古い Play Console は使えなくなり、すべてのユーザーが新しいバージョンを使うことになります。

この新しいバージョンでは、大幅に改善された UI や操作(完全に再設計されています)など、さまざまな機能が提供されます。

リリース前に新しいコンソールを確認したい方は、play.google.com/console にアクセスしてみてください。または、11 月 2 日に 新しい コンソールが唯一 の選択肢となるまで、ハラハラしながら待ってから使い始めるのもいいかもしれません。


ゲーム デベロッパーの皆さんへ

先日、Android 向けのゲームを開発しているデベロッパーのためのコンテンツを投稿しました。

テクスチャ圧縮フォーマットのターゲット指定

テクスチャ圧縮はゲームに役立つ技術です。異なるフォーマットを使い分けることで、ダウンロードやランタイムのサイズを縮小しつつ、実行時のパフォーマンスを向上させることができます。ただし、すべての端末がすべてのテクスチャ フォーマットをサポートしているわけではありません。では、デベロッパーはどうすればいいでしょうか。

Play Asset Delivery を使うと、App Bundle で複数の種類のテクスチャ フォーマットを使えるようになり、ユーザーの端末の機能に応じて適切なバージョンがダウンロードされます。Daniel Galpin によるこちらの記事では、テクスチャ圧縮の簡単な概要と、新しいゲーム配信機能のメリットを活用する方法について詳しく説明しています。動画で見たい方のために、Daniel Game Dev Show でも同じ内容を紹介しています。




GPU Inspector のテクスチャ カウンター

テクスチャとゲーム開発について、Francesco Carucci が Game Dev Show に動画を投稿しました。この動画では、新しい Android GPU Inspector ツールの機能を使って、テクスチャの利用に関連したパフォーマンスの問題の調査方法を紹介しています。

テクスチャはゲームが描画するグラフィックの主役なので、パフォーマンスの問題でも主役になる場合があります。この動画では、GPU Inspector を使う例と、帯域幅やキャッシュ、フィルタリングに関する問題について、またこれらの問題がこのツールでどのように明らかになるのかについて説明しています。



その他の最近公開されたブログ記事と動画

RecyclerView の基本

Meghan Mehta が RecyclerView についての記事を投稿しました。RecyclerView については、RecyclerView ガイドや、KotlinJava 両方のサンプル、そしてもちろん関連ドキュメントなど、既に多数の情報があります。しかし、テキストの項目やシンプルな概要などを表示する基本的な RecyclerView を作るだけなら、この記事がぴったりかもしれません。また、ベースとなるサンプルコードも確認したい方は、この記事の GitHub プロジェクトもご覧ください。

パフォーマンスに関する誤解を解消する

Calin Juravle は、Android アプリのパフォーマンスを改善する方法について、いくつかの誤解を取り上げる(そして解消する)記事を公開しました。たとえば、Kotlin と Java のアプリのサイズや起動時間の比較、フィールドと getter/setter の比較、ラムダと内部クラスの比較、オブジェクト プールの利用について解説しています。詳しくは記事をご覧ください

この記事の中で一番重要なポイントをお伝えしましょう。それは、どの最適化に時間をかけるかを決める前に、アプリのプロファイリングを行うこと、つまりデバッグ版でないものを使うことです。アプリのプロファイリングを先に行わないと、ユーザーの時間を節約するのではなく、自分の時間を無駄にすることになりかねません。

セキュリティと認証

Android セキュリティ チームは、さまざまな階層の認証について説明した記事を投稿しました。さらに、Android P、Android 10、Android 11 に導入されているバイオメトリック API についても詳しく説明しています。

またお会いしましょう

今回は以上です。次回も Android デベロッパーの世界の最新アップデートをお届けします。お楽しみに。
 


Reviewed by Yuichi Araki - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing, APAC



Google Cloud は、2020 年 11 月 6 日 (金)、13 日(金)の 2日間、流通業界(小売、卸売、消費財など)で DX を推進されている皆様に向けて「Google Cloud INSIDE Retail」をオンライン開催いたします。

4 回目を迎える今回は、『アプリケーション開発』と『データ分析、機械学習』をテーマに、小売業界をリードする方々をお招きし、これからの流通業界をみすえた、最新の導入事例をご紹介いただきます。また、先日開催された「Google Cloud NEXT’20」より、流通業界における国内外の最新事例、ソリューション、Tips などをお届けします。

開催概要

名 称 : 第 4 回 Google Cloud INSIDE Retail
日 時 :  2020 年 11 月 6 日(金)、11 月 13 日(金)いずれも 18:00 - 19:35
会 場 : オンラインにて開催
主 催 : グーグル・クラウド・ジャパン合同会社
プログラム : 
2020 年 11 月 6 日(金) 18:00 - 19:35
 『Google Cloud NEXT '20』流通業界最前線 Part 1
 グーグル・クラウド・ジャパン合同会社
 カスタマー エンジニア 諏訪 悠紀
 CPG メーカーの Asahi は Apigee でホントは何がしたいのか
 アサヒグループホールディングス株式会社 
 日本統括本部 システム統括部 マネージャー 清水 博 様
 量子コンピュータで解決する人と配送の最適化
 株式会社グルーヴノーツ
 代表取締役社長 最首 英裕 様

2020 年 11 月 13 日(金) 18:00 - 19:35
 『Google Cloud NEXT '20』流通業界最前線 Part 2
 グーグル・クラウド・ジャパン合同会社
 カスタマー エンジニア 唐澤 匠
 これからの時代の卸と小売の DX。開発不要ですぐに実現できる『情報卸』
 株式会社日本アクセス
 商品統括・マーケティング管掌付 特命担当
 兼 D&S ソリューションズ株式会社 取締役 COO 情報卸事業部長 望月 洋志 様
 流通業界の DX を実現するデータビジネス プラットフォームとは
 株式会社ブレインパッド
 ビジネス統括本部 アライアンス開発室 室長 筧 直之 様
   ※プログラムは変更になる場合があります。

詳細および参加のお申し込み
こちらからお申し込みください。
  • 競合他社様、パートナー企業様からのお申し込みはお断りさせていただくことがございます。 
  • 報道関係者のご参加はお断りさせていただきます。 
  • ビジネス向けのイベントとなっております。学生の方のご参加はご遠慮ください。 
  • ご視聴いただける方には、後日、ご登録されたメールアドレスに参加のご案内をお送りします。



Android 11 と関連技術、最新の Google Play に関する情報をお伝えするオンライン セミナーシリーズ Android 11 Meetups の日本開催 全 8 回が終了しました。共催にご協力いただいたGDG (Google Developer Groups)コミュニティの皆さまに心からの感謝をお伝えするとともに、セミナーへご参加くださった数多くのアプリ開発企業のエンジニアやプロダクト担当の皆さまにお礼を申し上げます。

日本では 6 月 23 日から 9 月 29 にかけて、Google が提供するテクノロジーの最新情報を Google 関係者や外部のエキスパートが日本語、または英語の場合は通訳を交えて共有しました。また、リアルタイムでお寄せいただいた質問に回答する時間を設け、直接ご意見やご質問を伺うことができました。この記事では、各回の動画アーカイブに加え、 11 Weeks of Android のブログ記事や関連ドキュメントを使いながらセミナーを振り返り、Android 11 と関連する技術情報についてまとめます。各セッションテキストに、直接開始時刻から動画を再生できるリンクを貼っていますのでご活用ください。




第 1 回: Android 11 の概要



開催時にベータリリースをしていた Android 11 の概要について、 3 つのセッションを通じてお話ししました。従来の Android OS とは異なる点や、Android 11 に対応したアプリを開発するためのツールについて、また、扱いが大きく変わったプライバシー管理機能に関わる情報を、特にアプリ開発デベロッパー向けに取り上げました。また、質疑応答の時間に寄せられたご質問とその回答からいくつかご紹介します。その他の内容についてはぜひ動画をご覧ください

Q. アプリに対するロケーションポリシーが適用されるタイミングは?

A. Google Developers Japan Blog (日本語)または Android Developers Blog (英語)や Play Console ヘルプのポリシーセンターで最新情報を随時お知らせします。

Q. One Tap で指紋認証は使えるのか?
新しい Google Identity Services Library の一部。ウェブと Android でクロスプラットフォームにログインするための新しい仕組みで、複数の種類の認証情報を効率よく管理します。

A. 現在は対応していません。

Q. Geofence は Android 11で使用できるのか?

A. バックグラウンド位置情報の利用権限を取得する必要がある。「1回だけ」のアクセス許可は、フォアグラウンド位置情報に対しての権限なので注意。

第 2 回: 機械学習




近年さらに活用の場が増えている機械学習について取り上げました。特にモバイル端末で動作するオンデバイス機械学習の Android での活用方法として、ML Kit の on-device API を解説しました。 質疑応答の時間に寄せられたご質問とその回答からいくつかご紹介します。その他の内容については動画をご覧ください

Q. モバイル端末上でモデルを作ることは可能か?

A. 可能だが、学習できる範囲は狭いのでサーバーで実行したほうが効率的。

Q. ML Kit のテキスト認識と Cloud Vision API との違いは何か?

A. MK Kit は On-device 用なので latin 文字しか認識しない。サーバーベースでなおかつ有償だが、Cloud Vision APIのほうが高性能である。

Q. 簡単に画像認識モデルを作るためのライブラリがあったら教えてほしい。

A. TensorFlow Model Maker が希望の内容に沿っているかと思う。モデルを作るには画像を大量に集めなければならない。例えば動画を撮影し、1 コマごとに切り出して学習させると効率が良いと思う。1 クラスに 100 枚ほど画像があれば十分なので、1 分尺ほどの動画を撮影すれば良い。それより少ない画像でモデルを作るのは難しいだろう。

第 3 回: Kotlin




Kotlin は表現力の高さ、高品質なアプリの記述に役立つこと、既存の Java コードベースを簡単に利用できることなどから高い評価を受けています。この回では Android のアプリの開発に密接に関係している Kotlin について最新情報を重点的に解説しました。質疑応答の際に寄せられたご質問とその回答をいくつかご紹介します。その他の内容については動画をご覧ください

Q. LiveData から Flowへの乗り換えは行うべきか?

A. StateFlow は Kotlin でしか使えないので、LiveData 自体が完全になくなるということはないと思う。

Q. 古くからあるアプリを Java から Kotlin に置き換えたい。どのような手順を踏むのが良いか。

A. まずは Javaにアノテーションをつけて整理し、Kotlin へ置き換えるのはどうだろうか。

Q. JVM 言語の使用経験がない人が Kotlin を習得する場合、先に Java を学んだほうが良いと思うか?

A. 同時に 2 言語を習得するのは大変むずかしいので、最初から Kotlin に絞って学習したほうが良いと思う。
※Kotlin の Codelab はこちら(英語)Kotlin Bootcamp Course, Android Kotlin Fundamentals Course

第 4 回: 開発ツール




Android の公式 IDE である Android Studio 4.0 のノウハウや、新しいデバッガーの利用、 ライブラリ スイートの Android Jetpack の最新情報に焦点を当てて解説しました。 Android Studio は、2020 年 8 月 13 日段階で、安定リリース チャンネルでは Android Studio バージョン 4.0 が、ベータ版チャンネルではバージョン 4.1 が、Canary チャンネルでは最新機能を搭載したバージョン 4.2 が公開されています。質疑応答で寄せられたご質問とその回答のいくつかをご紹介します。その他の内容については動画をご覧ください

Q. CPU Profiler の Sample Java Method は Kotlinでも使用可能か。

A. Java系のメソッドならば使用可能。

Q. サポートライブラリ版の AppCompat + Hilt は使えるか。

A. AppCompat を Android X 版 に変更することで使用可能だと思われる。

第 5 回: アプリ配信と収益化




Google Play Console へようこそ(日本語字幕あり)



アプリの配信、管理、分析機能を大幅に強化し、ポリシーの最新情報を素早く確認できる受信トレイなど多くの新機能も追加された新しい Google Play Console と、Google Play Commerce の詳細を最新情報を交えてご紹介しました。なお、Google Play Console は 2020 年 6 月に新しいベータ版を発表し、移行期間を経て 2020 年 11 月 2 日より従来の Play Console はアクセスできなくなります。

第 6 回: マルチデバイス




Android OS はスマートフォンだけにとどまらず、Android TV や車載 Android などがあり、Wear OS、Chrome OS とも密接に関わっています。デバイスの壁を超えたアプリをどのように開発するのか、また海外の事例なども交え、特に Chrome OS と Android TV 向けアプリの開発に関する最新情報をご紹介しました。以下に、質疑応答でお寄せいただいた内容を少しご紹介します。詳しくは動画をご覧ください


Q. Chrome OS と Android デバイスで処理を分割したいのだが。

A. Google Playストアでターゲットを絞り、マルチ APK とすることで分割できる。ただし、できれば同じ APK でサポートしてほしい。

Q. Chrome OS の Android バージョンはどの程度の時期にアップデートされる予定なのか。

A. 今現在は詳しいことは言えないが、 2021 年に R (Android 11) となるかもしれない。

第 7 回: ゲーム開発




今年 3 月下旬に Google for Games Developer Summit で発表された Android 向けゲームの開発ツールとその最新情報を中心にご紹介しました。この回では、Android スマートフォンだけにとどまらず、 Chrome OS でのゲーム開発や、Google Play ストアの最新情報・セキュリティ対策と、Play ストアのゲームセクションで「どのような」ゲームであるか伝えるのが効果的なのかといった、ゲーム開発だけに限らないセッションもあり、より幅の広いゲーム開発に関わる内容でお届けしました。

第 8 回: UI、デザイン




日本時間 2020 年 8 月 27 日にアルファ版を公開した Jetpack Compose は、Android でデベロッパーが頻繁に直面する難しい問題を解決するために開発され、プラットフォームのあらゆるバージョンでアプリを確実に動作させ、高い品質を確保できるライブラリです。この Jetpack Compose を利用した、次世代UIのアプリケーション開発について、そして Android 11 で追加されたシステム UI について3 つすべてのセッションを使い、紹介しました。



Posted by Hidenori Fujii - Google Play Developer Marketing, APAC
Reviewed by Yuichi Araki - Developer Relations Team