Core Web Vitals

Web アプリ

開発ツール/デバッグ

Trust & Safety

この記事は Frank van Diggelen による Android Developers Blog の記事 "Improving urban GPS accuracy for your app" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Android では、デベロッパーの皆さんがユーザーにとって、便利なアプリをできる限り簡単に作成できるようにしたいと考えています。そのため、Fused Location Provider API（FLP）などの API では、位置情報を最大限に活用できるようにすることを目指しています。しかし、密集した都市部では、通りの反対側や誤った区画を指すなど、その位置情報の精度が低いというご指摘をこれまで多くの方からいただいておりました。

ライドシェアやナビゲーションなど、特によく利用されている位置情報アプリでは、この点が非常に重要になります。たとえば、街でユーザーがライドシェアをリクエストしても、GPS エラーのためアプリが簡単に位置を特定できない場合があります。

解決されていない最後の大きな GPS 問題

誤って通りの反対側を指してしまうエラーが起こる主な原因は、都市では GPS シグナルが反射しやすいためです。この大きな GPS 問題の解決に役立てるため、私たちは新しいプロジェクトを立ち上げました。そのソリューションは、3D マッピングを活用して補正を行うという方法です。これには、建物の 3D モデル、未加工の GPS 測定データ、機械学習を組み合わせる必要があるため、Google のような企業の規模でしか実現できません。

12 月の Pixel Feature Drop では、Pixel 5 と Pixel 4a5G に 3D マッピングを活用した GPS 補正が追加されます。Pixel で使われている Qualcomm® Snapdragon™ 5G Mobile Platform にフィードバックを提供するシステム API により、都市部（ビルの谷間、いわゆる「アーバン キャニオン」）での精度が大幅に向上します。

Pixel 5 スマートフォンを用いた歩行テストの写真。まず通りの片側を歩き、その後反対側に移動する。黄色 = 移動経路、赤 = 3D マッピングを活用した補正を行わない場合、青 = 3D マッピングを活用した補正を行った場合。

この写真から、3D マッピングを活用した補正を行わない場合、GPS の結果が不安定になって通りの反対側（または誤った区画）を指す頻度が高くなることがわかります。一方、3D マッピングを活用した補正を行うと、位置は何倍も正確になります。

これまで問題が解決できなかった理由

都市部では GPS が構造的に誤った場所を指す点が今までの問題でした。その問題は、すべての GPS システムが衛星からの見通し線に基づいて位置を特定しているために引き起こされています。しかし大都市では、直接の信号は建物によって妨害されるため、ほぼすべての信号が障害物に反射した後に届くことになります。

GPS チップは信号が見通し線上にあることを仮定しているので、信号が余分な経路を通過してきた分だけ、計算に誤差が生じます。最も一般的な副作用は、位置が通りの反対側に表示されることですが、特に多くの高層ビルが建っている大都市では、誤った区画に表示されることもあります。

この問題は、10 年以上にわたって解決が試みられてきました。しかし、Android に 3D マッピングを活用した補正が搭載されるまでは、大規模な解決策は存在しませんでした。 

3D マッピングを活用した補正の仕組み

Google Play サービスの 3D マッピングを活用した補正モジュールには、Google が保持している世界中の 3,850 以上の都市の 3D 建造物モデルのタイルが含まれています。現在、Google Play サービスの 3D マッピングを活用した補正は、歩行者による利用のみをサポートしています。歩きながらデバイスの GPS を使うと、Android の Activity Recognition API が今歩行していることを認識します。さらに、3,850 以上の都市のいずれかにいる場合、その都市の 3D モデルのタイルがダウンロードされ、スマートフォンにキャッシュされます。キャッシュのサイズは約 20 MB で、写真 6 枚程度の大きさです。

このモジュールでは、3D マッピングを活用した補正アルゴリズムが難問を解決します。つまり、GPS の位置が正しくない場合、どうすれば信号を妨害したり反射したりしている建物を知ることができるかという、卵が先か鶏が先かわからないような問題です。この問題は、3D マッピングを活用した補正によって解決され、FLP には一連の補正済みの位置が渡されます。システム API はこの情報を GPS チップに渡し、チップがそれ以降の GPS 精度を改善できるようにします。

12 月の Pixel Feature Drop では、Pixel 5 と Pixel 4a(5G) を対象に、3D マッピングを活用した補正のバージョン 2 をリリースします。これにより、通りの反対側を指すという現象の発生率が約 75% 減少します。Android 8 以降を使っているその他の Android スマートフォンでは、FLP にバージョン 1 が実装されており、通りの反対側を指すという現象の発生率が約 50% 減少します。2021 年初頭には、Android エコシステム全体（Android 8 以降）でバージョン 2 を利用できるようになる予定です。

Android の 3D マッピングを活用した補正は、米国の Global Positioning System（GPS）に加え、その他の Global Navigation Satellite System（GNSS）の信号にも対応しています。具体的には、GLONASS、Galileo、BeiDou、QZSS の信号です。

GPS チップ パートナーは、それぞれのテクノロジーにおけるこの作業の重要性について、次のように述べています。

「ユーザーは、モバイル スマートフォンの位置情報やナビゲーション機能の精度に依存しています。位置情報テクノロジーは、お気に入りのレストランを見つけたり、タイミングよくライドシェア サービスを利用したりする際に非常に重要ですQualcomm Technologies は、Google の 3D マッピングを活用した補正を組み込んだ最新のQualcomm® Location Suite テクノロジーによるユーザー エクスペリエンスの改善で、主導的な役割を果たしています。今回の Google との共同作業は、歩道レベルの精度の位置情報実現に向けた重要なマイルストーンです」

―― Qualcomm Technologies, Inc. プロダクト管理担当副社長、Francesco Grilli 氏

「Broadcom は、BCM47765 二周波 GNSS チップのナビゲーション エンジンに Google の 3D マッピングを活用した補正を組み込みました。二周波の L1 および L5 信号と 3D マッピングを活用した補正を組み合わせることで、アーバン キャニオンでこれまでにない精度を実現できます。L5 と Google の補正を組み合わせれば、都市部での GNSS の活用に革命を起こすことができます」

――Broadcom Inc. エンジニアリング担当シニア ディレクター、Charles Abraham 氏

「Google の 3D マッピングを活用した補正によって、スマートフォン ユーザーが都市環境で歩行しているときの個人の位置情報の精度が大きく進展しました。MediaTek Dimensity 5G ファミリーは、3D マッピングを活用した補正に対応しています。これにより、高精度デュアルバンド GNSS や業界トップレベルのデッドレコニング パフォーマンスに加えて、最高精度のグローバル位置情報を 5G スマートフォン ユーザーに提供できます」

―― MediaTek

3D マッピングを活用した補正を利用する方法

Android 8 以降を実行しているスマートフォンでは、3,850 以上の都市で GPS をオンにして歩行しているときに、Android の 3D マッピングを活用した補正が自動的に作動します。デベロッパーがこの改善を活用する最適な方法は、FLP を使って位置情報を取得することです。GPS チップによるさらに高度な 3D マッピングを活用した補正は、現在のところ、Pixel 5 と Pixel 4a 5G で利用できます。また、今後数週間のうちに、Android エコシステム全体（Android 8 以降）に対してロールアウトされる予定です。今後、運転中などの他のモードもサポートする予定です。

Android の 3D マッピングを活用した補正は、以下を含む 3,850 以上の都市で利用できます。 

• アジア: 日本と台湾のすべての主要都市
  
  
• 北米: 米国、カナダ、メキシコのすべての主要都市
  
  
• ヨーロッパ: すべての主要都市（ロシアとウクライナを除き 100%）
  
  
• その他: ブラジル、アルゼンチン、オーストラリア、ニュージーランド、南アフリカのすべての主要都市

Google Earth 3D モデルの拡張とともに、3D マッピングを活用した補正の範囲も広がります。

Google マップにもアップデートが行われます。これにより、一部の都市で、歩道、横断歩道、安全地帯などの歩行者向けの街区レベルの情報の精度が向上します。2021 年には、Google Maps Platform を使っているアプリにもこのアップデートが提供されます。3D マッピングを活用した補正による位置情報の精度向上と合わせて、皆さんのようなデベロッパーが、世界中で Android を使っている 20 億人の歩行者のユースケースのサポートを向上させてくださることを期待しています。

位置情報の継続的な改善

私たちは 3D マッピングを活用した補正の他にも、位置情報の精度と利便性を向上させる努力を懸命に続けています。Fused Location Provider API（FLP）の最新の改善項目は、以下のとおりです。

• デベロッパーは、現在の位置情報を取得する簡単な方法を求めていました。新しい getCurrentLocation() API を使えば、1 回のリクエストで現在の位置情報を取得できます。位置情報の変化を継続的に取りにいくする必要はありません。この新しい API は、必要なときだけ位置情報をリクエストできるようにすることで（また、自動的にタイムアウトしてオープンな位置情報リクエストをクローズすることで）、電池の寿命も改善します。最新の Kotlin サンプルもご覧ください。
  
  
• Android 11 の Data Access Auditing API は、アプリやその依存関係からのユーザーのプライベートなデータ（位置情報など）へのアクセスについて、透明性を高めます。この API では、FusedLocationProviderClient で属性タグが新しくサポートされているので、デベロッパーは今まで以上に簡単に、アプリの位置情報サブスクリプションや定期的な位置情報リクエストを監査できるようになります。詳しくは、こちらの Kotlin サンプルをご覧ください。

Qualcomm および Snapdragon は、Qualcomm Incorporated の商標または登録商標です。Qualcomm Snapdragon および Qualcomm Location Suite は、Qualcomm Technologies, Inc. および/またはその子会社の製品です。

2020 年は、予想もつかない事態が続く中で、困難な状況をポジティブに変える取り組みに多くのデベロッパーの皆さまが精力を傾けてこられました。世界保健機関（WHO）と世界中のゲーム関連事業者が提唱した #PlayApartTogether （離れていっしょに遊ぼう）キャンペーンを日本でも立ち上げ推進した、株式会社ミラティブと株式会社ミクシィの取り組みもその 1 つです。

Google Play では Play ストアに特集ページを設け、賛同デベロッパーのゲームを掲載しました。詳細をまとめた動画をご覧ください。

Posted by Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems

この記事は Vesna Doknic による Google Play Developers - Medium の記事 "Churn: acting before it’s too late" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

アプリユーザーの離脱を防ぐには

手遅れになる前に対処する

アプリのユーザーは、3 つの基本的なグループに分けることができます。それは、エンゲージメントがない（獲得戦略によって新たに引き寄せられたグループ）、エンゲージメントが増加中（利用維持戦略によって利用が促進されたグループ）、エンゲージメントが減少中（離脱阻止戦略によってつなぎ留められているグループ）の 3 つです。これらはすべて異なる戦略が関わっているので、獲得、維持、離脱阻止をまったく別の領域として考えることは理にかなっています。しかし、離脱との闘いは軽視されることが多く、獲得の増加や、エンゲージメントの高いユーザーの維持率を上げることで、相殺できたりするものと見なされがちです。

前回の記事（英語）では、どうすればデベロッパーが効果的な維持戦略を策定できるかについて説明しました。これは、エンゲージメントの高いユーザーを維持する可能性を高めることを狙った戦略です（さらに細かく掘り下げたレポート全文をご覧ください）。しかし、戦略やアプリがどれほど素晴らしいものであっても、いくらかのユーザーは離脱してしまうものです。

ユーザーの離脱は、目先の収益以上の損失を会社にもたらします。例えば、早い段階でユーザーが離脱すれば、そのユーザーの獲得コストは完全に無駄であったということになります。また、離脱したユーザーを再定着させることは可能ですが、それには新しいユーザーを獲得するよりも費用も時間もかかる可能性が高いです。

ユーザーを再定着させるには、そもそもユーザーの離脱を引き起こした問題を直接的に克服しなければなりません。そのコストを考えると、ユーザーを再定着させるよりも、最初からユーザーが離脱しないようにあらかじめ手を打っておくほうがはるかに効果的です。

それでは、どうすれば手遅れになる前に行動できるのでしょうか。

明確な離脱予測を確立する

離脱を防ぐということは、離脱が起こる前に対処するということです。すなわち、警告システムを作り、離脱の兆候を特定して早い段階で行動するのです。ユーザーは一夜にして離れるわけではありません。離脱する前には、アプリの使い方が変わり始めます。そしてそれは、計測して特定することが可能です。この危険信号を特定するには、以下の様なデータを確認し、離脱するユーザーがどのような行動をとっているのかを調べます。

• 離脱ポイント: 通常、ユーザーが離脱する前に、どのくらいの期間休眠状態になるかを調べます。離脱したユーザーと過去の利用状況のデータを調査し、アプリに関係するパターンを特定します。
  
  
• 利用パターンの変化: 離脱前には、利用の頻度や時間が減少し始めるのが一般的です。離脱を示すその他の一般的なパターンとして、表面的な使用になる、セッション時間が短くなる、主要機能を使わなくなる、「キャンセル方法」のページを見るなどがあります。
  
  
• 使用率: 利用の低下率を調べることも重要です。使用時間が突然減った場合は、迅速な対応が必要です。一方、徐々に低下した場合は、もう少し時間をかけて対策を取ることができます。

Quickbooks は、詳細なモデリングによって最近離脱したユーザーの行動を分析し、高い離脱率と相関性のある行動に注目した「ユーザー リスク プロフィール」を作っています。

これは 200～300 種類のアプリ内行動をまとめたもので、機能を使用しない、休眠の日数、重要指標を達成できない、などが含まれています。詳しい方法について知りたい方は、こちらの記事（英語）をご覧ください。 

Quickbooks は、このような「点検」を行うことで、即座に介入して独自の方法で望ましい行動を促し、離脱のリスクを軽減できるようにしています。 

アプリの価値を高める

離脱を予測できるようになったら、離脱する可能性が高いユーザーを特定してアプリに呼び戻すことを試みます。そのためには、ユーザーにアプリの価値を再認識してもらわなければなりません。既に使っている機能についてのリマインダーを表示したり、近くリリースされる機能に期待してもらったりすることも効果的です。

これを行う方法の 1 つは、ユーザーがアプリを使って既に実現したことを思い出してもらうことです。Yazio は、ユーザーの進捗を目に見える形で継続的に追跡し、離脱を防ぐ方策として、頻繁にお祝いの言葉を贈っています。進行状況バーと祝福の画面を使ってユーザーのモチベーションを上げ、目標の達成を促します。

可能な限りコンテンツをパーソナライズし、ユーザーに自分が大事にされていると感じてもらえるようにするのも効果的です。Mobills は、使用率が低下したユーザーに対し、そのユーザーに合わせたメッセージを送り、ギフトを提供したり応援するようにしています。

Lifesum も、ユーザーに合わせたメッセージを送っています。ただし、ユーザーが見落としている可能性があるものを強調します。つまり、重要な機能のリマインダーを重視し、ユーザーの使用率を維持できるように、あまり知られていない機能についてお知らせしています。

定期購入の期限切れに注目する

アプリで定期購入を導入している場合、その更新期間には常にリスクがつきまといます。ここで最も重要なことは、適切なタイミングで適切な兆候に基づいて行動することです。そのためには、定期購入期間が終了する数週間前または数か月前、まさに離脱を示す行動が起きているときに、その行動を特定する必要があります。兆候は思ったよりも早く見つかるかもしれません。

続いて、キャンセル以外の選択肢を確実に示して、そのことをユーザーにはっきりと伝えます。ユーザーは、より手頃な価格、または広告をベースにしたオプションが存在することを知らないかもしれません。ユーザーにキャンセルの理由を与えないようにしましょう。

オファーを行うときは、価値の見せ方を工夫してみましょう。定期購入の更新をユーザーに促すのは、難しいものです。どんなメッセージがユーザーの共感を得るかを判断するために、異なるメッセージを試してみてもよいかもしれません。コストやメリット、オプションを明確に提示すれば、ユーザーは選択肢を与えられたように感じて選びやすくなる可能性があります。また、実世界の同等なものとコストを比べれば、視野を広げて価値を見直してもらえるかもしれません。Yazio は、定期購入の月間コストが 1 日 1 杯のコーヒーや他のダイエット製品よりも安いことをアピールしています。

また、常に言えることですが、パーソナライズしたメッセージを送れば、ユーザーは自分が大事にされていると感じます。Quickbooks は、定期購入のキャンセル フローの途中で、ユーザーがアプリで実現したこと（1,000 マイルを移動したなど）や、費用を払ったにもかかわらずまだ使っていなかった機能を提示しています。 

まとめ

上記のステップを通して、注目すべきユーザー グループとそれらのグループの障壁を表す、離脱につながるさまざまな行動パターンを発見できるかもしれません。もちろん、一部のグループでは、離脱は避けられない可能性もあります。アプリが提供するサービスの価値を誤解したユーザーや、単にそのアプリでは事足りなくなったユーザーがそういったグループに当てはまるでしょう。そういったケースもあるので、再定着に向けたさまざまな努力をしているにもかかわらず活動のレベルが低いままであるユーザー グループではなく、価値をもたらしてくれるグループに注目するようにしましょう。完全に離脱をなくすことは不可能であることを忘れないでください。

この記事が、離脱を最低限に抑える戦略の立案にお役に立つことを願っています。ここでご紹介した戦略は、「どっちつかず」のユーザーを定着させるために役立ち、獲得戦略や維持戦略とともに、アプリを継続的に成長させるために欠かせないものです。  この内容についてもっと知りたい方は、以下の関連情報をご覧ください。

• アプリユーザーの維持に関する最新記事
• アプリユーザーの維持や離脱のトピックに関して、さらに多くのケーススタディを取り上げたレポート全文はこちら

スキームフル Same-Site は、「サイト」の定義を、「登録可能ドメイン」のみから、「スキーム＋登録可能ドメイン」に変えるものです。詳細や例は、「同一サイト」と「同一オリジン」を理解するをご覧ください。

うれしいのは、すべてのウェブサイトを既に HTTPS にアップグレードしている場合、何も心配することはない点です。その場合、何も変わることはありません。

まだウェブサイトを完全に HTTPS にアップグレードしていない場合は、この作業の優先度を上げる必要があります。ただし、サイトにアクセスするユーザーが HTTP と HTTPS を行き来している場合は、一般的なシナリオとその SameSite Cookie の動作について、以下をお読みください。

以下の変更を有効化すると、Chrome と Firefox でテストできます。

• Chrome 86 以降で、chrome://flags/#schemeful-same-site を有効にします。進捗状況は、Chrome ステータス ページでトラッキングしてください。
• Firefox 79 以降で、about:config から network.cookie.sameSite.schemeful を true に設定します。進捗状況は、Bugzilla の問題でトラッキングしてください。

Cookie のデフォルトを SameSite=Lax に変更した主な理由の 1 つに、クロスサイト リクエスト フォージェリ（CSRF）に対する保護がありました。しかし、安全でない HTTP トラフィックが存在する場合、ネットワーク攻撃者が Cookie を改ざんし、それを使って安全な HTTPS バージョンのサイトに侵入するチャンスが残ることになります。スキーム間にクロスサイト境界を追加することで、このような攻撃に対する保護を強化できます。

一般的なクロススキーム シナリオ #

ナビゲーション #

これまで、クロススキームなウェブサイト間のナビゲーション（たとえば、http://site.example から https://site.example へのリンク）では、SameSite=Strict Cookie の送信が許可されていました。今後、これはクロスサイト ナビゲーションとして扱われます。つまり、SameSite=Strict Cookie はブロックされます。

サブリソースの読み込み #

ここで行う変更は、完全な HTTPS へのアップグレードを進める間の一時的な修正としてのみ検討してください。

サブリソースの例として、イメージ、iframe、XHR や Fetch によるネットワーク リクエストなどがあげられます。

これまで、ページでクロススキーム サブリソースを読み込んだ場合、SameSite=Strict または SameSite=Lax の Cookie の送信や設定が許可されていました。今後、これは他のサードパーティまたはクロスサイトのサブリソースと同じように扱われます。つまり、SameSite=Strict や SameSite=Lax の Cookie はすべてブロックされます。

加えて、ブラウザが安全なページで安全でないスキームからのリソースの読み込みを許可したとしても、サードパーティまたはクロスサイト Cookie には Secure が必須なので、リクエストの Cookie はすべてブロックされます。

フォームの POST #

これまでは、クロススキーム バージョンのウェブサイト間で POST を行った場合、SameSite=Lax または SameSite=Strict が設定された Cookie の送信は許可されていました。今後、これはクロスサイト POST として扱われ、SameSite=None Cookie のみ送信できるようになります。このシナリオは、デフォルトで安全でないバージョンを表示し、ログインまたはチェックアウト用のフォームを送信する際にユーザーを安全なバージョンにアップグレードするサイトで使われている可能性があります。

サブリソースと同じく、リクエストが安全な HTTPS などのコンテキストから安全でない HTTP などのコンテキストに向かう場合、サードパーティまたはクロスサイトの Cookie には Secure が必要になるので、リクエストの Cookie はすべてブロックされます。

サイトをテストする方法 #

Chrome と Firefox では、デベロッパー ツールやメッセージを利用できます。

Chrome 86 以降では、DevTools の [Issue] タブにスキームフル Same-Site の問題が表示されます。サイトで以下の問題が表示される可能性があります。

ナビゲーションに関する問題:

• "Migrate entirely to HTTPS to continue having cookies sent on same-site requests"—将来のバージョンの Chrome で Cookie がブロックされる予定であることを示す警告。
• "Migrate entirely to HTTPS to have cookies sent on same-site requests"—Cookie がブロックされたことを示す警告。

サブリソースの読み込みに関する問題:

• "Migrate entirely to HTTPS to continue having cookies sent to same-site subresources" または "Migrate entirely to HTTPS to continue allowing cookies to be set by same-site subresources"—将来のバージョンの Chrome で Cookie がブロックされる予定であることを示す警告。
• "Migrate entirely to HTTPS to have cookies sent to same-site subresources" または "Migrate entirely to HTTPS to allow cookies to be set by same-site subresources"—Cookie がブロックされたことを示す警告。後者の警告は、フォームを POST した場合にも表示される可能性があります。

詳しい内容は、スキームフル Same-Site のテストとデバッグに関するヒントにも掲載されています。

Firefox 79 以降で about:config から network.cookie.sameSite.schemeful を true に設定すると、スキームフル Same-Site の問題に関するメッセージがコンソールに表示されます。サイトで以下の内容が表示される可能性があります。

• "Cookie cookie_name will be soon treated as cross-site cookie against http://site.example/ because the scheme does not match."
• "Cookie cookie_name has been treated as cross-site against http://site.example/ because the scheme does not match."

FAQ #

私のサイトは完全に HTTPS が利用できるようになっていますが、ブラウザの DevTools に問題が表示されるのはなぜですか？ #

一部のリンクやサブリソースが安全でない URL を指している可能性があります。

この問題を修正する方法の 1 つは、HTTP Strict-Transport-Security（HSTS）と includeSubDomain ディレクティブを使うことです。HSTS と includeSubDomain を使うと、ページに安全でないリンクが意図せずに含まれる場合でも、ブラウザが自動的に安全なバージョンを使ってくれます。

HTTPS にアップグレードできない場合はどうすればよいでしょうか？ #

サイトを完全に HTTPS にアップグレードしてユーザーを保護することを強くおすすめしますが、ご自身でアップグレードできない場合は、ホスティング プロバイダに相談してアップグレードのオプションを提供できるかを確認してください。セルフホストの場合は、Let's Encrypt が証明書をインストールして設定するためのさまざまなツールを提供しています。また、HTTPS 接続を提供できる CDN やその他のプロキシを経由してサイトにアクセスするように移行することも検討できます。

それでも難しい場合は、影響を受ける Cookie の SameSite 保護の緩和を試します。

• SameSite=Strict Cookie のみがブロックされる場合は、保護を Lax に下げます。
• Strict と Lax の両方の Cookie がブロックされ、Cookie が安全な URL に送信される（または安全な URL で設定される）場合は、保護を None に下げます。
  • この回避策は、Cookie の送信先 URL（または設定元 URL）が安全でない場合、失敗します。これは、SameSite=None の Cookie には Secure 属性が必要だからです。つまり、このような Cookie を安全でない接続で送信、設定することは許可されていません。この場合、サイトを HTTPS にアップグレードしなければ Cookie にアクセスすることはできません。
  • サードパーティ Cookie は将来的に廃止される予定なので、これは一時的な対策に過ぎないことを忘れないでください。

SameSite 属性を指定していない場合、Cookie にどのような影響が発生しますか？ #

SameSite 属性のない Cookie は、SameSite=Lax を指定した場合と同じように扱われ、それと同じクロススキーム動作が適用されます。なお、安全でない手法も一時的に例外として許可されています。詳しくは、SameSite FAQ の Chromium における Lax＋POST 対処法をご覧ください。

WebSocket はどのような影響を受けますか？ #

ページと同じ安全性が確保されている場合、WebSocket 接続は今後も同一サイトと見なされます。

同一サイト:

• https:// からの wss:// 接続
• http:// からの ws:// 接続

クロスサイト:

• http:// からの wss:// 接続
• https:// からの ws:// 接続

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

Android 開発の最新ニュースやトピックをご紹介する Now in Android。今回は App Bundle、マテリアル デザイン コンポーネント、新しいターゲット API 要件、新しい Fragment とフローのドキュメント、最近公開されたブログ記事・動画・関連ドキュメント、ポッドキャスト エピソードなどをご紹介します。

MAD Skills: App Bundle とマテリアル デザイン コンポーネント

最先端の Android 開発に関する新しい技術コンテンツを扱う連載 MAD Skills シリーズが続いています。

App Bundle のミニシリーズは、Google Developer Expert の Angelica Oliveira からのヒント、続いて私（質問役）と Ben Weiss、Wojtek Kaliciński、 Iurii Makhno（回答役）によるリアルタイム Q&A とアーカイブで終了しました。App Bundle の全エピソード（動画と記事）は、まとめのブログ記事（英語）からリンクしています。

続いて MAD Skills は、マテリアル デザイン コンポーネント（MDC）についての新しいミニシリーズに入りました。マテリアル デザイン コンポーネントは、マテリアル デザイン ガイドラインを使ってアプリの構築を簡単にするライブラリです。

初回は Nick Butcher が、Android デベロッパーにマテリアル デザイン コンポーネントの使用を推奨する理由を説明しています。この動画には、テーマのサポート、組み込みの画面遷移、デフォルトのマテリアル スタイルのコンポーネントなど、MDC が提供するさまざまな機能の概要が含まれています。このコンテンツは、以前にブログ記事（英語）も掲載しています。

次に、Nick Rout がマテリアル テーマについてのエピソードを投稿しました。MaterialThemeBuilder サンプル プロジェクトについて説明しつつ、マテリアル テーマの使い方とカスタマイズの方法を紹介しています。

この動画に加えて、色、書体、形状について取り上げた記事（英語）もそれぞれご覧ください。

12 月第一週にかけて、Chris Banes が 3 つ目のエピソードを投稿しました。Android 10 の Force Dark 機能と MDC の DayNight テーマの両方を使い、MDC でダークテーマを作成する方法について説明しています。また、Chris はこのコンテンツをブログ記事形式（英語）でも公開しました。

引き続き、ほかにも MDC 関連のコンテンツを公開する予定です。さらに、日本時間 12 月 11 日午前 3 時から、もう一度リアルタイム Q&A （英語）を行います。詳細は MDC プレイリストをご覧ください。

連載中の MAD コンテンツは、YouTube の MAD Skills プレイリスト、Medium のブログ記事（英語）、またはすべてのリンクが掲載されているランディング ページからご覧ください。

App Bundle とターゲット API 要件

2021 年後半には、ターゲット API（新規アプリとアプリのアップデート）と App Bundle の両方の要件が追加されます。Hoi Lam が、これについて詳しく説明したブログ記事（日本語）を投稿しました。簡潔にまとめると、次のようになります。

2021 年 8 月:

• 新規アプリで API レベル 30 の指定が必須になります。
  
  
• 新規アプリを Play Store に公開する場合、App Bundle の使用が必須になります。
  
  
• 150 MB を超えるアセットや機能がある新規アプリは、Play Asset Delivery や Play Feature Delivery を使った配信が必須になります。新しいアプリでは、拡張ファイル（OBB）はサポートされません。

2021 年 11 月:

• アプリのアップデートで API レベル 30 の指定が必須になります。

最近公開された関連ドキュメント

Fragment のドキュメント

Fragment は、UI デベロッパーに重要なアーキテクチャ要素を提供し、アプリの UI の小さな塊を自己完結的な形で管理できるようにします。Fragment と Navigation を組み合わせている方も、単独で Fragment を使っている方も、アプリで最も効果的に Fragment を使う方法を確認することをおすすめします。ツールや API の使い方を理解するために、最新の綿密なドキュメントを公開することが重要であると考えています。サポートが終了した API の利用は避けるべきですが、関連ドキュメントでは、正しい方向性を示したり、ベスト プラクティスを説明しています。

そこで、Fragment のドキュメントを大きく改訂し、ライフサイクル、状態、テストなど、Fragment のさまざまな側面について説明している最新のガイドを公開しました。こちらから、最新のドキュメントをご確認ください。

AndroidX で Fragment の修正や拡張を行っている Ian Lake が、Twitter のフィードで今回のドキュメントの変更に触れています。

Kotlin フロー

Kotlin のフローについての新しいドキュメントも公開しました。ここには、フローの基本的な使用方法から、新しい StateFlow および SharedFlow API のテスト方法まで、あらゆる情報が掲載されています。また、フローの使用についての動画も忘れずにご覧ください。

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

起動時のパフォーマンスをテストする

先週私は、アプリの起動時のパフォーマンスに関するいくつかの処理を自動化する方法について、ブログ記事（英語）を投稿しました。私は、起動時のパフォーマンス全般に注目しており、何度も繰り返して連続実行する際に、起動時間を求める処理を自動化する妥当な方法を見つけたいと考えてきました。同じように起動時のパフォーマンス テストに興味がある方のために、私が利用したアプローチを公開しています。

Dagger -> Hilt

Manuel Vivo は、Dagger から Hilt への移行というブログ記事（英語）で、「その価値はあるのか？」という疑問を投げかけています。このブログ記事では、移行を検討すべきいくつかの重要な理由に触れています。たとえば、API のテスト、整合性、AndroidX 拡張機能との統合などです。

Hilt を使ってみる

Hilt を使い始めるデベロッパーの皆さんに役立ててもらうため、Filip Stanis がKotlin による Hilt 実践ガイド（英語）を投稿しました。依存性注入や Dagger を使ったことがない方でも大丈夫です。まったく初めてという方も、ぜひお読みください。

タイトルからは、この記事が Kotlin デベロッパー向けのように思えるかもしれませんが、これは記事のコード スニペットに Kotlin を使っているからです。記事で紹介している一般的なアプローチやテクニックは、Java プログラミング言語を使っているデベロッパーにも当てはまります。

フローを使う

Manuel Vivo が Kotlin Vocabulary シリーズに新しい動画を投稿しました。Kotlin フローを使ってデータのストリームを発行する方法について説明しています。これは、以前公開した動画、コルーチンの ABC が元になっているので、先にそちらを見てからフローを学ぶのもよいでしょう。

Kotlin Extensions: View Binding と Synthetics

David Winer が Kotlin Synthetics と View Binding についてのブログ記事を投稿しました。この 2 つはどちらも、厄介な findViewById() 呼び出しをコードから無くすためのメカニズムです。このブログ記事では、Kotlin プラグインの今後のバージョンで Synthetics のサポートが終了することをお伝えしています。また、今後も推奨とサポートが継続される @Parcelize エクステンションについても触れています。

バックグラウンド位置情報

最近の Android リリースでは、ユーザーデータの保護、データアクセスへのコントロール、透過性向上に関して、多くの変更が行われています。特に重視されている領域が位置情報です。ユーザーは、アプリの位置情報へのアクセスを望まない場合や、そのアクセスを非常に注意深く制御したい場合があるからです。

そのため、Google Play ポリシーにより、バックグラウンドでの実行中に位置情報にアクセスするアプリでは、（Play Store から）アクセス許可をリクエストする操作が必須になります。このブログ記事では、そのリクエスト方法について詳しく説明しています。

またお会いしましょう

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