[この記事は Jason Douglas、Actions on Google 担当 PM ディレクターによる Google Developers Blog の記事 "Start building Actions on Google" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]
Google Assistant は、ナレッジグラフから自然言語処理に至るまで、長年積み上げてきたテクノロジーや知能を統合したものです。Assistant を効果的に活用するには、ユーザーの生活の中でさまざまなアプリやサービスをつなげることが必要になります。そのためには、デベロッパーが Google Assistant を通して多種多様なサービスをユーザーに提供するためのエコシステムを構築することがとても重要だと考えています。
10 月には、Google Assistant のデベロッパー プラットフォームである Actions on Google のプレビュー版を公開しました。Actions on Googleを使うと、Assistant に独自のサービスを追加できるため、Assistant のユーザー体験をさらに向上させることができます。本日(*原文公開当時)より、Google ホームの会話アクションが開発できるようになりました。さらに、プラットフォームへのフィードバックを行う事が可能な、アーリーアクセスパートナーへの申し込みフォームも公開しました。
Google Home の会話アクション
会話アクションを活用すると、ユーザーに情報、サービス、サポートを提供できます。特徴的な部分としては、会話アクションを通じて本当に Assistant と会話ができることです。ユーザーには特殊な技術や、アプリをインストールする必要もありません。ただ話しかければよいだけです。現在、デベロッパーを対象に、何が実現可能かを説明する 2 つのサンプルが提供されています。「Ok Google, talk to Number Genie」と話しかけると、数当てゲームができます。または、「Ok Google, talk to Eliza」と話しかけると、1960 年代の傑作 AI と会話できます。
デベロッパー向けの Actions on Google ウェブサイトにアクセスすると、すぐに開発を始めることができます。スムーズで直感的な開発を実現するため、Google は会話インタラクション開発ツールの API.AI や Gupshup、アナリティクス ツールの DashBot や VoiceLabs、コンサルティング会社の Assist、Notify.IO、Witlingo、Spoken Layer など、さまざまな開発パートナーと連携してきました。また、一連のサンプルや音声ユーザー インターフェース(VUI)リソースも作成しています。今後数週間でリリースされる予定のアーリーアクセス パートナーによる統合アプリを試すこともできます。
この取り組みはまだ始まったばかりで、みなさんが開発される Google Assistant 向けアプリを見るのを楽しみにしています。今後も、プラットフォーム機能の追加は継続され、Pixel スマートフォンや Google Allo など、各種アシスタントで利用できる統合アプリを作れるようになります。購入や予約にも対応するだけでなく、業界を問わず、複雑なアシスタントとも連携していく予定です。今後公開されるこのような機能を利用してアクションを作ってみたいデベロッパーのみなさんは、ぜひアーリーアクセス パートナー プログラムに登録してください。ともにこのプラットフォームの将来を作り上げてゆきましょう。 さまざまな開発を試して、Actions on Google を使ってみた感想をお聞かせください。最新情報を入手するには、ニュースレターに登録し、Google+ コミュニティに参加してください。StackOverflowでの質問には、「actions-on-google」タグをご利用ください。
プレゼンテーションで、オーディエンスにアイデアを伝えるために写真や画像を使うのは常識です。そのため、優れたプレゼンテーションを作成するベスト プラクティスの 1 つは、全体的にテキストをなるべく少なくすることです。つまり、プレゼンテーションにテキストを 入れるなら、(わずかに)使うテキストは印象的 かつ視覚的にも美しいものでなければなりません。ソフトウェア アプリケーション、たとえば Google Slides APIで生成されるスライドであれば、手で作るスライドよりもなおさらそれが重要になります。
先日、G Suite チームは Slides API の初版をリリースし、まったく新しいカテゴリのアプリケーションへの扉を開きました。それ以降、この API の持つ可能性をみなさんに実現していたくため、スライドのテキストや画像を置き換える方法やスプレッドシートのデータからスライドを生成する方法など、いくつかの動画を公開しています。今回は、主要 API の 3 つの使用例の最後となる、テキストの書式設定についてお伝えしましょう。
Google スライド内のテキストは、API リクエストを送信して操作できます。Google Sheets APIと同じく、リクエストは JSON ペイロード形式で API の batchUpdate()メソッドに送信します。次に示すのは、スライド内のある図形(shapeID)の中にテキストを挿入する JavaScript です。
Google スライドのテキストの構造やスタイル設定について理解を深めたい方は、ドキュメントのテキスト コンセプト ガイドをご覧ください。DevByte で取り上げたコードサンプルの 全容については、さらに詳しく取り上げている投稿をご覧ください。一般的な API の操作の他のサンプルは、こちらのページをご覧ください。これらの動画やデベロッパー リソースが次のすばらしいアプリの作成に役立つことを願っています。ぜひ、ユーザーのために印象的なプレゼンテーションの作成を自動化するアプリを作ってみてください。
まず、JPEG および RAW イメージ(具体的には、DNG、CR2、NEF、NRW、ARW、RW2、ORF、PEF、SRW、RAF の各ファイル)の Exif データを読み取ることができます。これには、大きな内部的変更が伴いました。すべてのネイティブの依存性を排除し、実際にすべてが動作することを確認するために大規模なテストを行う必要があったためです。
他のアプリから content:// URI(ターゲット API 24 以上のアプリから送信されるものなど)経由でイメージを受信するアプリでは、直接 InputStreamから ExifInterfaceを使えるようになっています。これによって、受信した content:// URI から Exif 情報を簡単に直接抽出でき、一時ファイルを作成する必要がなくなります。
Uri uri; // the URI you've received from the other app InputStream in; try { in = getContentResolver().openInputStream(uri); ExifInterface exifInterface = new ExifInterface(in); // Now you can extract any Exif tag you want // Assuming the image is a JPEG or supported raw format } catch (IOException e) { // Handle any errors } finally { if (in != null) { try { in.close(); } catch (IOException ignored) {} } }
注: ExifInterfaceは、HttpURLConnectionから返されるようなリモートの InputStreamでは動作しません。content://または file:// URI に対してのみ使用することを強くお勧めします。
Internet of Things(IoT)は、まったく新しい分野のデバイスにコンピューティングをもたらします。本日(*原文公開当時)は、Google の IoT デベロッパー プラットフォームの 2 つの重要なアップデートについてお知らせします。このアップデートによって、ネットワークに接続されたスマートな製品を今まで以上に短時間で簡単に作れるようになります。
現在、Android Things の Developer Preview 版が公開されています。Android Things は、IoT 製品を作成する総合的な手法で、世界有数のサポート数を誇るオペレーティング システムである Android を活用しています。これによって、Android デベロッパーは、Android API や Google のサービスを利用してスマート デバイスを短時間で構築できるようになります。アップデートは Google から直接提供されるので、高いセキュリティを確保できます。Project Brillo に寄せられたフィードバックを取り入れているため、Android Studio、Android Software Development Kit(SDK)、Google Play サービス、Google Cloud Platform などのおなじみのツールも含まれています。数か月後には、Developer Preview のアップデートを提供し、定期的な OS パッチ、セキュリティの修正、そして皆さんのアップデートを安全にプッシュできるインフラを実現する予定です。それと同時に、ビルトインの Weave 接続なども提供されます。
現在、Android Things を搭載した実際の製品の構築を始めるにあたって、すぐに使えるハードウェア ソリューションも存在しています。たとえば、Intel Edison、NXP Pico、Raspberry Pi 3 などです。こういったカスタム デザインのソリューションを使うと、Google の同じ Board Support Package(BSP)を使用しつつ、大規模な本番環境で容易に稼働させることもできます。
Android スマートフォン、iPhone の両方のユーザーがシームレスな認証を行えるように、OAuth やワンクリック Google ログインのサポートが追加された API が新たに作成されました。Android Wear 向けの OAuth API を使うと、ユーザーが時計のボタンをタップしてスマートフォンの認証画面を開き、ウォッチアプリから直接サーバーサイドの API で認証できるようになります。Google ログインを使うと、この操作がさらに簡単になり、どのアカウントで認証するかを選択するだけで、ユーザーの認証が完了します。
スタンドアロンで動作しないウォッチアプリもあります。また、時計とスマートフォンの両方のアプリがインストールされている場合に、よりよいユーザー エクスペリエンスを提供できることもあります。Google は皆さんのフィードバックを入念にチェックし、ペア設定された端末で Play Store を開いてユーザーが簡単にアプリをインストールできるように、2 つの新しい API(PlayStoreAvailabilityと RemoteIntent)を追加しています。また、新しく追加された RemoteIntent API を使い、時計から操作してスマートフォンでカスタム URL を開くことができます。この操作には、追加のスマートフォン アプリやデータレイヤーは不要です。
// Check Play Store is available int playStoreAvailabilityOnPhone = PlayStoreAvailability.getPlayStoreAvailabilityOnPhone(getApplicationContext());
if (playStoreAvailabilityOnPhone == PlayStoreAvailability.PLAY_STORE_ON_PHONE_AVAILABLE) { // To launch a web URL, setData to Uri.parse("https://g.co/wearpreview") Intent intent = new Intent(Intent.ACTION_VIEW) .addCategory(Intent.CATEGORY_BROWSABLE) .setData(Uri.parse("market://details?id=com.google.android.wearable.app")); // mResultReceiver is optional; it can be null. RemoteIntent.startRemoteActivity(this, intent, mResultReceiver); }
スワイプで閉じる動作の復活
Android Wear 1.0 のスワイプで閉じる操作は、直感的で時間の節約になるという多くのフィードバックをいただきました。そこで、今回の Developer Preview リリースでは、以前の動作を復活させています。このリリースでスワイプで閉じる操作をサポートするために、次のプラットフォームと API の変更を行っています。
11 月に、Google Sign-In API のアップデートについてお知らせしました。現在、Play ゲームサービスでは、認証に Google Sign-In API を使用するよう変更するアップデート作業が行われています。この変更によって、次のようなメリットが生まれます。
ゲームとログインの両方を同じクライアント接続で実行できる
1 つの API でバックエンド サーバーに送る認証コードを取得できる
この変更により、Google ログインと Games API のログインが統合され、Google API クライアントの作成方法も次のようにアップデートされます。
// Defaults to Games Lite scope, no server component GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_GAMES_SIGN_IN).build();
// OR for apps with a server component GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_GAMES_SIGN_IN) .requestServerAuthCode(SERVER_CLIENT_ID) .build();
// OR for developers who need real user Identity GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_GAMES_SIGN_IN) .requestEmail() .build();
// Build the api client. mApiClient = new GoogleApiClient.Builder(this) .addApi(Games.API) .addApi(Auth.GOOGLE_SIGN_IN_API, gso) .addConnectionCallbacks(this) .build(); }
@Override public void onConnected(Bundle connectionHint) { if (mApiClient.hasConnectedApi(Games.API)) { Auth.GoogleSignInApi.silentSignIn(mApiClient).setResultCallback( new ResultCallback() { @Override public void onResult(GoogleSignInResult googleSignInResult) { // In this case, we are sure the result is a success. GoogleSignInAccount acct = googleSignInResult.getGoogleSignInAccount());
// For Games with a server, send the auth code to your server. String serverAuthCode = signInAccount.getServerAuthCode();
// Use the API client as normal. Player player = Games.API.getCurrentPlayer(mApiClient); } } ); } else { onSignedOut(); } }
アップグレードした以前の Firebase.com プロジェクトと既存の Google API プロジェクトを共存させる
別の Google API プロジェクトのサービスを使いつつ、以前の Firebase.com データベースを新しい Firebase プロジェクトにアップグレードしたい場合に発生する 1 つのシナリオがあります。アップグレードした以前のプロジェクトは、新しい Firebase プロジェクトになります。しかし、そのプロジェクトは既存ユーザーに Google Sign-In の認証を提供する Google API プロジェクトと併せて使う必要があります。
ここで問題になるのは、Android アプリで Google Sign-In を動作させるには、そのアプリの SHA-1(APK の署名に使用するキーのフィンガープリント)とパッケージ名(com.foo.bar など)を登録する必要があることです。Google Sign-In は、このペアによって特定のアプリがどの Google API プロジェクトを使っているか判断します。ある SHA1 とパッケージ名のペアは Google(と Firebase プロジェクト)内でグローバルに一意であるため、アップグレードした以前の Firebase プロジェクトに同じ SHA-1 とパッケージ名のペアを追加しようとすると、OAuth2 クライアントがすでに(Google API プロジェクト内に)存在するという次のエラーが発生します。
警告: このエラーが表示されても、本番環境のアプリの既存クライアント ID は削除しないでください。削除してしまうと、既存ユーザーがアプリを利用できなくなります。正しい対応は、Firebase コンソールでアップグレードしたプロジェクトの中に同じパッケージ名の新しいアプリを作成することであり、その際に SHA1 を 空のまま で登録します。 あとは、通常どおりに Firebase Auth を使った Google Sign-In を実装します。ある時点で、次のようにして GoogleSignOptions オブジェクトを設定することになります。
GoogleSignInOptions gso = new GoogleSignInOptions.Builder(GoogleSignInOptions.DEFAULT_SIGN_IN) .requestIdToken(getString(R.string.default_web_client_id)) .requestEmail() .build();
ここで、 default_web_client_id文字列は、ID トークンの audienceフィールドを設定するために使われています。この値は google-services.json ファイルから取得されており、Google プロジェクトではなく Firebase プロジェクトに紐付きます。この値を Google API プロジェクトのクライアント ID と置き換える必要があります。任意のウェブ クライアント ID を使うことも、次のようにして新しい ID を作ることもできます。
次に、Firebase プロジェクトに戻り、先ほど GoogleSignInOptionsに設定したクライアント ID をホワイトリストに登録します。この操作は、Firebase コンソールの Auth > Sign In Providers > Googleセクションから行います。
忘れずに google-services.jsonファイルをダウンロードし直し、Android アプリに追加してください。この時点で、Firebase プロジェクトは Google API プロジェクトで生成された Google ID トークンでも利用できるようになります。そのため、Android アプリは Google API プロジェクトを使って問題なく Google Sign-In でログインできます。そして、通常のアプローチに従い、Google API プロジェクトに紐付けた Google ID トークンを使って Firebase プロジェクトに対する認証を行います。これによって、Google API プロジェクトに関連づけられている Google API に対する認証情報付きの API 呼び出しや、Firebase プロジェクトを使った Firebase API に対する認証情報付きの API 呼び出しができるようになります。
2 つの Firebase プロジェクトのデータベースにアクセスする
先ほどの例は、1 つの Firebase プロジェクトから別の Google API プロジェクトにアクセスする必要がある場合でした。この方法は、API が分かれているためうまく動作します。しかし、同じ Firebase API を経由し、複数のデータベース インスタンスなど、別のプロジェクトにアクセスしなければならないこともあるでしょう。
FirebaseOptions options = new FirebaseOptions.Builder() .setApplicationId("1:530266078999:android:481c4ecf3253701e") // Required for Analytics. .setApiKey("AIzaSyBRxOyIj5dJkKgAVPXRLYFkdZwh2Xxq51k") // Required for Auth. .setDatabaseUrl("https://project-1765055333176374514.firebaseio.com/") // Required for RTDB. .build(); FirebaseApp.initializeApp(this /* Context */, options, "secondary");
これで、同じクライアント API を使ってデータベースにアクセスできるようになります。ただし、この場合、対象の FirebaseAppを FirebaseDatabase.getInstance()に渡し、どのプロジェクトにアクセスするかを明示します。
// Retrieve my other app. FirebaseApp app = FirebaseApp.getInstance("secondary"); // Get the database for the other app. FirebaseDatabase secondaryDatabase = FirebaseDatabase.getInstance(app);
2 つの Firebase Database に対して認証を行う
以上で説明した 2 つのテクニックを組み合わせると、結合する外部 ID さえあれば、複数の Firebase プロジェクト間で認証データを共有できます。
たとえば、Google Sign-In を使ってログインできるアプリがあり、デフォルトとセカンダリのプロジェクトの両方で認証が必要となるデータベース ルールが設定されている場合、同じ Google 資格情報を使って両方のシステムにログインできます。
まず、アプリでデフォルトのプロジェクトの Google Sign-In を通常どおりにセットアップします。次に、デフォルトのプロジェクトからベースとなるクライアント ID を取得します。クライアント ID は、アプリのクライアント(ウェブ、Android、iOS)の単なる識別子で、通常はクライアントの中に含まれています。プロジェクトには複数のクライアント ID を持たせることもできますが、ホワイトリストに登録する必要があるのは、GoogleSignInOptions のビルダーの requestIdToken を呼び出す際に指定するものです。
function initialize() { macaddress.one('wlan0', function (err, mac) { mac_address = mac; if (mac === null) { console.log('exiting due to null mac Address'); process.exit(1); } firebase.initializeApp({ serviceAccount: '/node_app_slot/<service-account-key>.json', databaseURL: 'https://<project-id>.firebaseio.com/' }); var db = firebase.database(); ref_samples = db.ref('/samples'); locationSample(); }); }
Java Client for Google Maps Servicesは Google Maps API を利用する際に必要な大量の通信コードを扱い、エラー処理について公開されているベスト プラクティスおよびレート制限に従ったリトライ方針に従います。次に示す GeolocateWifiSample() 関数は、イベント リスナーとしてFirebase に登録されています。この関数はデバイスから報告される各ネットワークをループし、それをジオロケーション リクエストに組み込みます。
private void GeolocateWifiSample(DataSnapshot sample, Firebase db_geolocations, Firebase db_errors) { // initalize the context and request GeoApiContext context = new GeoApiContext(new GaeRequestHandler()).setApiKey(""); GeolocationApiRequest request = GeolocationApi.newRequest(context) .ConsiderIp(false); // for every network that was reported in this sample... for (DataSnapshot wap : sample.child("networks").getChildren()) { // extract the network data from the database so it’s easier to work with String wapMac = wap.child("address").getValue(String.class); int wapSignalToNoise = wap.child("quality").getValue(int.class); int wapStrength = wap.child("signal").getValue(int.class); // include this network in our request request.AddWifiAccessPoint(new WifiAccessPoint.WifiAccessPointBuilder() .MacAddress(wapMac) .SignalStrength(wapStrength) .SignalToNoiseRatio(wapSignalToNoise) .createWifiAccessPoint()); } ... try { // call the api GeolocationResult result = request.CreatePayload().await(); ... // write results to the database and remove the original sample } catch (final NotFoundException e) { ... } catch (final Throwable e) { ... } }
// this import should be first in order to load some required settings (like globals and reflect-metadata) import { platformNativeScriptDynamic } from "nativescript-angular/platform";
import { AppModule } from "./app.module"; import { BackendService } from "./services/backend.service";
handleSnapshot(data: any) { //empty array, then refill and filter this._allItems = []; if (data) { for (let id in data) { let result = (Object).assign({id: id}, data[id]); if(BackendService.token === result.UID){ this._allItems.push(result); } } this.publishUpdates(); } return this._allItems; }
[この記事は Huibao Lin、Eyal Peled、Google ソフトウェア エンジニアによる Google Developers Blog の記事 "Google AMP Cache, AMP Lite, and the need for speed" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。] Google は、基本方針として高速なサービスの設計を追求しています。Accelerated Mobile Pages(AMP)形式を使うと、コンテンツを確実かつ高速に読み込むことができますが、これだけではありません。
Google 検索や Google ニュースと天気などでは、ほぼ瞬時にユーザーに画面が表示される AMP が使われています。その鍵となる技術のひとつがスマート キャッシュです。一般的に、キャッシュを活用すると、コンテンツとそれをリクエストするユーザーを物理的に近づけることができ、コンテンツのデータがユーザーのもとに届くまでに移動する距離が短くなります。さらに、キャッシュのような単一の共通インフラを使うことで、ページの提供時間の一貫性が高まります。一方、多くのホストから配信されるコンテンツは、キャッシュに比べるとコンテンツを提供するレイテンシが大幅に異なり、かなり長くなります。
この記事は Aditya Tendulkar、Google マイビジネス プロダクト マネージャーによる Google Geo Developers Blog の記事 "Google Geo Developers Blog: Introducing insights in the Google My Business API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 Google My Business API の営業拠点・店舗分析機能を紹介します。これは、サードパーティのアプリケーション デベロッパーや大規模な多拠点ブランドが、検索数や閲覧数、ユーザーのアクション数の合計を求めるなどの営業拠点・店舗に関する分析をプログラムから簡単に行う機能です。ビジネス オーナーはこうした情報を追跡し、分析することによって、ユーザーが Google のサービスを使って、どこでどのようにして、営業拠点や店舗を見つけたのかを把握できます。
デベロッパーは Google My Business API を使って、各店舗の場所に関する最大 18 か月分のデータをリクエストし、それを分析して実用的な形で集計や視覚化を行うアプリケーションを構築できます。たとえば、数百の店舗を抱えるコーヒー ショップであれば、ユーザーの閲覧数、店舗へのルート 検索のクリック回数、電話の回数などの傾向を容易に把握し、店舗間で比較することができます。この分析結果は、店舗間のリソース割り当ての改善やマーケティング効果の追跡に活用できます。
この新しい API は、Google マイビジネス ダッシュボードの機能を皆さんのデータ アナリティクス ツールから使えるようにするものです。次の図に示すようにウェブ インターフェースを利用するユーザーは、直近 90 日の Google マイビジネス情報からグラフを生成できます。
サンプルデータは、Google マイビジネス ウェブ ダッシュボードから参照可能
このデータは API からも利用できます。最新の ドキュメントをご覧いただければ、この API を簡単に試してみることができます。次に示す簡単な HTML リクエストでは、Google 検索と Google マップで実行された、ビジネスリスティングの検索結果の数を取得します。
この新機能によって、Google My Business API ユーザーは、顧客が Google のサービスを使って、どのように営業拠点・店舗を検索しているのか、さらにはその場所を見つけた後にどのようなアクションをとっているのかを理解した上で、ユーザーのアクションを引き起こす最適なビジネスリスティングを得ることができます。このような分析は、Google マイビジネス ウェブやモバイルでも利用できるため、場所を問わずに重要なトレンドを把握することができます。
2017 年は、Cloudflare のネットワーク トラフィックの半分以上がモバイル端末からのものになると予測しています。モバイルウェブは、小さな画面に表示できる形式になっているとはいえ、従来のウェブのプロトコルや技術を使って PC の CPU やネットワーク接続、画面向けに構築されたものです。そのため、モバイルウェブのブラウジングは、ネイティブのモバイルアプリに比べると低速に感じられます。
ブランドに合わせたユーザー エクスペリエンスを提供したい大規模なサイトオーナーに対しては、サイトオーナーのドメインに一致するようにビューアーのドメインをカスタマイズできる機能を提供する予定です。訪問者を Google のドメインにリダイレクトせずに AMP コンテンツを表示するシームレスな操作が初めて実現しました。Accelerated Mobile Links ビューアーのカスタマイズに興味を持っている大規模なサイトオーナーの皆様は、Cloudflare チームにご連絡ください。
AMP の革新
AMP の初代チャンピオンは Google ですが、AMP 関連技術はオープンです。私たちは、Cloudflare の Accelerated Mobile Links や独自の AMP キャッシュの開発にあたり、Google チームと密接に連携してきました。Google で AMP プロジェクトのテクニカル リードを務める Malte Ubl 氏は、私たちとの協業について次のように話しています。
この記事は Megan Ruthven、ソフトウェア エンジニアによる Android Developers Blog の記事 "Silence speaks louder than words when finding malware | Android Developers Blog" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。 Android セキュリティ チームでは、端末をさらに安全かつスムーズに操作できるようにする方法を模索しています。Google Play を利用する全端末を対象としたセキュリティ ソリューションの 1 つがアプリの確認です。アプリの確認では、端末上に有害な可能性があるアプリ(Potentially Harmful App、PHA)がないかどうかを確認します。PHA が見つかった場合、アプリの確認で警告を表示し、ユーザーがそのアプリをアンインストールできるようにします。
しかし、アプリの確認が行われない端末もあります。新しいスマートフォンを買った場合などセキュリティとは関係ない理由でそうなることもあれば、心配すべきことが起きていることもあります。アプリの確認が行われない場合、その端末は利用不能または安全ではない(Dead or Insecure、DOI)と見なされます。あるアプリをダウンロードした端末が高確率で DOI 端末となった場合、そのアプリは DOI アプリと見なされます。私たちは Android ユーザーを保護するため、アプリが PHA かどうかを DOI 指標などのセキュリティ システムから判断しています。また脆弱性を発見した際には、セキュリティ アップデート システムを使って Android 端末にパッチを適用しています。
そこで、端末の継続利用率はすべてのアプリで同じになるはずという前提のもと、アプリの DOI スコアラーを利用します。あるアプリの継続利用率が平均よりも低い標準偏差を示す場合、DOI スコアラーはそのアプリにフラグを立てます。平均から標準偏差の数値を計算する一般的な方法に、Z スコアがあります。Z スコアの方程式を次に示します。
N = アプリをダウンロードした端末数
x = アプリをダウンロードした継続利用中の端末数
p = 何らかのアプリをダウンロードした端末の継続利用率
ここで、アプリの継続利用率の Z スコアを DOI スコアと呼びます。Z スコアが -3.7 より低い場合、DOI スコアはそのアプリが統計的に著しく低い継続利用率であるという指標になります。つまり、帰無仮説を真とする場合、Z スコアの大きさがそこまで大きくなる確率は 0.01% 以下しかありません。この場合の帰無仮説とは、アプリが低い継続利用率を示すのは、アプリの動作とは関係なく偶然であるということです。
これによって、極端な値(継続利用率が低くダウンロード数が多い)を示すアプリが DOI リストのトップに現れることになります。そこから DOI スコアと他の情報を組み合わせて、アプリを PHA に分類するかどうかを判断します。次に、アプリの確認を使用してインストール済みのアプリを削除し、今後はそのアプリがインストールされないようにします。
まず、注文管理を Google Payments Center から Google Play Developer Console に移動し、いくつかの機能を改善しています。課金設定は、引き続き payments.google.com からも利用できますが、Developer Console からもアクセスできるようになります。新機能には適切なアクセス制御を設定できるため、必要なツールへのアクセス権のみをユーザーに与えることができます。
Google Play Developer Console の新しい注文管理タブ 今まで Google Payments Center で行っていたタスクは、Developer Console から実行できます。さらに、いくつかの改善も行っています。