現在、世界中の人々がモバイル デバイスを使い、指先だけで、友人や家族とのつながりを維持したり、金銭を管理したり、ヘルスケア情報を追跡したりしています。しかし、デバイスが悪意のある人に盗まれると、機密データの流出、ID の盗難、金融詐欺、プライバシー侵害といった被害に遭う可能性があります。

先日、その対策として、Android の盗難防止機能をリリースしました。この包括的な機能は、デバイスの盗難前、盗難中、盗難後のすべての段階で、ユーザーとデータを保護できるように設計されています。Android の安全を確保するための取り組みの一環として、この機能を拡張して強化し、世界中のユーザーがさらに強力な保護を受けられるようにします。

 

ID チェックを Pixel および Samsung One UI 7 デバイスにロールアウト

最初に ID チェックが正式導入されるのは、Pixel と One UI 71 の対象となる Samsung Galaxy デバイスです。これらのデバイスでは、アカウントとデバイスに関する重要な設定の保護が強化されます。ID チェックをオンにすると、信頼できる場所以外から特定の機密リソースにアクセスする場合に、デバイスで明示的な生体認証が必須になります。さらに、サポートされているすべてのデバイスで Google アカウントの保護が強化されます。One UI 7 対応の Galaxy デバイスでは、Samsung アカウントのセキュリティが強化され、デバイスにログインしているアカウントの不正な乗っ取りがはるかに難しくなります。

ID チェックを有効化する際に、複数の信頼できる場所を指定できます。信頼できる場所以外にいる場合、デバイスの PIN や生体認証の変更、盗難防止の無効化、パスキーへのアクセスなど、アカウントやデバイスに関する重要な設定にアクセスする際に、生体認証が必須になります。

ID チェックを利用することで、特に機密性の高いデバイス資産が確実に不正アクセスから保護されるという安心感が得られます。たとえ盗難者や悪意のある者がデバイスの PIN を知ったとしても、セキュリティが破られることはありません。

現在、Android 15 を搭載した Pixel デバイスへのID チェックのロールアウトが行われています。One UI 7 対応の Galaxy デバイスは、今後数週間以内に利用できるようになります。今年中には、他のメーカーの対応 Android デバイスにもロールアウトされる予定です。

 

盗難検知ロック: AI を活用した保護を拡大

昨年導入した重要な盗難防止機能の 1 つが、盗難検出ロックです。これは、オンデバイス AI アルゴリズムを活用して、スマートフォンが盗難に遭った可能性を検出する機能です。機械学習アルゴリズムにより、ロックされていないデバイスで盗難に遭った可能性が検知されると、盗んだ人による操作を防ぐため、画面がロックされます。

盗難検知ロックは、世界中の Android 10 以上のスマートフォン2 へのロールアウトが完了しています。

 

Android デバイスの盗難保護

私たちは、GSMA や業界のエキスパートと協力し、情報やツール、予防技術を共有することで、モバイル デバイスの盗難に対抗しています。近日中に GSMA ホワイト ペーパーを公開しますので、ご期待ください。モバイル業界と協力して作成したこのホワイト ペーパーには、デバイスの盗難から自分自身や組織を保護するための詳しい情報を含める予定です。

Android では、ID チェックの追加と既存機能の継続的な拡張を通し、堅牢で包括的なツールセットを提供することで、デバイスとデータを盗難から保護します。私たちは、個人情報が確かに守られているという安心感を皆さんにお届けする取り組みを続けています。

サポートされている Android デバイスでこちらをクリックすると、新しい Android の盗難保護機能をオンにすることができます。盗難防止機能の詳細については、ヘルプセンターをご覧ください。


  1. One UI 7 では、タイミング、対象、機能名が異なる場合があります。 

  2. Android Go スマートフォンを除きます。 


Posted by Eiji Kitamura - Developer Relations Team

  • 境界サニタイザー: 攻撃者がスペースに許容量以上のデータを詰め込もうとした場合、コードにバグがあると、データがあふれて他のデータが破損したり、悪意のあるコードが実行されたりします。これがバッファ オーバーフローです。境界サニタイザーは、特定の方法でメモリにアクセスする箇所にチェックを自動追加し、コードが指定された領域以外のメモリにアクセスしないようにすることで、メモリの破損を防ぎます。
  • 整数オーバーフロー サニタイザー: 数値は重要です。大きすぎると「オーバーフロー」が発生し、小さい値として誤解釈される可能性があります。逆も発生することがあります。数値が負の方向にオーバーフローすると、大きな値として誤解釈される可能性があります。攻撃者がこういったオーバーフローを悪用すると、予期しない動作が引き起こされる可能性があります。整数オーバーフロー サニタイザーは、そのような演算が行われている箇所にチェックを追加し、この種の脆弱性によるメモリ破損のリスクを排除します。
  • スタック カナリア: スタック カナリアは、コードが確実に想定される順序で実行されるように、あらかじめ仕掛けを施しておく仕組みです。ハッカーがスタックの脆弱性を悪用し、カナリアに気付かずに実行フローを変更しようとすると、カナリアが「作動」するため、システムは攻撃された可能性があることを検知できます。
  • 制御フローの整合性(CFI): CFI もスタック カナリアと同じように、コードが限定されたパスのみに従って実行されることを保証します。攻撃者が許可された実行パスから逸脱させようとしても、CFI によってモデムが再起動されるので、許可されていない実行パスに入ることはありません。
  • スタック変数の自動初期化: C/C++ では、デベロッパーがメモリを使う宣言を行っても、通常は初期化されません。割り当てられた領域を正しく設定するのは、デベロッパーの役割であると想定されているからです。これが正しく処理されないと、値が初期化されないことによって機密データが漏洩したり、攻撃者に操作されてコードが実行されたりする可能性があります。Pixel スマートフォンでは、スタック変数が自動的にゼロに初期化されるので、スタックデータの脆弱性を防ぐことができます。
また、テストプロセスでは、アドレス サニタイザーなどの多くのバグ検出ツールも活用しています。これにより、ソフトウェアのバグを特定し、デバイスをユーザーに出荷する前にパッチを適用することができます。

Pixel のメリット: 保護を組み合わせて最大限のセキュリティを実現する

セキュリティ強化は難しく、この作業に決して終わりはありません。しかし、以上のようなセキュリティ対策を組み合わせることで、Pixel 9 のベースバンド攻撃に対する耐性は大幅に向上しています。

Pixel の積極的なセキュリティ アプローチは、ソフトウェア スタック全体にわたってユーザーを保護するという取り組みを体現したものです。リモート攻撃に対するセルラー ベースバンドの防御力強化は、時代の先を行く Pixel のセキュリティ対策の一例に過ぎません。

セルラー ベースバンドの防御力強化作業に参加してくれた同僚に感謝します。Dominik Maier、Shawn Yang、Sami Tolvanen、Pirama Arumuga Nainar、Stephen Hines、Kevin Deus、Xuan Xing、Eugene Rodionov、Stephan Somogyi、Wes Johnson、Suraj Harjani、Morgan Shen、Valery Wu、Clint Chen、Cheng-Yi He、Estefany Torres、Hungyen Weng、Jerry Hung、Sherif Hanna



Janine Roberta Ferreira さんは、サンパウロの職場から車で帰宅する途中、信号の前で停止しました。すると突然男が現れ、ロックされていなかった車の窓を割り、スマートフォンを奪おうとしました。Janine さんは男としばらく争いましたが、最終的に男はスマートフォンを奪って逃げていきました。この出来事は、Janine さんにとって大きなショックでした。甥の写真など、貴重なデータが奪われた悲しみだけではありません。盗まれたばかりのスマートフォンには、銀行の情報が保存されていたので、大変な不安を感じました。

このような状況を考えれば、プラットフォームに関わらず、既存のツールを上回る包括的なスマートフォン盗難対策が必要であることは明らかです。スマートフォンの盗難は、多くの国で広く懸念されています。ブラジルでは、1 時間あたり 97 台のスマートフォンが盗難に遭っています。GSM 協会は、毎年数百万台というデバイスが盗まれていると報告しており、その数は今も増え続けています。

決済情報や個人情報など、ますます多くの機密データがスマートフォンに保存されるようになっているため、スマートフォンをを紛失すれば、誰でも不安に感じるはずです。そこで、一連の機能を開発して徹底的なベータ版テストを行い、デバイスの盗難前、盗難中、盗難後のあらゆる段階で、皆さんのデバイスとデータを保護できるようにしました。


この高度な盗難防止機能は、Android 15 と Google Play 開発者サービスのアップデート(Android 10 以上のデバイス)を通じて、世界中のユーザーが利用できます。

盗難に遭った瞬間に AI がデバイスを保護

盗難検知ロックは、強力な AI を活用することで、スマートフォンが盗まれかけているときに、先回りして保護を行います。具体的には、オンデバイス機械学習でさまざまなデバイス シグナルを分析し、盗難に遭った可能性があることを検知します。ロックされていないデバイスで盗難に遭った可能性が検知されると、盗んだ人による操作を防ぐため、画面がロックされます。

スマートフォンが盗まれた場合に機密データを保護するため、デバイスのセンサーを使って、スマートフォンが盗まれかけているかどうかを識別します。私たちは、この機能をできるだけ多くのデバイスに導入できるように、懸命に作業を進めています。さまざまなデバイスとの互換性を確保するため、世界のアクティブ ユーザーの 90% をカバーする Android デバイスに対して、本日(元記事公開当時)より徐々にロールアウトします。現在お使いのデバイスがサポートされているかどうかは、盗難防止設定ページを定期的にチェックすることで確認できます。


盗難検知ロックのほかに、オフライン デバイスロックも搭載されます。この機能は、盗んだ人がデータを抽出したり、Android の「デバイスを探す」によるリモートワイプを回避したりするため、デバイスをオフラインにする場合への対策となります。ロック解除されたデバイスが長期間オフラインになると、この機能によって画面がロックされるので、盗んだ人はスマートフォンを使えなくなります。

Android デバイスを紛失したり、デバイスが盗まれたりした場合は、リモートロックを使ってすばやく保護できます。盗まれたときに Google アカウントの認証情報を覚えていなくても、任意のデバイスで Android.com/lock にアクセスすれば、認証済みの電話番号だけでスマートフォンをロックできます。リモートロックは、Android の「デバイスを探す」からデバイスにアクセスできるようになるまでの間、そのデバイスを保護します。この機能を使うと、デバイスの保護、検索、リモートワイプが可能です。デバイスのリモートワイプが問題にならないように、セキュリティのベスト プラクティスとして、継続的にデバイスをバックアップすることをお勧めします。

以上の機能は、Android 10 以上のほとんどのデバイス1 で利用できます。Google Play 開発者サービスをアップデートし、設定から機能を有効にする必要があります。

盗難を未然に防ぐ高度なセキュリティ

Android 15 には、盗難を未然に防ぐための新しいセキュリティ機能が導入されています。これは、盗んだ人が機密設定やアプリにアクセスしたり、再販のためにデバイスをリセットしたりすることを難しくすることによって実現します。
  • 「デバイスを探す」などの機密設定を変更するには、PIN、パスワード、または生体認証が必要になります。
  • 複数回ログインに失敗すると、盗んだ人がパスワードを推測しようとしている可能性があると判断し、不正アクセスを防ぐためにデバイスがロックダウンされます。
  • 出荷時設定へのリセット保護機能も強化されます。再販価値を大幅に下げてデータを守るため、Google アカウントの認証情報を使わずにデバイスをリセットする操作は、さらに難しくなっています。
今年中には、オプトイン機能として本人確認を導入し、新たな保護レイヤーを追加します。これにより、PIN の変更、盗難防止の無効化、信頼できない場所からのパスキーへのアクセスなど、重要な Google アカウントやデバイスの設定にアクセスする際に、生体認証が必須となります。そのため、デバイスの PIN が侵害された場合でも、不正アクセスを防ぐことができます。

現実世界で数十億人の Android ユーザーを保護する

AI や生体認証などの高度な技術を組み込み、Android デバイスが盗難の対象となりにくくすることによって、皆さんの安心を高めます。このような盗難防止機能は、現実世界のすべての人を保護しようとする Android の取り組みの一例に過ぎません。私たちは、世界中のパートナーと協力し、Android のセキュリティを継続的に改善することで、皆さんと皆さんのデータの安全を確保しようとしています。

サポートされている Android デバイスでこちらをクリックすると、新しい Android の盗難保護機能をオンにすることができます。盗難防止機能の詳細については、ヘルプセンターをご覧ください。


  1. Android Go のスマートフォン、タブレット、ウェアラブルはサポート対象外 


Posted by Eiji Kitamura - Developer Relations Team


この記事は Product Manager, Google Maps Platform の Ilya Bezdelev による Google Cloud Blog の記事 "Learn about our updated renderer for the Maps SDK for Android" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Google は、Android における Google Maps Platform の開発体験を向上させる方法を常に模索しています。そのため、Maps SDK for Android のレンダラを更新し、より多くの機能とより優れたパフォーマンスを提供できるよう取り組んでいます。

2021 年 10 月に更新したレンダラをご利用いただいているデベロッパーの皆様に感謝申し上げます。最新バージョンには、良い点や改善案などの皆様からのフィードバックに基づいた改良が施されており、すぐにお試しいただけます。アップグレードされたマップレンダラは、Maps SDK for Android のバージョン 18.0.0 以降でご利用いただけます。オプトインしてご利用のうえ、機能の不具合報告については適宜お知らせいただければ幸いです。

新しいマップレンダラの利点は次のとおりです。

新しいレンダラを使用できるデバイス :デバイスで Android 4.4W(API レベル 20)以前を使用している場合、デバイスのデータ ストレージが 2 GB 未満の場合、またはデバイスでバージョン 21.39.13 以前の Google Play 開発者サービスを使用している場合は、従来のレンダラを引き続きご利用ください。

新しいマップレンダラにアップグレードする方法

MapsInitializer.initialize() を呼び出してレンダラ バージョンをリクエストする方法について 2 つのコードサンプルを次に示します。

import com.google.android.gms.maps.MapsInitializer;

import com.google.android.gms.maps.MapsInitializer.Renderer;

import com.google.android.gms.maps.OnMapsSdkInitializedCallback;

class MapRendererOptInApplication extends Application implements OnMapsSdkInitializedCallback {

 @Override

 public void onCreate() {

   super.onCreate();

   MapsInitializer.initialize(getApplicationContext(), Renderer.LATEST, this);

 }

 @Override

 public void onMapsSdkInitialized(MapsInitializer.Renderer renderer) {

   switch (renderer) {

     case LATEST:

       Log.d("MapsDemo", "The latest version of the renderer is used.");

       break;

     case LEGACY:

       Log.d("MapsDemo", "The legacy version of the renderer is used.");

       break;

   }

 }

}

Java のコードサンプル

import com.google.android.gms.maps.MapsInitializer

import com.google.android.gms.maps.MapsInitializer.Renderer

import com.google.android.gms.maps.OnMapsSdkInitializedCallback

internal class MapRendererOptInApplication : Application(), OnMapsSdkInitializedCallback {

 override fun onCreate() {

   super.onCreate()

   MapsInitializer.initialize(applicationContext, Renderer.LATEST, this)

 }

 override fun onMapsSdkInitialized(renderer: MapsInitializer.Renderer) {

   when (renderer) {

     Renderer.LATEST -> Log.d("MapsDemo", "The latest version of the renderer is used.")

     Renderer.LEGACY -> Log.d("MapsDemo", "The legacy version of the renderer is used.")

   }

 }

}

Kotlin のコードサンプル

お問い合わせ

レンダラがうまく機能せずお困りの場合、Issue Tracker に問題点を登録してください。できる限り早急に対応いたします。Android 用の新しいマップレンダラをオプトインして使用を開始する方法については、こちらのドキュメントをご覧ください。機能の具合について、皆様からのフィードバックをお待ちしております。すでに新しいレンダラにアップグレードされた方には、今後のサービス向上のため簡単なアンケートにご回答いただいております。ご協力のほどよろしくお願いいたします。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。 

Posted by 丸山 智康 (Tomoyasu Maruyama) - Developer Relations Engineer 

Share on Twitter Share on Facebook


この記事は Developer Advocate の Alex Muramoto による Google Cloud Blog の記事 "Announcing Advanced Polylines for the Maps SDKs for Android" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

デベロッパーによる Google マップの基本地図のスタイル設定とカスタマイズを可能にする継続的な取り組みの一環として、この度、Maps SDK for Android 向けの高度なポリラインのスタイル設定の提供を開始することを発表します。この機能は、現在 Google が提供しているポリライン機能の上に構築されています。デベロッパーはこの機能を使って、地図上に表示される定型の線を作成できます。こうした定型の線は、経路、パレードルート、通行止めなどの情報を表すためによく使用されます。ポリラインは、Google Maps Platform のデベロッパーが、ユーザー向けに地図をカスタマイズする際に最もよく使う機能の一つです。

高度なポリラインのスタイル設定では、マルチカラー ポリライン、グラデーションのポリライン、スタンプ型ポリラインの 3 つの新しいポリラインのカスタマイズを導入することで、ポリラインのコア機能をより豊かに、表現力のあるものにできます。

高度なポリラインのスタイル設定は、最新のレンダラを有効にしたバージョン 18.1.0 以降の Maps SDK for Android とバージョン 5.2.0 の Maps SDK for iOS において、利用可能です。

マルチカラー ポリライン

マルチカラー ポリラインを使うと、ポリラインをセグメント化し、各セグメントに異なる色を適用して情報を表現することができます。このカスタマイズは、経路上のさまざまな情報を伝える、季節のキャンペーンで企業のブランディングに合わせる、あるエリアに注目を集めるなど、さまざまなユースケースで活用できます。

マルチカラー ポリラインを使用するには、`StyleSpan` オブジェクトを作成し、`addSpan()` または `addSpans()` メソッドを `PolylineOptions` に追加します。デフォルトでは、配列の各アイテムが対応する線分の色に設定されます。次の例では、セグメントの色を設定して、緑と紫(マゼンタ)のセグメントを持つポリラインを作成しています。

 Polyline line = map.addPolyline(new PolylineOptions()

        .add(new LatLng(37.789258, -122.387819),

          new LatLng(37.786572, -122.390556),

          new LatLng(37.786140, -122.390899))

        .addSpan(new StyleSpan(Color.MAGENTA))

        .addSpan(new StyleSpan(Color.GREEN))

      );

グラデーションのポリライン

グラデーションのポリラインは、ポリライン全体に 2 色のグラデーションを適用します。交通の流れや標高の変化など、強弱の変化を表現するのに便利です。

グラデーション ポリラインを使用するには、ポリラインの開始色と終了色を設定する 2 つの 32 ビットの ARGB(alpha、red、green、blue)値を指定してグラデーションを定義し、次に `PolylineOptions.addSpan()` を呼び出して、このプロパティを図形のオプション オブジェクトに設定します。

以下は、サンフランシスコからランチョ コラール デ ティエラまでのグラデーション ポリラインを作成する例です。

 Polyline line = map.addPolyline(new PolylineOptions()

        .add(new LatLng(37.662953, -122.400542), new LatLng(37.5414277, -122.4845455))

        .addSpan(new StyleSpan(StrokeStyle.gradientBuilder(Color.GREEN, Color.RED).build())));

スタンプ型ポリライン

スタンプ型ポリラインを使うと、選択したビットマップ画像を繰り返し使ってポリラインを作成できます。これにより、図形とポリラインの外観のカスタマイズが可能になります。

スタンプ型ポリラインを使用するには、`TextureStyle` の `StampStyle` を作成して、ポリラインの外観をビットマップ テクスチャの繰り返しに設定します。このプロパティは、`PolylineOptions.addSpan()` を呼び出すことで、図形のオプション オブジェクトに設定できます。

 StampStyle stampStyle = TextureStyle.newBuilder(BitmapDescriptorFactory.fromResource(R.drawable.arrow)).build();

Polyline line = map.addPolyline(

new PolylineOptions()

.add(

new LatLng(37.789258, -122.387819), 

new LatLng(37.786572, -122.390556), 

new LatLng(37.786140, -122.390899))

.addSpan(new StyleSpan(StrokeStyle.colorBuilder(Color.BLUE).stamp(stampStyle).build()))

.addSpan(new StyleSpan(StrokeStyle.colorBuilder(Color.YELLOW).stamp(stampStyle).build()))

);

スタイル設定とカスタマイズ機能は、ユーザーにより良いマッピング サービスを提供し、重要な情報を伝え、独自の地図を作り上げるために、最適かつ最も簡単な方法の一つです。最近リリースしたクラウドベースのマップスタイル設定、データドリブンのスタイル設定、WebGL を活用したマップ機能などのスタイル設定やカスタマイズ機能はもちろんのこと、Google Maps Platform チームは、それぞれのニーズを満たす柔軟性を備えた素晴らしいマッピング サービスを提供するツールをお届けできるよう、取り組みを続けています。この新しい、マップ上のポリラインのカスタマイズとスタイル設定をぜひご活用ください。

Google Maps Platform に関する詳しい情報はこちらをご覧ください。ご質問やフィードバックはページ右上の「お問い合わせ」より承っております。


Posted by 丸山 智康 (Tomoyasu Maruyama) - Developer Relations Engineer 
Share on Twitter Share on Facebook


本プログラムではオンライン学習ツール Pathways 上にあるネイティブ Android UI を開発するための最新のツールキット「Compose」について学習します。

お申し込みはこちら

    Android Study Jams の流れ :

    1. Android Study Jam ウェブサイト上部の "Register" ボタンから参加登録

    2. Google Developers Profile をお持ちでない場合)Google Developers アカウントのセットアップ
      https://developers.google.com/ へアクセスし、Developer Profile を作成いただけます。

    3. 7 月 19 日(火)16:00 ~ 18:00 のオンライン キックオフ セッションに参加(任意)

    4. Jetpack Compose Pathway (合計 13 件のアクティビティ)を完了しましょう。
      ※ 7 月 19(火)~ 8 月 19 日(金)の期間内にバッジを獲得された方のみ、グッズ企画の対象となりますので、ぜひ期間中に Pathway を完了してみましょう!

    5. 期間内にクイズを受講し、バッジを獲得

    6. 先着順でグッズ企画のキャンペーンに応募


    プログラム概要

    プログラム期間 : 2022 年 7 月 19 日(火) ~ 8 月 19 日(金)

    キックオフ セッション : 2022 年 7 月 19 日(火)16:00 ~ 18:00

    Compose を初めてご利用いただく方にもご安心いただけるように、キックオフ セッションで使い方を説明し、いくつかのラボを解説つきで実施します。(本セッションは、アーカイブでもご覧いただけます。セッションに参加できなくても、プログラムに参加して学習することは可能です)

    対象 : Android, Compose を学びたい大学生以上の方

    費用 : 無料

    実施方法 : オンライン


    参加特典

    本プログラムに登録しプログラムを修了した参加者には、下記のノベルティをプレゼントいたします。


    コミュニティ支援

    1 人ではなかなか思うように勉強が進まない方を支援することを目的とした、勉強会を開催するコミュニティを募集します。コミュニティが主催する勉強会に参加することで、1 人では解決しなかった課題などを解決しましょう。

    コミュニティ主催の勉強会の情報は随時こちらのブログで更新していきます。また主催者となって勉強会を開催してくださるコミュニティのオーガナイザーの方には Google からの支援をおこないますので、こちらのフォームから申し込んでください。

    皆様のご参加をお待ちしております。


    お問い合わせ

    [email protected] 


    Posted by Takuo Suzuki - Developer Relations Team

    Share on Twitter Share on Facebook

    I/O では毎年、Android のプライバシーとセキュリティの最新機能についてお話ししています。しかし、ユーザーの皆さんの中には、Google が最新リリースでシームレスなエクスペリエンスを提供しつつ、安全性やプライバシーを強化している方法について、もっと詳しく知りたいと考えている方もいます。そこで、データ保護を強化し、プライバシーを高めてアプリの信頼性やデバイスのエクスペリエンスを向上するために開発しているツールについて、詳しく説明したいと思います。

    高速で邪魔にならないセキュリティ

    スマートフォンを使うのが消費者であっても企業であっても、デバイスとそこで実行されるアプリの妥当性を保証するうえで、重要な要素となるのが構成証明(attestation)です。基本的に、鍵の構成証明とは、デベロッパーがシークレットまたは指定されたデータをデバイスにバインドすることです。これは、この鍵が利用できる限り「同じユーザー、同じデバイス」であるという主張であり、暗号学的に妥当性を主張できます。

    Android 13 では、Android デバイスへの構成証明鍵のプロビジョニング方式を新しいモデルに移行しました。この方式はリモート鍵プロビジョニング(RKP)と呼ばれています。新しいアプローチでは、工場でのプロビジョニング エラーを無くし、鍵の脆弱性のリカバリ方法を提供することで、デバイスのセキュリティを強化します。具体的には、構成証明鍵の証明書管理ライフサイクルにおいて、Google の責任範囲を広げたアーキテクチャに移行することによって実現します。RKP の詳細は、こちらから確認できます。

    また、Google Play システム アップデートを使って直接アップデートできるモジュールをさらに増やします。これにより、シームレスかつ自動的により多くのシステム コンポーネントをアップグレードしたりバグを修正したりできるようになるため、デベロッパーはアップデートについて気にする必要がなくなります。現在、Android の 30 以上のコンポーネントが Google Play 経由で自動アップデートできる状態になっています。これには、Android 13 の新モジュールである Bluetooth や超広帯域無線(UWB)も含まれています。

    昨年は、主要なオペレーティング システムの脆弱性のほとんどが、C や C++ などのプログラミング言語の未定義の動作によって引き起こされていることについてお話ししました。Rust は高度なシステム プログラミング(OS、ネットワーク)に必要な効率と柔軟性を兼ね備えたもう 1 つの言語ですが、Rust にはメモリ安全性という追加の利点があります。うれしいお知らせですが、鍵管理コンポーネントやネットワーク スタックなどの Android のセキュリティ上重要な部分に、Rust が採用されています。

    強固なプラットフォームの実現は、メモリ安全性や不正利用防止技術などを継続的に改善することにとどまりません。強固な API サーフェスを実現して、エンドユーザーにより安全なエクスペリエンスを提供することもその一部です。

    Android 13 では、アプリ デベロッパーが意図せずに導入してしまいがちな潜在的脆弱性への対策として、たくさんの機能拡張を実装しました。その 1 つとして、アプリの特定のブロードキャスト レシーバをエクスポートしてデバイスの他のアプリに公開するかどうかをデベロッパーが指定できるようにすることで、ランタイム レシーバの安全性を向上しています。また、インテント フィルタで一致しないインテントをブロックすることで、アプリとそのコンポーネントの保護をさらに強化します。

    特定のセキュリティ認証要件に準拠しなければならない企業ユーザーのために、セキュリティ ログ レポートをアップデートして、セキュリティ ログのカバレッジを増やすとともに、ログを 1 か所にまとめるようにしました。この機能は、Common Criteria などの標準に準拠しなければならない企業に便利です。また、すべてのセキュリティ関連ログを 1 か所で審査できるので、管理ソリューション プロバイダなどのパートナーにとっても有益です。

    条件に合わせたプライバシー

    Android 13 では、プライバシーを重視したアプリを開発する方法が増えます。新しい写真ピッカーを使うと、別のアプリにメディア ライブラリへのアクセス権を与えることなく、共有したい写真や動画のみを選択できます。現在、アプリでこの機能を実装できるようになっています。

    Android 13 では、昨年導入した周辺デバイス パーミッションを利用して、動作するために位置情報を要求しなければならないアプリの数も減らします。たとえば、一部のアプリや状況で、Wi-fi を有効にするために位置情報をオンにする必要はなくなります。また、ストレージの動作を変更し、オーディオ、画像、動画のファイルにアクセスするパーミッションを別々に要求しなければならないようにしました。

    これまでは、アプリがバックグラウンドからクリップボードにアクセスすることは制限されており、それが行われた際には警告を表示していました。Android 13 では、短い周期でクリップボードの履歴を自動削除するので、アプリが以前にコピーされた情報を見ることはできなくなります。

    Android 11 より、長期間利用しなかったアプリに付与されたパーミッションの自動リセットが導入され、その後、この機能は Android 6 以降を実行しているデバイスにまで拡大されています。それ以来、50 億以上のパーミッションが自動リセットされました。

    Android 13 では、アプリ制作者がさらに積極的にパーミッションの削除ができるようになります。デベロッパーは、アプリが不要なパーミッションを保持する時間を短縮することで、プライバシーを強化できます。

    通知が多くのアプリにとって重要であることは認識していますが、ユーザーにとっては、すべての重要度で同じであるわけではありません。Android 13 デバイスの新規アプリは、デフォルトで通知を送信する前にパーミッションを求めることが義務づけられるので、アラートを受け取りたいアプリを細かく制御できるようになります。

    信頼できるアプリ

    ほとんどのアプリ デベロッパーは、パッケージ化された機能がバンドルされたさまざまなソフトウェア開発キット(SDK)を使ってアプリを開発しています。SDK はすばらしい機能を提供してくれますが、一般的に、アプリ デベロッパーが SDK コードの確認や調整を行うことはほぼ不可能です。パフォーマンスの分析も同様です。

    そこで、アプリの安全性を高めることを目的として、デベロッパーと連携して、新しい Google Play SDK Index を導入します。これにより、SDK のコードをアプリに組み込む前に、SDK の安全性や信頼性に関するシグナルを確認できるようになります。すべての方が、この仕組みを活用して、アプリのエコシステムのセキュリティとプライバシーを強化することができます。

    先月、Google Play で新しいデータ セーフティ セクションのロールアウトを開始しました。これにより、アプリがユーザーのデータをどのように収集、共有、保護する予定であるかを、アプリをインストールする前に知ることができます。また、さらに Play アプリの信頼性向上を促すため、デベロッパーが世界で認知されているモバイルアプリのセキュリティ標準である OWASP の MASVS に照らして、独立してアプリを検証できるようにしました。

    私たちは、少数のデベロッパー グループや認定ラボパートナーと共同で、このプログラムを進化させようとしています。この独立した検証を終えたデベロッパーは、その旨をデータ セーフティ セクションに表示することができます。

    その他のモバイル セキュリティと安全性

    現在、Google Play のマルウェア対策によって、1 日あたり 1,250 億個のアプリがスキャンされています。私たちは、それと同じように、スパムやフィッシングの検知には組み込みの機能が使われるべきだと考えています。うれしいことに、ある最新の分析レポートで、フィッシングと詐欺対策の組み込みメッセージング アプリとして、Messages が最も高い評価を受けました。

    現在、Messages は、毎月 15 億のスパム メッセージからの保護に役立てられています。そのため、迷惑メールも不正アクセスの試みも避けることができます。悪意のあるユーザーが情報を盗み取ろうとして、リンクをクリックさせようとしたり、アプリをダウンロードさせようとしたりするケースが増えています。そのため Google は、常に新たな防御策を探し続けています。

    昨年には Messages にエンドツーエンドの暗号化を導入し、モバイルでの会話のセキュリティを向上しました。今年は、グループ会話のエンドツーエンド暗号化をベータ版としてリリースし、個人のメッセージの保護をさらに強化する予定です。

    Google はたくさんの機能を開発していますが、それをオープンで透過性のある形で行っています。Android 11 では、スマートフォンでプライバシーを保ちながらデジタル ID を使えるようにするプラットフォーム機能についてお知らせしました。これは、ISO 規格に準拠した新機能でした。カード型の免許証(またはその他の身分証明書)を誰かに渡して確認してもらう場合、選択の余地はありません。つまり、相手はフルネーム、生年月日、住所などの個人を特定できる情報(PII)にアクセスできます。モバイル版ならもっと細かい制御が可能で、相手に何を公開するのかをエンドユーザーやアプリが厳密に選択できます。さらに相手も、返されたデータを保持するつもりかどうかを宣言しなければなりません。また、身元を明かすことなく、年齢などの一部の詳細情報を提示することもできます。

    直近 2 回の Android リリースでは、この API を改善し、サードパーティ組織がさまざまなデジタル身分証明のユースケースを簡単に利用できるようにしています。運転免許証、学生証、企業のバッジなどがその一例です。ここで、Google Wallet が Android Identity Credential を使ってデジタル ID と運転免許証をサポートすることを発表します。Google は、米国の各州や世界中の政府と連携し、今年中に Wallet でデジタル ID を実現する予定です。Google Wallet の新しい機能強化の詳細については、こちらからご覧ください。

    Android による保護

    Google は、皆さんのセキュリティとプライバシーはわかりやすく、制御しやすいものであるべきだと考えています。今年は、Android 13 デバイスの設定画面に、デバイスのセキュリティとデータのプライバシーのすべてを管理できる機能をロールアウトする予定です。

    新しいセキュリティとプライバシーの設定ページでは、安全性の状態を色分けされたシンプルな表現で示すほか、セキュリティとプライバシーを改善するための明確で実用的なガイダンスも提供する予定です。このページの中心は、新しいアクション カードです。安全性のリスクに対処するために実行すべき重要な手順が、そこに通知されます。問題について警告する通知のほかに、プライバシーを強化する方法についてのタイムリーなおすすめも提供したいと考えています。

    データを管理できているという安心感を得るには、信頼できる安全な土台が必要です。デバイスが安全でなければ、プライバシーの保護は望めないからです。Android が常に皆さんを守ることができるように、私たちは懸命に努力を続けています。その保護について詳しく知りたい方は、ウェブサイトをご覧ください。


    Reviewed by Eiji Kitamura - Developer Relations Team
    Share on Twitter Share on Facebook

    Figure 1: IME(例、Gboard)は 漢字の選択肢を表示
    Figure 1: IME(例、Gboard)は 漢字の選択肢を表示



    入力処理を行う IME アプリには、下記のような情報が保存されています。
    1. IME内のメニュを表示するための一般的な「漢字↔よみがな」の対応情報
    2. ユーザーが選択した変換の履歴に基づいた「漢字↔よみがな」の対応情報
    上記の 1 と 2 の情報は、IME のデータベースで管理されます。このデータベースは、ユーザーの入力や IME の人工知能によって、改善されてゆきます。

    つまり IME は「推測しにくい」よみがなを、ユーザーの文字入力によって、簡単に取得することができるように作られているのです。また、そのよみがなは、漢字の情報とともにデバイス上でデータベース化されます。

    Q:その貴重なデータをアプリケーションと提供する方法はないのでしょうか?
    A:はい!この記事を書いているのは日本語を利用する Android アプリ開発者の皆様にそれをご紹介するためです。Gboard で漢字の変換データをアプリと共有する API が利用可能になりました。

    Figure 2: 漢字入力とともに、よみがな情報を提供するIME



    この Gboard(v10.1 以降)に追加された API は、IME のテキスト出力に、よみがなを span として追加します。この API を利用するアプリケーションは、その出力を拾うことで、高い精度でユーザーの入力した文章に該当するよみがなを推測できるようになります。

    よみがな情報を取得するためには、漢字入力の対象となる TextEdit が下記の条件を満たす必要があります:

    • ア)inputType プロパティの値を textPersonName にする。
    • イ)privateImeOptions プロパティの値を com.google.android.inputmethod.latin.requestPhoneticOutput にする。
    Android Studio の Layout エディターで見た場合、設定は下記のようになります。

    Figure 3: Android Studioのプロパティ設定

    次に、TextWatcher を宣言し、入力通知の際、CharSequence から、getSpans() によって該当する TtsSpan を取得します。
    public class MainActivity extends AppCompatActivity {
    
        private class PhoneticRetriever implements TextWatcher {
            // Extracts phonetic metadata from an incoming text blob
            private String getPhoneticMetadata(CharSequence s) {
                String phonetic = null;
                if (s instanceof SpannableStringBuilder) {
                    SpannableStringBuilder textAsSpan = (SpannableStringBuilder) s;
                    TtsSpan[] allSpans = textAsSpan.getSpans(0, s.length(), TtsSpan.class);
                    if (allSpans.length == 1 && allSpans[0].getType().equals(TtsSpan.TYPE_TEXT)) {
                        // log shows where the span is in the text
                        Log.v("PHON",
                                s.toString() + " [" + textAsSpan.length() + "] start:" +
                                textAsSpan.getSpanStart(allSpans[0]) + " end:" +
                                textAsSpan.getSpanEnd(allSpans[0]));
                        phonetic =  allSpans[0].getArgs().getString(TtsSpan.ARG_TEXT);
                        textAsSpan.removeSpan(allSpans[0]); // avoid consuming again
                    }
                }
                return phonetic;
            }
            @Override
            public void afterTextChanged(Editable s) {
                String sphonetic = getPhoneticMetadata(s);
                if (sphonetic == null) {
              // no phonetic data
                } else {
                    // phonetic data is in sphonetic - use it as you like
                }
            }
    
            @Override
            public void beforeTextChanged(CharSequence s, int start, int count, int after) {}
    
            @Override
            public void onTextChanged(CharSequence s, int start, int before, int count) {}
        }
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            EditText etUserInput = (EditText)findViewById(R.id.editTextPhoneticWithOptions );
            etUserInput.addTextChangedListener(new PhoneticRetriever());
        }
    }
    

    このサンプルコードでは、afterTextChanged() のコールバックで TtsSpan を取得しています。TtsSpan.ARG_TEXT がよみがなで、getSpanStart()getSpanEnd() を利用すれば、入力された CharSequence の中で取得したよみがなの位置を取得することができます。

    実行可能なコードはこちらのレポジトリをご参照ください。
     → https://github.com/googlesamples/gboard-dev-samples/tree/main/GetIMEPhoneticName

    同じコードを使ったサンプルアプリケーションを Play Store からインストールすることも可能です。
     → https://play.google.com/store/apps/details?id=com.ragingsamples.getimephoneticname

    Google コンタクト アプリ(v3.37 以降)では、連絡先を編集する際、この API を使って漢字名に該当するよみがなが自動入力されます。自動入力の結果が誤っている場合でも、ユーザーは手動でよみがなを直すことができます。

    Figure 4: Google コンタクト アプリのよみがな推測

    この API を利用して取得したよみがなの使い道はみなさんの作るアプリ次第ですが、いくつか参考になるユースケースをご紹介します:
    • ユーザーの入力した名前から自動的によみがなを推測する。2021 年 5 月現在、この API は 名前にのみ対応しているため、ショッピング アプリや銀行アプリ、カスタム CRM アプリ、 SNS アプリなどで利用することができます。
    • 他の IME が Gboard と同じ API を提供することで、より多くのユーザーによみがなのサポートを提供する。

    ほかのユースケースのご提案、名前以外に将来的にサポートして欲しい入力タイプ、改善点などありましたら、ぜひフィードバックをお願いします。


    Posted by Alex Gimenez - Technical Solutions Consultant
    Share on Twitter Share on Facebook

    モバイル デバイスのセキュリティ評価は難しく、信頼できる方法で企業のクレイムを検証するには、独立した業界の認証(Certification)によるものである必要があります。スマートフォンの場合、特に確実なエンドツーエンドの認証(Certification)に Common Criteria(CC)Mobile Device Fundamentals(MDF)Protection Profile があります。Common Criteria は、31 か国に広がる大規模なセキュア IT プロダクトの相互認証(mutual recognition)を確立する原動力です。ここ数年間、すべての OS のバージョンで継続的に認証(Certification)を受けているスマートフォン メーカーは、Google、Samsung、Apple の 3 社のみです。2 月初頭には、現在サポート対象で、Android 11 を実行する Pixel スマートフォンのすべての認証(Certification)が完了しました。Google は、最新の OS バージョンで認証(Certification)を受けた最初のメーカーです。

    この認証(Certification)は、コンシューマや企業が直面する現実の脅威に対するデバイスの防御力を評価するために設計されています。次の表は、CC MDF 保護プロファイルに示されている脅威と対策の概要です。

    脅威

    対策

    ネットワークの盗聴 - 攻撃者がワイヤレス通信チャンネルなどのネットワーク インフラストラクチャ上に存在する

    ネットワーク攻撃 - 攻撃者がワイヤレス通信チャンネルなどのネットワーク インフラストラクチャ上に存在する

    通信の保護 - 安全な暗号化通信を保証する IPsec、DTLS、TLS、HTTPS、Bluetooth などの標準プロトコル

    認可と認証 - ネットワークやバックエンドの安全な認証(Authentication)

    モバイル デバイス設定 - ユーザーや企業の管理者が定義するセキュリティ ポリシーを設定して適用する機能

    物理アクセス - 物理アクセス可能な攻撃者は、モバイル デバイスから認証情報を含むユーザーデータの取得を試みる可能性がある

    ストレージの保護 - デバイスに含まれるデータを安全に保存(すなわち、保存データの暗号化) 

    認可と認証 - パスワード、PIN、指紋、顔認証など、既知のロック解除要素を利用した安全なデバイス認証(Authentication)

    悪意や欠陥のあるアプリケーション - モバイル デバイスに読み込まれたアプリケーションに、悪意のあるコードや悪用可能なコードが含まれる可能性がある 

    通信の保護 - 安全な暗号化通信を保証する IPsec、DTLS、TLS、HTTPS、Bluetooth などの標準プロトコル

    認可と認証 - ネットワークやバックエンドの安全な認証(Authentication)

    モバイル デバイス設定 - ユーザーや企業の管理者が定義するセキュリティ ポリシーを設定して適用する機能

    モバイル デバイスの整合性 - ソフトウェア、ハードウェアの両方における重要な機能のデバイスの整合性

    エンドユーザー プライバシーとデバイスの機能 - アプリケーション分離やサンドボックス化、フレームワーク アクセス許可により、ユーザー アクティビティごとの分離やプライバシーを提供

    恒常的な存在 - 攻撃者がデバイスに恒常的に存在する場合、デバイスは整合性を失い、それを取り戻せないことを意味する 

    モバイル デバイスの整合性 - ソフトウェア、ハードウェア両方における重要な機能の整合性を保証するためのデバイスの整合性が保たれている

    エンドユーザー プライバシーとデバイスの機能 - アプリケーション分離やサンドボックス化、フレームワーク アクセス許可により、ユーザー アクティビティごとの分離やプライバシーを提供


    この認証(Certification)が重要なのは、認定を受けたラボが実際にデバイスを評価し、さまざまなテストをして以下を確認しているためです。

    1. すべての対策があらかじめ定義された標準や基準を満たしている。
    2. すべての対策が公表されているとおりに機能する。

    概念的には、評価対象(TOE)はデバイスのハードウェア(システム オン チップ)とオペレーティング システム(Android)の組み合わせです。上記の脅威に対する対策を検証するため、ラボは以下のセキュリティ機能を確認します。

    これが企業にとって重要な理由

    Pixel のセキュリティが企業のニーズを確実にサポートできることは、非常に重要です。規制が厳しい業界の多くでは、機密データが考えられる限り最も強固な保護を受けられるように、Common Criteria 認証(Certified)デバイスの利用が義務付けられています。Android Enterprise 管理フレームワークでは、企業がデバイスの管理などをし、エンドユーザーが実行できる操作を制限したり、デバイスを監査してすべてのソフトウェアが適切に設定されていることを保証したりできます。たとえば、企業の IT 管理者は、カメラ、位置情報サービス、アプリのインストール プロセスなどの機能に対するポリシーを強制できます。

    これがコンシューマにとって重要な理由

    セキュリティは企業だけが心配することではありません。Common Criteria 認証(Certification)で検証している多くの保護は、コンシューマにも適用されます。たとえば、Wi-Fi に接続するとき、ウェブのブラウズを誰にも盗聴されないことを確認したいと思うでしょう。デバイスの紛失や盗難の際は、ロック画面によって他人が個人情報にアクセスする可能性が減ると確信したいはずです。

    Google は、すべてのユーザーにセキュリティとプライバシーをお届けしたいと考えています。Pixel デバイスがこの認証(Certification)基準以上を確実に満たせるようにしたいと考えているのはそのためです。今後もこの基準を満たすために注力しますので、どうぞご安心ください。Pixel スマートフォンでは、スイッチを入れた瞬間から充実したセキュリティを利用できます。

    これが Android エコシステムにとって重要な理由

    認証(Certification)はサードパーティによる検証として有用な形態ですが、以下の、Google が 3 C と呼ぶものに該当することがよくあります。

    • Complex(複雑) - デバイスのハードウェア、オペレーティング システム、その間にあるものすべてを含む評価スコープであるため。
    • Costly(高価) - すべての形式とモデルの組み合わせ(SoC + OS)について、認定を受けたラボで実際に評価作業をする必要があり、個々のテストは数百件にのぼるため。
    • Cumbersome(厄介) - かなり長い評価手続きで、初回は最長で 18 か月を要するため。

    ここ 3 年間は、OEM パートナーを対象に、この複雑さを軽減するための作業をしてきました。その結果、必要なセキュリティ要件を満たすために要求される機能が Android オープンソース プロジェクトに直接組み込まれることをお知らせします。さらに、すべての管理要件と監査要件を Android Enterprise Management フレームワークに追加しました。昨年は、このために開発したツールを GitHub に公開しました。他の Android OEM が認証(Certification)を受ける際に、この作業のメリットを活用できるようにするためです。

    新しい Android OS バージョンでの Pixel スマートフォンの認証(Certification)は継続しますが、Google はその他の Android OEM も、この認証(Certification)や、以下のその他の認証(Certification)を取得できるように取り組んでいます。

    • アメリカ国立標準技術研究所の Cryptographic Algorithm と Module Validation Programs。これは暗号アルゴリズムとモジュールの評価で、アメリカの公共部門やその他多くの規制のある業界で求められています。Android 11 では、Conscrypt の主要モジュールである BoringSSL がこの検証を終えています(認定番号 3753)。
    • アメリカ国防総省の Security Technical Implementation Guide(略称 STIG)。アメリカ国防総省のネットワークに技術を導入する方法をまとめたガイドラインです。かつては Android OEM に独自の実装や制御があったので、それによって異なる STIG が存在していましたが、Google の作業の成果によって、現在は 1 つの Android STIG テンプレートに統合されています。そのため、Android OEM は、さまざまな要件を満たすために独自の制御を作成する手間をかけずに済みます。

    今後も、企業とコンシューマの両方を対象にしたセキュリティ対策に注力してまいります。業界の皆さんがこの作業に加わってくれることを歓迎いたします。


    Reviewed by Eiji Kitamura - Developer Relations Team
    Share on Twitter Share on Facebook

    Android デバイスで Autofill with Google を有効にする方法は次のとおりです

    1. スマートフォンの [ 設定 ] アプリを開く
    2. [ システム ] > [ 言語と入力 ] > [ 詳細設定 ] をタップする
    3. [ 自動入力サービス ] をタップする
    4. [ Google 自動入力サービス ] をタップして設定を有効化する

    項目が見つからない場合は、こちらのページをご覧ください。デバイス メーカーから詳しい情報を得る方法が記載されています。

    動作の仕組み

    Google はユーザーのプライバシーを最優先に考えていますが、パスワードなどの機密データを扱う機能では特にそれを重視しています。Google 自動入力は Android の自動入力フレームワークがベースになっています。このフレームワークは、厳格かつ不変なプライバシーとセキュリティを遵守し、次の 2 つの場合にのみユーザーの認証情報にアクセスすることを保証します。1)ユーザーが Google アカウントに認証情報をすでに保存している場合。2)Android OS がユーザーに新しい認証情報を保存することを提案し、ユーザーがアカウントに認証情報を保存した場合。

    ユーザーが認証情報を操作したとき(フォームに認証情報を入力する、または初めて保存するとき)、Chrome で使われているものと同じプライバシー保護 API を使い、Google が追跡している既知の侵害されたパスワードのリストにその認証情報が含まれていないかを確認します。

    この実装では、以下の点が保証されています。

    この API の内部処理の詳細については、Chrome チームによるこちらのブログをご覧ください。

    その他のセキュリティ機能

    Google 自動入力は、Password Checkup の他にも、データの保護に役立つ機能を提供します。

    いつものように、プロダクト全般のセキュリティ向上に関する最新情報をお届けする Google Security ブログにご注目ください。


    Reviewed by Eiji Kitamura - Developer Relations Team
    Share on Twitter Share on Facebook


    注意事項: これは Chrome の動作の変更です。他のブラウザにも同様の機能が追加されることを期待しています。


    アプリで共有アイコンを表示しないようにする方法

    androidx.browser バージョン 1.3.0 以降では、CustomTabsIntent.BuildersetShareState() メソッドを使ってデフォルトの共有を無効にすることができます。

    val customTabsIntent = CustomTabsIntent.Builder()

            .setShareState(CustomTabsIntent.SHARE_STATE_OFF)

            .build();


    この変更の一環として、CustomTabsIntent.Builder の addDefaultShareMenuItem() メソッドと setDefaultShareMenuItemEnabled() メソッドは非推奨となっています。代わりに setShareState() を使うようにしてください。

    アプリでカスタムタブを使っている方は、ぜひフィードバックをお寄せください。こちらのフォームから連絡することができます。



    Reviewed by Eiji Kitamura - Developer Relations Team
    Share on Twitter Share on Facebook