まず、注文管理を Google Payments Center から Google Play Developer Console に移動し、いくつかの機能を改善しています。課金設定は、引き続き payments.google.com からも利用できますが、Developer Console からもアクセスできるようになります。新機能には適切なアクセス制御を設定できるため、必要なツールへのアクセス権のみをユーザーに与えることができます。
Google Play Developer Console の新しい注文管理タブ 今まで Google Payments Center で行っていたタスクは、Developer Console から実行できます。さらに、いくつかの改善も行っています。
この記事は 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 に分類するかどうかを判断します。次に、アプリの確認を使用してインストール済みのアプリを削除し、今後はそのアプリがインストールされないようにします。
2017 年は、Cloudflare のネットワーク トラフィックの半分以上がモバイル端末からのものになると予測しています。モバイルウェブは、小さな画面に表示できる形式になっているとはいえ、従来のウェブのプロトコルや技術を使って PC の CPU やネットワーク接続、画面向けに構築されたものです。そのため、モバイルウェブのブラウジングは、ネイティブのモバイルアプリに比べると低速に感じられます。
ブランドに合わせたユーザー エクスペリエンスを提供したい大規模なサイトオーナーに対しては、サイトオーナーのドメインに一致するようにビューアーのドメインをカスタマイズできる機能を提供する予定です。訪問者を Google のドメインにリダイレクトせずに AMP コンテンツを表示するシームレスな操作が初めて実現しました。Accelerated Mobile Links ビューアーのカスタマイズに興味を持っている大規模なサイトオーナーの皆様は、Cloudflare チームにご連絡ください。
AMP の革新
AMP の初代チャンピオンは Google ですが、AMP 関連技術はオープンです。私たちは、Cloudflare の Accelerated Mobile Links や独自の AMP キャッシュの開発にあたり、Google チームと密接に連携してきました。Google で AMP プロジェクトのテクニカル リードを務める Malte Ubl 氏は、私たちとの協業について次のように話しています。
この記事は 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 マイビジネス ウェブやモバイルでも利用できるため、場所を問わずに重要なトレンドを把握することができます。
[この記事は 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 が使われています。その鍵となる技術のひとつがスマート キャッシュです。一般的に、キャッシュを活用すると、コンテンツとそれをリクエストするユーザーを物理的に近づけることができ、コンテンツのデータがユーザーのもとに届くまでに移動する距離が短くなります。さらに、キャッシュのような単一の共通インフラを使うことで、ページの提供時間の一貫性が高まります。一方、多くのホストから配信されるコンテンツは、キャッシュに比べるとコンテンツを提供するレイテンシが大幅に異なり、かなり長くなります。
// 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";
import firebase = require("nativescript-plugin-firebase");
firebase.init({
//persist should be set to false as otherwise numbers aren't returned during
livesync
persist: false,
storageBucket: 'gs://giftler-f48c4.appspot.com',
onAuthStateChanged: (data: any) => {
console.log(JSON.stringify(data))
if (data.loggedIn) {
BackendService.token = data.user.uid;
}
else {
BackendService.token = "";
}
}
}).then(
function (instance) {
console.log("firebase.init done");
},
function (error) {
console.log("firebase.init error: " + error);
}
);
platformNativeScriptDynamic().bootstrapModule(AppModule);
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;
}
近年、アセットの追跡や盗難防止、使用状況の最適化、アセットの保守点検などを目的として、GPS の代わりに Google Maps Geolocation API を用いた IoT（モノのインターネット）アプリケーションが増えています。そこで、Industry Solutions プロジェクトの一環として、周辺の Wi-Fi ネットワークと Google Maps Geolocation API を使って自身の位置を特定できる IoT デバイスのプロトタイプ作成に取り組みました。この記事では、実装した機能の一部を紹介すると共に、皆さんがご自分でもプロトタイプを作成できるよう、その方法を簡単に説明します。
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) {
...
}
}
API は位置だけでなく精度表示も返すため、精度のコンポーネントを示すカスタム マーカー（半径内の範囲が脈動する）を作成しました。
2 個のデバイス（赤と青）と判明した位置の直近 5 か所
次に進むには
この記事では、インターネットに接続されたデバイス（ロボットからウェアラブル端末まで）を追跡するために、Google Maps Geolocation API を使った IoT デバイスの構築方法を紹介しました。App Engine の処理モジュールを拡張し、他の Google Maps API を使ってルート案内や標高、プレイス、タイムゾーン情報などの地図データを提供することもできます。皆さん、ぜひ作成してみてください。
さらに、Firebase の代わりに Google Cloud Platform を使って同様のソリューションを実現することも可能です。手順はこちらの記事をご覧ください。
Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps Solution Architect, Google Maps
