[go: nahoru, domu]

[この記事は David East、デベロッパー アドボケートによる Firebase Blog の記事 "5 tips for Firebase Storage" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

David East


David East
デベロッパー アドボケート
お待ちかねの機能、Firebase デベロッパーのためのファイル ストレージがついに実現されました。Firebase Storage は、ユーザーが iOS 端末、Android 端末、ウェブで生成した画像やビデオなどのコンテンツをアップロードするためのスタンドアロン ソリューションです。他の Firebase のサービスと同様、サーバーは必要ありません。
Firebase Storage は、拡張性セキュリティネットワークの耐障害性に特化した設計になっています。
  • 拡張性: アップロードされたファイルはすべて Google Cloud Storage でバックアップされます。このストレージは、 数ペタバイト規模のデータに対応しています。
  • セキュリティ: ストレージ セキュリティ ルールによってファイルを保護し、特定のユーザーのみにアクセスが許可されます。
  • ネットワークの耐障害性: ネットワーク接続が不安定な場合、アップロードやダウンロードが自動的にリトライされます。そのため、自分で状況を確認する必要はありません。
このブログ記事では、Firebase Storage を活用するための 5 つのヒントを紹介します。説明はこのくらいにして、早速コードを見てみましょう。


1. ファイルのリファレンス ポイント

Realtime Database のことをよく知らなくても、Firebase Storage に簡単にデータを保存できます。Firebase Storage は、シンプルなフォルダとファイルの仕組みを使用し、データの構造化を行います。ファイルには、リファレンスを使ってアクセスします。

ウェブ
var storageRef = firebase.storage.ref("folderName/file.jpg");

iOS
let storageRef = FIRStorage.reference().child("folderName/file.jpg")
Android
StorageReference storageRef = FirebaseStorage.getInstance().reference().child("folderName/file.jpg");


リファレンスを使うと、ストレージ バケット内の指定の場所にあるファイルを操作できます。このストレージでは、既存のファイルのダウンロードや新しいファイルのアップロードを簡単に行うことができます。

2. メソッド 1 つでファイルをアップロード

リファレンスを取得したら、メソッド 1 つでファイルをアップロードできます。

ウェブ
var storageRef = firebase.storage.ref("folderName/file.jpg");
var fileUpload = document.getElementById("fileUpload");
fileUpload.on(‘change’, function(evt) {
  var firstFile = evt.target.file[0]; // get the first file uploaded
  var uploadTask = storageRef.put(firstFile);
});

iOS
let storageRef = FIRStorage.reference().child("folderName/file.jpg");
let localFile: NSURL = // get a file;

// Upload the file to the path "folderName/file.jpg"
let uploadTask = storageRef.putFile(localFile, metadata: nil)


Android
StorageReference storageRef = FirebaseStorage.getInstance().reference().child("folderName/file.jpg");
Uri file = Uri.fromFile(new File("path/to/folderName/file.jpg"));
UploadTask uploadTask = storageRef.putFile(file);

ウェブのバイナリ ファイルは、<input type="file" /> 要素で受信した File オブジェクトから取得します。iOS ユーザーは、メモリ内またはローカルからファイルをアップロードできます。Android では、ストリームを使ってアップロードすることも可能です。

3. タスクで進捗状況を監視

アプリに進捗インジケーターを作成したい場合、Firebase Storage を使うと簡単に実現できます。ファイルのアップロードやダウンロードを行うと、UploadTask または DownloadTasks が作成されます。これらのタスクから、ファイルのアップロードやダウンロードの進捗を監視できます。

ウェブ
var storageRef = firebase.storage.ref("folderName/file.jpg");
var fileUpload = document.getElementById("fileUpload");
fileUpload.on(‘change’, function(evt) {
  var firstFile = evt.target.file[0]; // get the first file uploaded
  var uploadTask = storageRef.put(firstFile);
  uploadTask.on(‘state_changed’, function progress(snapshot) {
     console.log(snapshot.totalBytesTransferred); // progress of upload
  });
});

iOS
let storageRef = FIRStorage.reference().child("folderName/file.jpg");
let localFile: NSURL = // get a file;

// Upload the file to the path "folderName/file.jpg"
let uploadTask = storageRef.putFile(localFile, metadata: nil)

let observer = uploadTask.observeStatus(.Progress) { snapshot in
  print(snapshot.progress) // NSProgress object
}

Android
StorageReference storageRef = FirebaseStorage.getInstance().reference().child("folderName/file.jpg");
Uri file = Uri.fromFile(new File("path/to/images/file.jpg"));
UploadTask uploadTask = storageRef.putFile(file);
uploadTask.addOnProgressListener(new OnProgressListener() {
    @Override
    public void onProgress(UploadTask.TaskSnapshot snapshot) {
        System.out.println(snapshot.getBytesTransferred().toString());
    }
});


進捗のリスナーがアップロードのスナップショットを返し、ファイルがサーバーにアップロードされます。このスナップショットから、ファイルの合計サイズ(バイト数)や現時点でアップロードされているバイト数などの有用な情報を得ることができ、アップロード済みの比率の計算やアプリの UI コントロールのアップデートを行うこともできます。

4. メソッド 1 つでファイルをダウンロード

Firebase Storage では、2 つの方法でファイルをダウンロードできます。1 つ目は SDK のリファレンスを使用する方法、もう 1 つはダウンロード URL を使用する方法です。iOS および Android ユーザーは、ファイルをメモリやディスクにダウンロードしたり、ダウンロード URL からダウンロードすることができます。ウェブ SDK では、ダウンロード URL からファイルをダウンロードできます。

ウェブ
var storageRef = firebase.storage.ref("folderName/file.jpg");
storageRef.getDownloadURL().then(function(url) {
  console.log(url);
});

iOS
let storageRef = FIRStorage.reference().child("folderName/file.jpg");
storageRef.downloadURLWithCompletion { (URL, error) -> Void in
  if (error != nil) {
    // Handle any errors
  } else {
    // Get the download URL for 'images/stars.jpg'
  }
}

Android
StorageReference storageRef = FirebaseStorage.getInstance().reference().child("folderName/file.jpg");
storageRef.getDownloadUrl().addOnSuccessListener(new OnSuccessListener() {
    @Override
    public void onSuccess(Uri uri) {
        // Got the download URL for 'users/me/profile.png'
    }
}).addOnFailureListener(new OnFailureListener() {
    @Override
    public void onFailure(@NonNull Exception exception) {
        // Handle any errors
    }
});


iOS と Android のアプリでは、メモリまたはディスクにファイルを格納できます。また、URL を使って一般的な画像キャッシュ ライブラリと連携させることもできます。ウェブ アプリでは、モダンブラウザが持っている強力なキャッシュ システムを活用できるため、URL を使う方式が好まれる場合があります。

5. ストレージ セキュリティ ルールによるユーザーベースのセキュリティ

Realtime Database と同様に、Firebase Storage でもアップロードできるファイルのサイズやタイプを制限したり、誰がどのファイルにアクセスできるかを指定するためのルールが提供されます。Firebase Storage は Firebase Authentication と一体になっているので、アプリケーション内のユーザーに対してファイルを保護することができます。この機能は、ユーザーのプロフィール写真のアップロード権限をそのユーザーだけに与える一方、そのプロフィール写真を誰でも閲覧できるようにしたい場合などに便利です。

// Only a user can upload their profile picture, but anyone can view it
service firebase.storage {
  match /b//o {
    match /users/{userId}/profilePicture.png {
      allow read;
      allow write: if request.auth.uid == userId;
    }
  }
}


ご意見をお寄せください。

私たちは、Firebase Storage で実現してきたことに誇りを持っています。しかし、この機能はまだスタートしたばかりです。皆様のフィードバックをお待ちしています。Firebase Storage を活用するためのヒントをお持ちでしょうか。Firebase Storage を利用する目的は何ですか。アプリの開発に役立ちそうな機能はありますか。ぜひ、コメントを残すか、Slack のチーム経由でご意見をお寄せくください。


Posted by Khanh LeViet - Developer Relations Team

[この記事は Jacob Wenger、ソフトウェア エンジニアによる Firebase Blog の記事 "Firebase and React Native" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]






Jacob Wenger




Jacob Wenger
ソフトウェア エンジニア
継続的にフィードバックをお寄せいただいているおかげで、JavaScript SDK のバージョン 3.1.0 で Firebase の React Native サポートが強化されました。それだけではありません。このバージョンでは、Node.js SDK からの認証されていないアクセスも追加されているため、サービス アカウントなしにアプリを初期化できるようになっています。これにはどのような意味があるのでしょうか。詳しく見ていきましょう。

React Native のサポート

Google I/O で Firebase 3.x SDK がリリースされた際、SDK の認証部分は React Native と互換性がなくなっていました。リリース 3.1.0 では、ブラウザ固有の API を置き換えることによって、再び Firebase に React Native との互換性を持たせています。さらに、アプリの再起動をまたぐ認証状態の永続化など、React Native で Firebase を使用する際に問題となってきた点が修正されています。これによって、その他の JavaScript アプリと同様、Firebase プロジェクトを初期化するだけでよくなります。

import ReactNative from "react-native";
import firebase from "firebase";
// Initialize Firebase
const firebaseConfig = {
  apiKey: "<YOUR-API-KEY>",
  authDomain: "<YOUR-AUTH-DOMAIN>",
  databaseURL: "<YOUR-DATABASE-URL>",
  storageBucket: "<YOUR-STORAGE-BUCKET>"
};
firebase.initializeApp(firebaseConfig);

3.1.0 SDK のアップデートでは、React Native でほぼすべての JavaScript SDK の機能がスムーズに動作するようになっています。ただし、いくつかの注意点があります。
  • signInWithPopup()signInWithRedirect()linkWithPopup()linkWithRedirect() などの「ヘッドフル」な認証メソッドは、React Native では動作しません(この点は Cordova でも同様です)。ただし、signInWithCredential() と任意のプロバイダからの OAuth トークンを利用することで、フェデレーションに対応したプロバイダにログインしたり、リンクすることができます。
  • React Native は File や Blob タイプをサポートしていないので、この環境では Firebase Storage へのアップロードは動作しません。ファイルのダウンロードは問題なく動作します。

未認証アクセス

リリース 3.1.0 のもう 1 つの特徴は、Node.js SDK で未認証アクセスがサポートされていることです。以前は、Node.js SDK を利用するにはサービス アカウントが必須でした。そのため、Firebase Console でのサービス アカウント キーの作成、サーバーへのダウンロード、コードからファイルを参照して認証、という作業を行う必要がありました。トークンの作成や検証には依然としてサービス アカウントが必要ですが、Node.js のユースケースによっては、サービス アカウントを使わないで済むこともあります。最新の SDK では、この要件を緩和してデータベース URL だけでアプリを初期化できるようにしています。

import firebase from "firebase";
firebase.initializeApp({
  databaseURL: "<YOUR-DATABASE-URL>",
});

サービス アカウントがない場合、他の未認証クライアントと同様に Realtime Database へのアクセスは制限されます。

フィードバックをお待ちしています

Slack のチームや Google Group、その他のサポート窓口より意見をお寄せいただき、ありがとうございました。新しい SDK で何か問題が発生した場合は、こちらからご連絡ください。React Native や Firebase に関して皆さまからのご意見をお待ちしています。


Posted by Yoshifumi Yamaguchi - Developer Relations Team

日の光がますますまぶしくなる今日このごろ、いかがお過ごしでしょうか。
さて、Android 版 Google 日本語入力をアップデートしたことをお知らせします。今回のアップデートからは Android 4.2 (Jelly Bean MR1, API Level 17) 以降のみに提供されます。それ以前の Android デバイスで Google 日本語入力をお使いの方は、現在ご使用中のバージョンを引き続きお使いいただけます。

主な変更点

テーマ機能


 


お待たせしました。
キーボードの外観をより自由に変更できるようになりました。ご自分で用意された画像を使うこともできます。Google 日本語入力の設定ページより変更が可能です。


片手モードの改善

簡単に片手モードを使うことができるようになりました。「あa」キーの長押しで表示される片手モードアイコンを選ぶと片手モードに移行します。



辞書をインポート
これまでの方法に加え、辞書ツールから直接単語リストをインポートできるようになりました。



記号/絵文字入力画面の刷新
 
記号/絵文字入力画面がより使いやすくなりました。


Android Nougat 対応

Android Nougat (プレビュー版含む) で使えるようになる新機能です。


Unicode 9 絵文字の対応

肌の色のバリエーションや手で顔を覆うジェスチャーなど、新しく追加された Unicode 9 絵文字を入力することができます(参考:Android N Developer Preview 2 がリリースされました)。

(開発者向け) ダイレクトブートへの対応
新たに導入されたダイレクトブート機能に対応しています(参考:ダイレクトブートに対応した開発)。


その他の変更点

  • 辞書を更新しました。
  • QWERTY キーボードから直接入力できる記号の種類を増やしました。
  • Tablet 端末における QWERTY キーボード レイアウトを改善しました。
  • ハードウェアキーボード で ひらがな ⇔ 英字 の切り替えを行うショートカットとして、これまでの [全角/半角キー] 、[ALT + `] に加え、[SHIFT + CTRL] を追加しました。

これからも、Google 日本語入力をよりよくするため、チーム一同で開発を進めていきます。お気づきの点がありましたら、ぜひプロダクト フォーラムからお知らせください。みなさんのフィードバックがなによりの励みになります。


Posted by 岡 智洋(Software Engineer)

[この記事は Tamzin Taylor、Google Play 担当戦略パートナー リードによる Android Developers Blog の記事 "New video tips to help news publishers find success on Google Play" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

本日(*原文公開当時)、3 部構成のビデオシリーズ「Tips for your news app on Google Play」(Google Play で配信するニュースアプリのヒント集)をリリースしました。このビデオで、実践的に高品質なニュースアプリの開発方法、リリースしてから収益化するためのベスト プラクティスを学習できます。このビデオシリーズは、最近リリースされた News Publisher Playbook(ニュース発行者のための Playbook)とセットになっています。

このビデオシリーズでは、次のようなことが学習できます。
  • ニュースアプリの設計と開発のための 10 のヒント
  • ニュースアプリをリリースしてユーザーを獲得するための 10 のヒント
  • ユーザーのリピート率を上げ、ニュースアプリを収益化するための 10 のヒント


Play Store から News Publisher Playbook を入手し、Android 用のニュースアプリの モバイル戦略を設計しましょう。この Playbook には、モバイル ウェブサイトの最適化、Google Play Newsstand 版の作成方法、ネイティブ アプリの改善方法などのヒントが記載されています。

フィードバックをお待ちしています

ビデオシリーズをチェックしたら、今後もより良いコンテンツを提供する事で、皆様を成功とビジネスの目的達成をサポートしたいので、ぜひフィードバックをお寄せください。Android Developers YouTube チャンネルに公開されている動画にコメントを残すかまたは他のコンテンツにも興味がありましたら、「いいね」を押し、チャネル購読してみてください。

また、Tips for Success on Google Play シリーズの他のビデオもご確認ください。最新のビデオには、数十億ユーザー向けのアプリを構築する 10 のヒントが含まれています。

Google Play で成功するためのその他のベスト プラクティスは、新しい Playbook for Developers アプリをご覧ください。



Posted by Takuo Suzuki- Developer Relations Team

[この記事は Rob Jagnow、Google VR ソフトウェア エンジニアによる Google Developers Blog の記事 "Daydream Labs: animating 3D objects in VR" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

ゲームをプレイしている場合でも、ビデオを見ている場合でも、VR で新しい世界に入り込み、ストーリーのヒーローになることができます。しかし、自分のストーリーを伝えたい場合はどうすればよいでしょうか。


臨場感のある 3D アニメーションの制作は難しく、コストもかかります。キーフレームを設定してスプライン補間を行う複雑なソフトウェアや、俳優の動きをライブでトラッキングするための高価なモーション キャプチャを必要とします。プロのアニメーターは、自然で表現力の高いシーケンスを作るためにかなりの労力を費やします。

Daydream Labs では、VR でアニメーションを行う際に技術的な複雑さを緩和し遊び感覚を向上させる方法を実験してきました。ある実験では、被験者がおもちゃを拾い上げたり、それを時間や空間の中で動かすことで、キャラクターを生き生きと動き回らせ、そのシーンをリプレイすることができました。



このようにして構築したアニメーションの実験で人々が遊ぶのを見て、いくつかのことに気づきました。

VR では複雑なメタファーは必要ない: 2D で複雑になる可能性があるものでも、3D では直感的にすることができます。グラフ エディタや位置を表すアイコンでアニメーションする代わりに、単純に手を伸ばして仮想世界にあるおもちゃをつかみ、シーンの中でそれを動かすことが可能です。このようなシンプルなアニメーションには手作りの魅力があり、驚くほど高度に感情を表現できました。

学習曲線がゼロに: 現実世界のおもちゃをどう使えばよいかはよくわかっているので、実験に参加した人々は、すぐにストーリーを伝え始めることができました。長いチュートリアルがなくてもアニメーションを変更したり、追加の説明なしに新しいキャラクターを追加することができました。

仮想環境での反応は現実世界での反応と同じ: VR 環境の遊び場に足を踏み入れた人々は、そこが、おもちゃを使って安全に遊ぶことができる場所だと理解し、臆することなくキャラクターを演じたり、愉快な声を出して遊んでいました。この仮想環境は遊ぶために作られているとわかっているので、さまざまなリスクにも挑戦しようとします。

さらに複雑なアニメーションを作るために、1 つのキャラクターの複数の関節を独立してアニメーションする別の実験も構築しました。操り人形のようにキャラクターの足、手、頭を別々にアニメーションさせ、その動きを記録できるものです。



VR は、ソフトウェアに対する考え方を変え、ユースケースを自然で直感的なものにします。この種のアニメーション システムはプロ用のツールの代替にはなりませんが、誰でも自分のストーリーを伝えることができます。VR を使ったストーリーの表現には、ビデオやアニメーションをはじめとしてさまざまな例があります。多くのクリエーターが VR で自身のストーリーを共有し、新しい視点が生みだされることを楽しみにしています。


Posted by Takeshi Hagikura - Developer Relations Team

[この記事は Sam Dutton、Ankur Kotwal、デベロッパー アドボケート、Liz Yepsen、プログラム マネージャーによる Android Developer Blog の記事 "Building for Billions" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]


「充電してください」「ネットワーク接続がありません」「このリソースの再生に十分な帯域がありません」

こういった警告は、世界中の多くのスマートフォンに表示されています。

何十億人ものユーザーに受け入れられる製品を構築するためには、ネットワーク接続の制限や断続的な接続、端末の互換性、スクリーンの大きさの違い、高額なデータコスト、すぐなくなるバッテリーといった大きな課題に対処する必要があります。先月の Google I/O では、developers.google.com/billions や関連する Android やウェブのリソースを公開しました。それに続き、本日(訳注:原文公開日)は Android およびウェブについてのビデオ プレゼンテーションを公開いたします。

こういったベスト プラクティスは、ネットワーク接続、データプラン、端末にかかわらず優れたパフォーマンスを提供することによって、何十億人ものユーザーに受け入れられることを目指すものです。g.co/dev/billions には、次のような役立つ内容が記載されています。

低速環境、中速環境、オフライン環境間のシームレスな遷移

ユーザーがある場所から別の場所に移動すると、高速な無線環境から断続的にしかつながらない環境に変わったり、データにかかるコストが跳ね上がったりします。データの保存、リクエストのキューへの格納、イメージ処理の最適化、完全オフライン状態でのコア機能の実行などによって、このような遷移に対応します。

適切な状況で適切なコンテンツを提供する

ユーザーがどこでどうやってコンテンツを参照しているのか、常にその状況を意識してください。ビューポートの大きさが変わっても問題なく機能するテキストやメディアの選択、短いテキストの維持(移動中のスクロール)、コンテンツの邪魔にならないシンプルな UI の提供、冗長なコンテンツの削除などは、すべてアプリの品質に対する 認識 の向上に貢献します。それとともにデータ転送量を減らすなど、実際のパフォーマンス向上を図ります。このような対策を済ませたうえでローカリゼーション オプションを提供すると、新たなユーザー層の取り込みやリピート率の向上につなげることができます。

モバイル ハードウェア向けの最適化

できる限り広いマーケットにアプリやウェブ コンテンツを提供し、それらが問題なく利用されるように、すべての主要な OS のバージョンをカバーします。さらに、対象マーケットの仮想端末や実際の端末でテストするというベスト プラクティスにも従います。ネイティブ Android アプリには、必要となる最小限の SDK と、対象 SDK を適切に設定します。さらに、低価格の携帯端末は RAM のサイズが小さいことも意識します。そのため、アプリのメモリ使用量が適切になるよう調整し、バックグラウンドでの動作も最小限にとどめます。APK サイズの最小化についての詳しい情報は、こちらのMedium の投稿をご覧ください。ウェブでは、JavaScript の CPU 使用量を最適化し、ラスター画像によるレンダリングを控え、リソースのリクエストを最小限にとどめます。詳しい情報は、こちらをご覧ください。

バッテリー消費量の削減

一般的に、携帯端末の価格が安いと、バッテリーの寿命も短くなります。ユーザーはバッテリー消費レベルに敏感で、バッテリーの消費が激しいと、アプリがアンインストールされやすくなったり、サイトが閲覧されなくなったりします。ベンチマーク テストを行って他のページやアプリとバッテリー消費量を比較するか、Battery Historian などのツールを使って、長時間動き続けてバッテリーを消費するプロセスをなくします。

データの集約利用

何を作る場合でも、データの集約利用は、ロード要件の理解、インタラクションに必要なデータ量の削減、ユーザーがすばやく目的の場所にたどり着くためのナビゲーションの効率化という 3 段階の簡単なステップで実現できます。ユーザーのためにデータ集約を行う(ネイティブ アプリでは、ネットワークの使用方法を設定する機能を提供することもできます)ことによって、プリペイド プランのユーザーやデータ利用料に制限のある契約のユーザーなど、データの利用に敏感なユーザーをつなぎとめることができます。また、「無制限」プランのユーザーであっても、ローミングを行ったり、予期せぬ費用が適用されたりすると、通信費が高額になる可能性もあります。

ネットワークにつながりにくい状況や低価格端末に対して、もう一歩踏み込んだ検討を行うか、成功につながる展開策を考えてみてください。よいアイデアは、ぜひ Google+ に投稿してください。



Posted by Yoshifumi Yamaguchi - Developer Relations Team

[この記事は Megan Boundey、Google Maps Mobile APIs プロダクト マネージャーによる Geo Developers Blog の記事 "Marker zIndex and more come to the Google Maps Android API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

米国時間 2016 年 6 月 27 日にリリースされた Google Maps Android API 最新版には、新しいマーカー プロパティ zIndex を使って地図上のマーカーの表示順序を設定できる機能や、タイル オーバーレイの透明度を設定できる機能、新しいサークル クリック リスナーなど、開発者からのご要望の多かった機能が含まれています。


マーカーの zIndex

マーカーの zIndexissue tracker で最も要望が多かった機能の 1 つです。今回のリリースにより、マーカーを地図上に表示する上で順番を設定できるようになります [Issue 7762]。この機能では、各マーカーに zIndex プロパティを設定することで、ユーザーが選択する可能性が最も高いタップ ターゲットをコントロールすることができます。マーカーは zIndex の順番で描画され、値が最も大きい zIndex マーカーが一番上に描画されます。

animated image with cars moving under a plane thanks to zIndex animated image with cars moving over a plane
変更前: マーカーの zIndex をコントロールする機能はなく、飛行機が車の下に隠れてしまう 変更後: 飛行機の zIndex を最大値に設定することで常に一番上に表示される


タイル オーバーレイの透明度

グラウンド オーバーレイと同様に、タイル オーバーレイの透明度も設定できるようになりました。ベース マップが透けて見えるようにすることができます [Issue 4765]。


サークルのクリック有効・無効設定

最新のリリースでコンパイルしたアプリでは、ポリラインやポリゴンと同じように、OnCircleClickListener でサークルのクリック有効・無効を設定できるようになります。該当するサークルで setClickable(boolean) を呼び出すことで、サークルのクリックを有効にしたり無効にしたりできます。


getMapAsync() が必須に

2014 年 12 月に getMap() を非推奨 とし、代わりに getMapAsync() を使用するようお知らせしました。今回のリリース以降は、アプリのコンパイルには getMapAsync() を使用していただくことになります。ただし、getMap() メソッドは、Android デバイスが持つ Google Play Services APK 内に残っているため、今回の変更によって、ユーザーのデバイス上にある既存のアプリが影響を受けることはありません。

以下の手順にまだ従っていない場合は、対応をお願いします。

以下は、非推奨となった getMap() を使ったサンプルフラグメントです。フラグメントのイニシャル ロジックを実装する架空の doStuff() を使用しています。
import android.os.Bundle;
 import android.support.v4.app.FragmentActivity;
 import com.google.android.gms.maps.GoogleMap;
 import com.google.android.gms.maps.SupportMapFragment;

 public class MainActivity extends FragmentActivity {

     private GoogleMap mMap;

     @Override
     public void onCreate(Bundle savedInstanceState) {
         super.onCreate(savedInstanceState);
         setContentView(R.layout.main);
         mMap = ((SupportMapFragment) getSupportFragmentManager().findFragmentById(R.id.map)).getMap();
         doStuff();
     }

 }


しかし、これでは getMap() が null を返す可能性があるため、エラーが起きやすい状態でした。同じサンプルで getMapAsync() を使った場合を下に示します。
import android.os.Bundle;
 import android.support.v4.app.FragmentActivity;
 import com.google.android.gms.maps.GoogleMap;
 import com.google.android.gms.maps.OnMapReadyCallback;
 import com.google.android.gms.maps.SupportMapFragment;

 public class MainActivity extends FragmentActivity implements OnMapReadyCallback {

     private GoogleMap mMap;

     @Override
     public void onCreate(Bundle savedInstanceState) {
         super.onCreate(savedInstanceState);
         setContentView(R.layout.main);
         ((SupportMapFragment) getSupportFragmentManager().findFragmentById(R.id.map)).getMapAsync(this);
     }

     @Override
     public void onMapReady(GoogleMap map) {
         mMap = map;
         doStuff();
     }

 }

ここでは、onMapReady() メソッドを定義する OnMapReadyCallback インターフェースを実装しています。このメソッドは、GoogleMap インスタンスの準備ができたときに呼び出されます。また、架空の doStuff() メソッドへの呼び出しを onMapReady() へ移動させています。ここが、フラグメントのイニシャル ロジックを開始させたい場所だからです。

Google Maps Android API をご利用いただいている皆様、そして issue tracker にてフィードバックをお寄せくださる皆様には、厚く御礼申し上げます。

リリース ノートには、バグ修正情報、非推奨情報、この記事で述べた機能について詳しく説明しています。ぜひ、新機能を試してみてください。

Posted by 丸山 智康(Tomoyasu Maruyama)- Google Maps Solution Architect, Google Maps API for Work

[この記事は Doug Stevenson、デベロッパー アドボケート、Ahmed Gad、プロダクト マネージャーによる The Firebase Blog の記事 "Introducing Firebase Test Lab for Android" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]




Doug Stevenson
Doug Stevenson
デベロッパー アドボケート


ユーザー基盤を拡大し、顧客満足度を高めて収益を増やすには、アプリケーションの品質が重要です。Google はそれをよく理解しています。Google Play のレビューで星 1 つになっているアプリのデータを詳しく分析すると、50% 以上のレビューがバグやクラッシュに関係していることがわかります。

2016 年 5 月の Google Play Store のレビューのサンプリング


Google Play Store での星 1 つのレビューの分類

多くのデベロッパーにとっては、リリース前にこのような問題を発見して解消するのは難しいことです。Android エコシステムは急速に成長しているため、ユーザーの規模に合わせた高品質でパフォーマンスの高いアプリを維持するのは厄介な作業です。ユーザー基盤が拡大する一方で、テストにはわずかな種類の端末しか使えないかもしれません。お住まいの国で手に入らない端末にアクセスするのは困難です。さらに、リリース前のテストをしやすくする適切なテスト用インフラを構築するのは費用も時間もかかるプロセスであり、継続的なメンテナンスも必要になります。


多様な端末を集めたテスト用インフラの構築

モバイル アプリケーションのテストを効率化するために、Google は Firebase Test Lab for Android を導入しました。これは、Google が自身の製品をテストする際に使用するツールと同じものを使ってテストを自動化できるプラットフォームです。これによって、いくつかの簡単なステップで Google の物理端末上でテストを起動し、できる限り高品質なアプリケーションを保証します。



あなたのテストを Google の端末で

通常、Android アプリケーションのテストを行う場合は、アプリとのインタラクションを記述した計測テストを書きます。既に Espresso、UI Automator 2.0、Robotium のいずれかでテストを記述している場合は、Firebase Test Lab にホストされた端末上ですぐにテストを実行できます。

テストを記録し、書く手間を削減

Android Studio 2.2(以降)では、新しい Espresso テスト レコーダー ツールを使って簡単に計測テストを作成することができます。アプリをレコーディング モードで起動するだけで、アプリを監視しているテスト レコーダーがインタラクションをすべて記憶し、それを再現する Espresso テストコードを生成してくれます。このようにして作成したテストは、Firebase Test Lab で実行できます。

テストを書かなくてもテストが可能

Firebase Test Lab は独自のテストを書かなくても利用できます。Robo テストと呼ばれる完全に自動化されたインテリジェントなテストが、アプリをクロールしてユーザー インターフェースのインタラクションをテストします。コードを 1 行も書かなくても、自動的にすべての範囲をテストしてくれるツールのメリットを活用できます。

端末を選択して大規模なテストを実施

テストを実行するたびに、さまざまな端末のメーカーやモデル、Android のバージョン、設定(仮想端末もベータ版として利用できるようになりました)を選択できます。その後、Firebase Test Lab は、選択した複数の端末上でテストを同時にできるだけ早く実行します。テストが完了すると、Firebase プロジェクトにテスト結果が保存されます。

開発初期段階から何度もテストを実施

テストは、Google Play にアプリをリリースする直前だけではなく、開発プロセス全体で行うと最も効果的です。テストプロセスをシンプルにするために、Android StudioFirebase Console などの既存のツールから直接 Firebase Test Lab のテストを起動できます。コマンドライン インターフェースを使うと、継続的インテグレーション環境でテストを実行することもできます。さらに、Google Play デベロッパー コンソールリリース前レポートを受信するようにオプトインすると、アルファ チャンネルやベータ チャンネルにアプリの新しいバージョンをリリースするたびに 5 分間の Robo テストを無料で利用できます。このテスト結果は、Play Store デベロッパー コンソールに表示されます。


Firebase コンソールに表示されたテスト結果

価格設定

Robo テストの実行によって生成される Play リリース前レポートは無料で利用できます。Firebase Test Lab でカスタマイズしたテストを利用するには、Blaze 課金プランのユーザーは物理端末 1 台につき 1 時間あたり 5 ドル、仮想端末(2016 年 10 月 1 日以降)1 台につき 1 時間あたり 1 ドルが必要です。それ以前は、仮想端末は無料で利用できます。詳細は、価格設定ページをご覧ください。


アプリの品質改善に今すぐ着手


Firebase Test Lab でテストを始めるのは簡単です。初めてのテストを実行するさまざまなシナリオが説明されているコードラボの手順をご覧ください。こちらから詳細なドキュメントをご覧いただくこともできます。不明点がある場合や、問題が発生した場合は、Firebase Google グループで質問できます。

Firebase Test Lab をぜひご活用ください。

Posted by Khanh LeViet - Developer Relations Team

[この記事は Emily Keller, Technical Program Manager for Google Maps APIs による Geo Developers Blog の記事 "Introducing the Google Maps APIs Udacity course" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google Maps のオペレーションチームは、地図や位置情報を活用して、優れたユーザーエクスペリエンスや地図・位置情報を使った強力な分析を実現するため、毎年数千人の開発者とともに仕事をしています。ここで得た知見をもとに、Udacity と協力して、Google Maps APIs のコースを新設しました。



新しいコースは、無料で受講することができます。地図や位置情報に関する機能をどのようにウェブサイトに統合するか、さまざまな ウェブサービス API を利用することによって有益な位置情報データをどのようにして得るかということを段階的に学べるチュートリアルとなっています。

独自スタイルの Google マップ、データの可視化、ストリートビューのパノラマ写真を用いて、不動産物件の一覧サイトの構築を行います。異なる地点間の距離を計算したり、経路を求めたり、特定の場所の情報を表示するなど、位置に関連する機能を実際に開発します。



また、Google Maps APIs の他の事例を確認したり、Google APIs Console を使って、アプリを監視する方法も学びます。コース終了時には、地図を利用したサイトを構築し、位置データ、サービス、地図を用いた皆さん自身のプロジェクトを始める準備もできていることでしょう。

Google Maps APIs の初心者の方、またこの機会にもう一度学んでみようという方も、Udacity にアクセスして、ウェブサイトに位置情報や地図で可視化する機能を追加する方法を学びましょう。

Posted by 丸山 智康 (Tomoyasu Maruyama) - Google Maps Solution Architect, Google Maps API for Work

アプリのユーザーベースを拡大する最大のチャンスは海外に眠っている可能性があります。今や世界 190 ヵ国以上の人々が毎日のように自分の端末にアプリをダウンロードしています。世界に潜むビジネス チャンスの大きさと、海外でアプリ ビジネスを展開するための 3 つのポイントについて、ぜひこちらのインフォグラフィックをご覧ください。



ローカライゼーションに関するその他のヒントについては、Android のローカライゼーション チェックリストをご確認ください。また、AdMob の Twitter Google+ ページをフォローして、AdMob の最新情報をチェックしてください。

Posted by Rikako Katayama - AdMob Team

[この記事は Dan Ciruli、Google Cloud Platform チーム担当プロダクト マネージャーによる Google Developer Blog の記事 "Announcing turndown of the Google Feed API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google Feed API は、2007 年に初めて発表された Google オリジナルの AJAX API の 1 つで、好評をいただいてきました。しかし、この API に向けられる関心や API の利用数は時間とともに低下しているだけでなく、現在は 2 世代前の Google の API インフラ上で動作しているという状況になっています。

2012 年 4 月には、その他多くの無料 API とともに、今後 3 年以内に廃止する予定であることをお知らせいたしました。2015 年 4 月に、廃止猶予期間は終了しています。今まで暫定的に API の運用を続けてきましたが、提供の終了をお知らせいたします。

Google Feed API の運用は 2016 年 9 月 29 日に終了いたします。しかし、デベロッパーの皆様への最後のお礼として、それまでの間は API の運用を継続する予定です。それまでに、アプリケーションでこの API を使用しないように対応してください。

Google は、API やデベロッパーの信頼がどれほど重要であるかを認識しており、このような決断は決して軽々しく行っているものではありません。今後も、Google が優れたサービスの提供に尽力し、その状況についてオープンであり、情報提供に務めてゆくことに変わりありません。

ワークフローで RSS が欠かせない要素となっているデベロッパーの皆様は、さまざまな商用製品の中からユースケースに合致するものをご利用いただくことができます。



Posted by Eiji Kitamura - Developer Relations Team

[この記事は Nicolas Capens ソフトウェア エンジニア兼「ピクセルパイレーツ」による Chromium Blog の記事 "Universal rendering with SwiftShader, now open source" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

SwiftShader は、CPU で高パフォーマンス グラフィック レンダリングを行うソフトウェア ライブラリです。Google は、既に Chrome、Android 開発ツール、クラウド サービスなどの複数の製品でこのライブラリを使用しています。本日(*原文公開当時)、Swiftshader は完全なオープンソースとなり、多くのアプリケーションで使用しやすくなりました。

2009 年以来、Chrome はハードウェア アクセラレーションによるレンダリングを完全にはサポートしていないシステムでの 3D レンダリングに SwiftShader を使用しています。WebGL などの 3D コンテンツは GPU 向けに記述されていますが、ユーザーの端末にはこのようなコンテンツを実行できるだけのグラフィック ハードウェアが搭載されていない場合もあります。また、信頼性の高い 3D レンダリングができない、あるいは 3D レンダリングがまったくできない深刻なバグがあるドライバが存在する可能性もあります。Chrome はそのようなシステムでもすべてのユーザーが 3D ウェブ コンテンツを利用できるように、SwiftShader を使用しています。





十分な GPU を搭載していないマシンで SwiftShader を実行していない Chrome(左)では、WebGL の Globe テストを実行できません。同じマシンで SwiftShader を有効にする(右)と、コンテンツの完全なレンダリングが可能になります。

SwiftShader は、Chrome や Android で使用されているのものと同じ OpenGL ES グラフィック API を実装しています。SwiftShader をオープンソース化することによって、他のブラウザ ベンダーが広く 3D コンテンツをサポートできるようになり、ウェブ プラットフォーム全体が進化します。とりわけ、WebGL が無条件にサポートされることによって、ウェブ デベロッパーがカジュアル ゲーム、教育アプリ、共同コンテンツ作成ソフトウェア、製品紹介、バーチャル ツアー、その他の魅力的なコンテンツを作成できるようになります。SwiftShader には、GPU のないシステムでのレンダリングを可能にするクラウド アプリケーションも存在します。

CPU でグラフィック計算を効率的に実行してユーザーに最高のパフォーマンスを提供するために、SwiftShader はいくつかのテクニックを利用しています。一般的なコンパイル時の最適化とは異なり、動的コード生成によって現在のタスクに最適なコードを実行時に生成できます。この複雑なアプローチは、直感的な命令型構文を持つ独自の C++ 埋め込み言語 Reactor を利用することによってシンプルなものになっています。また、SwiftShader は SIMT 風のベクター演算とマルチスレッド テクノロジーを併用し、利用できる CPU のコアやベクター演算ユニットを活用して並列度を上げています。これによって、アプリ ストリーミングなどのリアルタイム レンダリングが Android 上で実現できます。

デベロッパーの皆様は、git リポジトリから SwiftShader のソースコードにアクセスできます。メーリング リストにサインアップすると、最新の開発情報を受け取ることができます。また、オープンソース コミュニティの SwiftShader デベロッパーと共同作業を行うこともできます。


Posted by Takuo Suzuki - Developer Relations Team

[この記事は Dmitry Malykhanov、デベロッパー アドボケートによる Android Developers Blog の記事 "Android changes for NDK developers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

他の Android プラットフォームの改善と合わせて、Android M と N のダイナミック リンカーのコード記述要件が厳しくなりました。これは、クロスプラットフォームでコンパイル可能なきれいなネイティブ コードをロードできるようにするためです。最新の Android リリースにスムーズに移行できるように、このルールや推奨事項に従ってアプリケーションのネイティブ コードを記述することが必要になります。

個別の変更点については、以下で詳しく説明します。いずれも、ネイティブ コードのロードに関する問題を回避した結果、あるいは問題を回避するステップに伴う変更です。

必須ツール: NDK の各アーキテクチャには、toolchains/ の下に <arch>-linux-android-readelf バイナリ(たとえば、arm-linux-androideabi-readelf や i686-linux-android-readelf)というファイルがありますが、ここで使用している基本的な検査だけであれば、readelf はどのアーキテクチャに対しても使用できます。Linux では、readelf を使うには「binutils」パッケージ、scanelf を使うには「pax-utils」パッケージのインストールが必要です。

プライベート API(API 24 以降で強制)

ネイティブ ライブラリは、パブリック API のみを使用しなければならず、NDK 以外のプラットフォーム ライブラリにリンクしてはいけません。このルールは API 24 以降で強制となり、アプリケーションは NDK 以外のプラットフォーム ライブラリをロードできなくなります。このルールを強制するのはダイナミック リンカーなので、コードがどのような手段でロードしようとしても、パブリックでないライブラリにアクセスすることはできません。System.loadLibrary(...)、DT_NEEDED エントリ、dlopen(...) の直接呼び出しは、いずれも同じように失敗します。

アプリをアップデートしても、ユーザーは一貫した操作性を提供されるべきです。また、プラットフォームの変更に対応するために、デベロッパーが緊急アップデートを行なわなければならないのは適切ではありません。その理由から、プライベートな C/C++ シンボルの利用を控えることをおすすめします。プライベート シンボルのテストは、すべての Android 端末が合格する必要のある互換性テストスイート(CTS)に含まれていません。プライベート シンボルが存在しない可能性や、動作が異なる可能性があります。そのため、プライベート シンボルを使用するアプリは、特定の端末や将来のリリースで動作しなくなる可能性が高くなります。Android 6.0 Marshmallow で OpenSSL が BoringSSL に切り替えられた際に、多くのデベロッパーがこれを経験しました。

この変更によるユーザーへの影響を軽減するために、Google Play でインストール率の高いアプリで多く使われており、しばらくの間サポートが可能ないくつかのライブラリを特定しました。これには、libandroid_runtime.so、libcutils.so、libcrypto.so、libssl.so などが含まれています。また、移行に当てられる時間を長くとれるように、これらのライブラリは一時的にサポートいたします。ただし、将来のリリースでコードが動作しなくなるという警告を見かけたら、すぐに修正をしていただくようお願いいたします。

$ readelf --dynamic libBroken.so | grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libnativehelper.so]
 0x00000001 (NEEDED)                     Shared library: [libutils.so]
 0x00000001 (NEEDED)                     Shared library: [libstagefright_foundation.so]
 0x00000001 (NEEDED)                     Shared library: [libmedia_jni.so]
 0x00000001 (NEEDED)                     Shared library: [liblog.so]
 0x00000001 (NEEDED)                     Shared library: [libdl.so]
 0x00000001 (NEEDED)                     Shared library: [libz.so]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so]
 0x00000001 (NEEDED)                     Shared library: [libm.so]
 0x00000001 (NEEDED)                     Shared library: [libc.so]


発生する恐れのある問題: API 24 以降、ダイナミック リンカーはプライベート ライブラリをロードしないため、アプリケーションがロードできなくなります。

解決策: パブリック API のみを使うようにネイティブ コードを書き直します。短期的な回避策として、複雑な依存性のないプラットフォーム ライブラリ(libcutils.so)をプロジェクトにコピーすることができます。長期的な解決策としては、関連するコードをプロジェクト ツリーにコピーする必要があります。SSL / Media / JNI 内部 / バインダ API には、ネイティブ コードからアクセスするべきではありません。必要な場合は、ネイティブ コードから適切なパブリック Java API のメソッドを呼び出します。

パブリック ライブラリの完全なリストは、NDK 内で参照できます。platforms/android-API/usr/lib 以下をご覧ください。

注: SSL/crypto は特殊なケースです。アプリケーションは、プラットフォームの libcrypto および libssl ライブラリを直接使用してはいけません。これは古いプラットフォームにも該当します。既知の脆弱性から保護されるよう、すべてのアプリケーションで GMS セキュリティ プロバイダを使用してください。

セクション ヘッダーの欠落(API 24 以降で強制)

各 ELF ファイルのセクション ヘッダーには、追加情報が含まれています。ダイナミック リンカーがサニティ チェックを行う際にこのヘッダーを使うため、ヘッダーの存在が必須となります。バイナリを難読化してリバース エンジニアリングを防ぐために、このヘッダーを取り除こうとするデベロッパーもいます(取り除いた情報は広く入手できるツールを使って再構築できるため、この方法は実際にはあまり役に立ちません)。

$ readelf --header libBroken.so | grep 'section headers'
  Start of section headers:          0 (bytes into file)
  Size of section headers:           0 (bytes)
  Number of section headers:         0
$


解決策: ビルド時にセクション ヘッダーを取り除くステップを行わないようにします。

テキストの再配置(API 23 以降で強制)

API 23 以降、共有オブジェクトにテキストの再配置を含めることはできません。つまり、コードはそのままロードし、変更せずに使用する必要があります。このようなアプローチによって、ロード時間が短くなり、セキュリティも向上します。

テキストの再配置を行う一般的な理由は、位置に依存した手書きのアセンブラの存在です。これは一般的ではありません。さらに詳しい診断を行うには、ドキュメントに記載されている scanelf ツールを使用してください。

$ scanelf -qT libTextRel.so
  libTextRel.so: (memory/data?) [0x15E0E2] in (optimized out: previous simd_broken_op1) [0x15E0E0]
  libTextRel.so: (memory/data?) [0x15E3B2] in (optimized out: previous simd_broken_op2) [0x15E3B0]
[skipped the rest]


scanelf ツールを利用できない場合は、代わりに readelf を使用して基本的なチェックを行うことも可能です。その場合、TEXTREL エントリか TEXTREL フラグを探します。どちらかが見つかれば十分です(TEXTREL エントリに対応する値は関係なく、通常は 0 です。TEXTREL エントリが存在するだけで、.so にテキストの再配置が含まれていることがわかります)。次の例では、両方が存在しています。

$ readelf --dynamic libTextRel.so | grep TEXTREL
 0x00000016 (TEXTREL)                    0x0
 0x0000001e (FLAGS)                      SYMBOLIC TEXTREL BIND_NOW
$


注: 技術的には、共有オブジェクトに TEXTREL エントリ / フラグがあっても、実際のテキストの再配置は含まれていない場合も考えられます。これは NDK では発生しませんが、Android のダイナミック リンカーはこのエントリ / フラグに基づいて判断しているため、独自に ELF ファイルを生成している場合は、テキストの再配置を含むことを宣言している ELF ファイルを生成していないことを確認してください。

発生する恐れのある問題: 再配置は、強制的にコードページを書き込み可能にし、メモリ内のダーティー ページ数を無駄に増加させます。Android K(API 19)以降、ダイナミック リンカーはテキストの再配置について警告してきましたが、API 23 以降では、テキストの再配置を含むコードをロードできなくなります。

解決策: アセンブラを位置に依存しないように書き直し、テキストの再配置が不要になるようにします。詳しい説明は、Gentoo のドキュメントをご覧ください。

無効な DT_NEEDED エントリ(API 23 以降で強制)

ライブラリの依存性(ELF ヘッダーの DT_NEEDED エントリ)は絶対パスでも構いませんが、ライブラリがシステムのどこにインストールされるかを制御できない Android では、絶対パスは意味をなしません。DT_NEEDED エントリは必要となるライブラリの SONAME と同じである必要があり、実行時にライブラリを探す作業はダイナミック リンカーに委ねられます。

API 23 より前は、Android のダイナミック リンカーが必要なライブラリを探す際に、フルパスを無視してベース名(最後の「/」以降)だけを使用していました。API 23 以降では、実行時リンカーが DT_NEEDED を正確に解釈するため、端末上の正確な場所にライブラリが存在しない場合、ライブラリをロードできません。

さらに悪いことに、ビルド ホスト上のファイルを指す DT_NEEDED エントリを挿入するバグがあるビルドシステムも存在します。その場合、端末上でライブラリを見つけることはできません。

$ readelf --dynamic libSample.so | grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libm.so]
 0x00000001 (NEEDED)                     Shared library: [libc.so]
 0x00000001 (NEEDED)                     Shared library: [libdl.so]
 0x00000001 (NEEDED)                     Shared library:
[C:\Users\build\Android\ci\jni\libBroken.so]
$


発生する恐れのある問題: API 23 より前では、DT_NEEDED エントリのベース名が使われました。API 23 以降では、Android ランタイムは指定されたパスを使用してライブラリをロードしようとしますので、パスが端末上に見つかりません。SONAME ではなく、ビルド ホスト上のパスを使用するという問題があるサードパーティ製のツールチェーンやビルドシステムも存在します。

解決策: 必要なすべてのライブラリが SONAME だけによって参照されていることを確認してください。端末によって場所が異なる可能性があるため、ライブラリは実行時リンカーに探させてロードさせるようにします。

SONAME の欠落(API 23 以降で使用)

すべての ELF 共有オブジェクト(「ネイティブ ライブラリ」)に、SONAME(共有オブジェクト名)属性が必要です。デフォルトで NDK ツールチェーンはこの属性を追加します。そのため、この属性が存在しないということは、誤って別のツールチェーンを設定しているか、ビルドシステムの設定が誤っているかのどちらかです。SONAME がない場合、代わりにファイル名が利用されるので、実行時に誤ったライブラリがロードされるなどの問題が発生する可能性があります。


$ readelf --dynamic libWithSoName.so | grep SONAME
 0x0000000e (SONAME)                     Library soname: [libWithSoName.so]
$


発生する恐れのある問題: 名前空間の衝突により、実行時に誤ったライブラリがロードされる可能性があります。その場合、必要なシンボルが見つからない、または利用しようとしているライブラリとは違う ABI 非互換のライブラリが使われるため、クラッシュが発生します。

解決策: 最新の NDK は、デフォルトで正しい SONAME を生成します。最新の NDK を利用していることと、(-soname リンカー オプションによって)不適切な SONAME エントリを生成するようにビルドシステムを設定していないことを確認します。

最新の NDK で正しくビルドしたクロスプラットフォームのコードは、Android N で問題なく動作します。正しいバイナリを生成できるように、ネイティブ コード ビルドを見直してみることをおすすめします。


Posted by Yuichi Araki - Developer Relations Team

[この記事は Pete Warden、ソフトウェア エンジニアによる Google Developers Blog の記事 "TensorFlow v0.9 now available with improved mobile support" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

TensorFlow の開発を始めた際の最優先事項は、モバイル端末のサポートでした。Translate や Maps、Google アプリのような Google のモバイルアプリは、端末上で実行されるニューラル ネットワークを使用したアプリです。私たちは、オープンソース TensorFlow の最も重要な部分はモバイルだと考えています。

TensorFlow は、リリース当初から Android で利用できました。加えて本日(*原文公開当時)、TensorFlow v0.9 は iOS でも利用できるようになり、 Raspberry Pi のサポートと新しいコンパイル オプションも追加されました。

iOS で TensorFlow をビルドするために、クロスコンパイル処理を行ういくつかのスクリプトを作成しています。そのうちの makefile は、常に利用できるわけではない Bazel を使わずに TensorFlow をビルドする際に役立ちます。
以上のことは、最新の TensorFlow ディストリビューションにすべて含まれています。詳しくは、モバイル TensorFlow ガイドや iOS サンプルAndroid サンプルのドキュメントをご覧ください。モバイル用サンプルでは、ImageNet Inception v1 classifier を使用して画像を分類することができます。
現在のモバイル用サンプルはほんの触りに過ぎません。皆様のサポートや貢献をお待ちしています。ソーシャル メディアの投稿に #tensorflow タグをつけて、皆様のプロジェクトを共有してください。

TensorFlow 0.9.0 リリースノートの完全版は、こちらからご覧いただけます。


Posted by Kazunori Sato - Google Cloud Platform

[この記事は Adam Champy、Google Cast SDK プロダクト マネージャーによる Google Developers Blog の記事 "New Google Cast SDK released for Android and iOS" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google Cast を使うと、モバイルアプリを自宅の美しい画面やスピーカーで簡単に使えるようになります。

私たちは Google I/O で新しい Google Cast SDK を発表しました。この新しい SDK は、Google Cast 向けの開発をよりすばやく、より確実に、より簡単に運用できることに主眼を置き、アプリと Google Cast の間に適切な抽象化を実装する際に便利な状態管理を導入しました。また Google Cast デザイン チェックリストを満たすのに十分な Cast ユーザー エクスペリエンスも提供しています。

そして本日(*原文公開当時)、Android と iOS 向けの Sender 用 SDK をリリースしました。これには、両プラットフォーム向けの紹介ビデオドキュメント一式、参照用のサンプルアプリコードラボ チュートリアルも含まれています。最初に使用したデベロッパーからは、以前の SDK と比べて初回実装の開発時間を大幅に削減できたというフィードバックをいただいています。



カスタマイズ可能な拡張コントローラやミニ コントローラへのカスタマイズの追加など、発表された内容のいくつかは数か月後にリリースされます。これによって、さらに短時間で開発を行えるようになります。

新しい SDK や API については、Cast デベロッパー サイトをご覧ください。また、g.co/googlecastdev にアクセスして Google+ のデベロッパー コミュニティに参加し、他のデベロッパーとアイデアを交わしてみましょう。



Posted by Yoshifumi Yamaguchi - Developer Relations Team

開発者の方ならご存知かと思いますが、星 4 つ以上の評価を受けたアプリはユーザーに探しやすくなり、ダウンロード数が増える傾向があります。Google Play の調査でも、評価の高いアプリほど収益が多いのがわかります。


*Google Play のすべてのアプリ ビジネスモデル(アプリ内購入、有料アプリ、広告掲載)による収益が含まれています

では、星 4 つ以上の評価を得るには何をすればよいでしょうか?まずユーザーのレビューや評価から具体的なフィードバックを収集、分析し、定期的な業務手順を確立する必要があります。その後、分析結果に基づいてアプリの品質を改善していくことが重要です。

アプリの品質改善に向けた 6 つの指針

  1. 信頼性: クラッシュを起こさない。ユーザーからのエラーレポートを頻繁に確認し、アプリの信頼性を高めてバグを解消できるように迅速に対応しましょう。
  2. 応答性: スピード重視。アプリのスピードを上げるには、レイアウトを極力シンプルにすることが早道です。
  3. 操作性: 指先での操作を意識。簡単に改善できる一般的な問題点として、タップ対象エリアとフォントが小さすぎるケースが挙げられます。リンクは簡単にタップできるものにしましょう。
  4. デザイン: 美しさ重視。デザイナーを雇う余裕がない場合は、Photoshop や GIMP といった画像編集ツールを使ってアプリの見栄えを良くしましょう。
  5. やり過ぎは禁物: 機能を厳選。ユーザーの意見に耳を傾け、機能に対する要望を集めて対応しましょう。ただし、必ずしもすべての要望に応えることが最善策ではありません。
  6. OS や第三者アプリの機能を活用: ホーム画面ウィジェットリッチ通知グローバル検索Quick Contacts といった機能を組み込んだり、第三者アプリの機能を活用したりして、ユーザーの利便性を高めよう。
ぜひ Google+ Twitter のページで AdMob の最新情報を定期的にご確認ください。


Posted by Rikako Katayama - AdMob Team

[この記事は Bhavik Singh、プロダクト マネージャーによる Android Developers Blog の記事 "Create Intelligent, Context-Aware Apps with the Google Awareness APIs" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

Google I/O 2016 で、Google Awareness API が新たに発表されました。この API を活用すると、スナップショットやフェンスを使って、ユーザーの状況にインテリジェントに反応するアプリを実現できます。システム リソースには最低限の影響しか与えません。

本日(*原文公開当時)、Google Play サービスを通じすべてのデベロッパーが  Google Awareness API を利用できるようになったことをお知らせできることをうれしく思います。



場所、天気、ユーザー アクティビティ、周辺のビーコンを含む 7 種類のコンテキストを利用することで、アプリはユーザーが置かれている現在の状況を細かく認識できるようになり、その情報にを使って最適化、カスタマイズした体験をユーザーに提供できます。

Awareness API では、2 つの方法によってアプリ内で状況シグナルを活用できます。

  • Snapshot API では、アプリから簡単にユーザーの現在の状況についての情報をリクエストできます。たとえば、「ユーザーの現在いる場所と、現在の天候を教えてください」というようなリクエストが可能です。
  • Fence API では、ユーザーの状況が変化した際や、ある条件に該当した際にアプリを反応させることができます。たとえば、「ユーザーがヘッドフォンをさしたまま歩いているときは教えてください」というようなリクエストが可能です。Geofencing API と同じように、認識フェンスを登録することによって、アプリが実行されていない場合も含め、コールバックが送信されるようになります。


Awareness API は単一のシンプルなインターフェースであり、以前にはできなかった新しい方法で最適な処理が行われた状況シグナルを組み合わています。バッテリーを節約し、帯域幅を最低限に抑えるようにシステム リソースを管理しつつ、正確で実態に即した状況シグナルを提供します。

Google は、何社かのパートナーと密接に連携してきました。そのようなパートナーは、既に驚くような方法で状況認識をアプリに組み込んでいます。



オンライン住宅不動産サイトの Trulia は、Fence API を使って自由に見学できる家を提案しています。天気が良く、ユーザーが興味のある家のそばを歩いていると、Trulia は立ち寄ってみることをうながす通知を送信します。このようなカスタマイズした通知によって、ユーザーが都合の良いときに家を見学してくれる可能性が増加します。



また、SuperPlayer Music は Snapshot API と Fence API を使って、ユーザーのムードにぴったりの音楽を提案しています。ランニングを終えたり、ストレッチを始めたり、長時間のドライブに出かけたり、ジムに到着したようなとき、アプリはその状況を認識して、最適なプレイリストを提案します。

基本的なシグナルとすばらしいパートナーとともに Awareness API はスタートしたばかりです。Google Awareness API デベロッパー ドキュメントや Google I/O セッションを参考にして Awareness API を使い、あなたのアプリでもユーザーに最高の体験を提供しましょう。





Posted by Yoshifumi Yamaguchi - Developer Relations Team

[この記事は Laurence Moroney、デベロッパー アドボケート、 Alfonso Gómez Jordana、アソシエイト プロダクト マネージャーによる The Firebase Blog の記事 "Introducing Firebase Authentication" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]




Laurence Moroney





Laurence Moroney
デベロッパー アドボケート


多くのデベロッパーにとって、アプリ用認証システムの構築は、税金を払うことのように感じるものです。どちらもわかりにくく、行わざるを得ないタスクで、うまく対応しないととんでもない結果になる可能性があります。税金を払うために会社を始める人は誰もいないように、すばらしいログイン システムを作るためだけにアプリを開発する人もいません。どちらも避けることのできない代償であるように見えます。

今なら、少なくとも「認証税」からは逃れることができます。Firebase Authentication の力を借りれば、認証システムを完全に Firebase にアウトソースし、優れたアプリを構築することに集中できます。ユーザーが簡単にログインできるようになるだけでなく、独自に認証システムを実装する際に求められる、複雑な処理を理解する必要もなくなります。簡単に使い始めることができ、ユーザーができるだけ戸惑わないようなデザインとなっているユーザー エクスペリエンス(UX)コンポーネントもオプションで提供されています。また、オープン スタンダードを基にして構築されており、Google のインフラによって支えられています。




Firebase Authentication の実装は、比較的簡単に早く済みます。広く使われているログイン方法(Facebook、Google、Twitter、メールとパスワードなど)の中から提供したいものを Firebase コンソールから選択し、Firebase SDK をアプリに追加するだけで、アプリはRealtime DatabaseFirebase Storage独自のカスタム バックエンドのいずれかと安全に接続できるようになります。すでに認証システムをお持ちの方は、Firebase Authentication を別の Firebase 機能へのブリッジとして使用することもできます。

Firebase Authentication にはオープンソース UI ライブラリも含まれており、ユーザーに優れたエクスペリエンスを提供する際に欠かせない、さまざまな認証フローを効率的に構築できます。Firebase Authentication の UI には、パスワードのリセット機能、アカウントのリンク機能、複数のログイン方法がある場合に認知的負荷を減らすログイン時のヒント機能などがすべて組み込まれています。こうしたフローは、Google や YouTube、Android でログインやサインアップのプロセスを最適化するための長年の UX リサーチに基づいています。Firebase Authentication には、多くのアプリでログイン コンバージョンを大幅に改善することにつながった Android の Smart Lock for Passwords も含まれています。Firebase UI はオープンソースなので、インターフェースは完全にカスタマイズできます。どんなアプリに組み込んでも自然に見えます。必要に応じて、クライアント API を使って一から独自の UI を作成することもできます。

さらに、Firebase Authentication はオープン性とセキュリティを中核に据えて構築されており、セキュリティ、相互運用性、移植性を持つように設計された業界標準である OAuth 2.0 と OpenID Connect を活用しています。Firebase Authentication チームのメンバーは、このようなプロトコルの設計にも携わっており、その経験を基にして ID トークン、取り消し可能なセッション、ネイティブ アプリの偽装対策といった最新のセキュリティ手法を生み出しています。それによってアプリが使いやすくなるとともに、多くの一般的なセキュリティの問題も回避できます。また、コードは Google Security チームによる独立したレビューを受けており、サービスは Google のインフラで守られています。

Fabulous がログインを短時間で実装するために Firebase Authentication を使用



Fabulous は、ログイン システムを強化するために Firebase Authentication を使用しています。デューク大学先進後知恵研究センターの研究から生まれたこのアプリは、不適切な行動を慎み、健康的な習慣を身に付けるための取り組みを始め、最終的にはユーザーが健全に幸福な暮らしを送ることを支援することを目的としています。

Fabulous のデベロッパーは、アップデートを最低限に抑え、エンドユーザーの負担を軽くする簡単な初回起動フローを実装したいと考えました。また、サインアップする前にアプリを試せるよう、匿名オプションも設けたいと考えました。さらに、複数のログイン方法をサポートし、ユーザーのログインフローとアプリのルック アンド フィールに一貫性を持たせるオプションも求めていました。

「たった半日で認証を実装することができました。以前は、独自のソリューションの作成には何週間もかかり、プロバイダの API に変更が発生するたびにアップデートしなければなりませんでした」- Amine Laadhari, Fabulous CTO

Malang Studio が Firebase Authentication で商品化までの時間を月単位で短縮



Chu-Day(AndroidiOS に対応)は、カップルが重要な日を忘れないようにするためのアプリケーションです。このアプリは、キャラクター中心のゲーム型ライフスタイル アプリケーションを開発している韓国企業 Malang Studio が作成しました。

一般的に、カウントダウンや記念日関係のアプリはユーザーのログインを要求しません。Malang Studio は、カップルをつないで特別な記念日をともにカウントダウンできるようにすることで、Chu-day を特別なアプリにして差別化を図りたいと考えました。しかしこれにはログイン機能が必要で、ユーザーの脱落を防ぐシームレスなログイン プロセスも必要でした。

Malang Studio は、Facebook や Google のログインを利用することで、 1 日で初回起動フローをアプリに組み込むことができました。サーバー側の開発やデータベースについて考える必要はなく、Firebase User Management Console を活用し、ログイン実装の開発やテスト、ユーザーの管理を行うこともできました。

「Firebase Authentication は最低限の設定しか必要としないので、短時間で簡単にソーシャル アカウントへのサインアップが実装できました。コンソールで提供されるユーザー管理機能もすばらしく、簡単に認証システムを実装できました」- Marc Yeongho Kim, Malang Studio CEO 兼 創立者

Firebase Authentication の詳細については、デベロッパー サイトと Google I/O 2016 のセッション「Best practices for a great sign-in experience」をご覧ください。


Posted by Yoshifumi Yamaguchi - Developer Relations Team

[この記事は Dom Elliott、Google Play チームによる Android Developer Blog の記事 "Grow your business on Google Play with help from the new Playbook for Developers app" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

本日(*原文公開当時)、Android 端末で Playbook for Developers(*日本語名 ハンドブック)モバイル アプリが利用できるようになりました。このアプリで各機能やベスト プラクティスについての最新情報を受け取り、Google Play でのビジネスを成長させましょう。 6 週間にわたってベータテストを行ってくださった方々のフィードバックのおかげで、アプリの公開に向けた微調整や改訂を行うことができました。

Playbook for Developers アプリの文章や動画によるコンテンツは、次のように活用することができます。
  • ビジネス上興味があるトピックを選び、Google を始めとするさまざまなウェブのエキスパートたちによる記事やビデオが満載された My Playbook をパーソナライズできます。
  • 開発、公開、促進、成長、収益など、目的に応じてグループ化された記事から、Google のデベロッパー製品についての詳細ガイドを確認できます。
  • 各項目に対して、完了、共有、保存、消去のアクションを実行できます。保存した記事は、アプリ内で書かれたものであればオフラインでも読むことができます。ウェブの記事やビデオを見るには、データ接続が必要になります。

このアプリは、Android 5.0 以上をサポートしています。最新の情報を提供し、ビジネスの成長をサポートするため、アプリ内のコンテンツは今後も追加、更新されます。Playbook for Developers アプリをすぐに入手し、フィードバックをお寄せください。アプリは、バハサ・インドネシア語ドイツ語スペイン語(南米)フランス語ブラジル ポルトガル語ベトナム語ロシア語韓国語中文(简体)中文(繁體)日本語の各言語でご利用いただけます。

Google が Google Play デベロッパー向けにリリースしたアプリは、これで 2 つ目になります。Google Play Developer Console アプリを使うと、移動中であっても、アプリのパフォーマンス統計や財務データの確認、アプリのステータスや公開状況の変更の通知、ユーザー レビューの確認や返信ができるようになります。



Posted by Takeshi Hagikura - Developer Relations Team

[この記事は Pasha Nahass、モバイルアプリ広告プロダクト マネージャーによる Inside AdMob の記事 "Making native ads better for app developers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]

モバイル広告は急速に進化しており、デベロッパーはさまざまな広告フォーマットを使ってアプリを収益化できるようになっています。現在のユーザーは、バスを待っているときや家での「自分の時間」など、さまざまな状況でモバイル端末を使っています。そういった状況で自分の興味をそそる内容の広告が表示されれば、クリックしたくなるのではないのでしょうか。

しかし、モバイル端末の画面は小さいのが難点です。コンテンツのデザインが悪かったり、アプリが予期しない動作フローを行うと、ユーザーエクスペリエンスは損なわれます。同じことが広告にも言えます。ネイティブ広告は、アプリの世界観に合った、シームレスな広告体験を実現する方法として登場しました。これは真新しい手法ではありませんが、まだすべてのデベロッパーが取り入れているものではありません。現在のネイティブ広告ソリューションの多くは、実装に大きなリソースが必要です。規模を拡大するのは難しく、継続的な負担となる可能性もあります。デベロッパーなら誰でも、広告のために長いコードを書くよりも、アプリの新機能を作りたいと思うでしょう。

Google は、デベロッパーのためにネイティブ広告を改善したいと考えています。そして本日(*原文公開当時)、アプリ内でネイティブ広告を簡単に実装できるAdMobネイティブ広告エクスプレスを皆様にご提供できる運びとなりました。ネイティブ広告エクスプレスの特長は次のような点です。

  • ご利用方法がとても簡単です。AdMobの管理画面内、ネイティブ広告エクスプレスのインターフェースにご用意のあるサンプルよりテンプレートを選択し、カスタマイズすることで、5分もかからずにネイティブ広告を作成することができます。「エクスプレス」という名前がついているのはそのためです。アプリに実装するコード分量は最小限に留められており、バナー広告の実装に必要なコード分量と変わりません。
  • すぐに広告配信することが可能です。ネイティブ広告は作成したその日にローンチし、広告配信を開始することができます(アプリがアプリストアで承認され次第)。Google は高度な技術によって広告のカスタマイズを検証し、ユーザーに良質な体験を提供できるガイドラインに沿った広告が提供されるようにしています。
  • いつでも簡単に最適化ができます。AdMob管理画面より、テンプレートのカスタマイズや微調整、デザイン変更などネイティブ広告エクスプレスの仕様変更を行い、プレビュー、変更を反映させた広告リリースまで、アプリのコードを書き換えることなく実現可能です。ネイティブ広告のベータ版をご利用頂いたデベロッパーの中には、別の広告フォーマットより CTR(クリックスルー率)が最大 4 倍向上した事例もあります。



ネイティブ広告エクスプレス インターフェースで広告のサイズを選択し、色をカスタマイズ

Linghit Limited や Cheetah Mobile のような多数のユーザーを抱えるデベロッパーが既に AdMob のネイティブ広告で成功しています。中国暦を使ったカレンダーアプリShunli を開発した Linghit Limited は、定評のある良質なユーザーエクスペリエンスを損なわない、アプリ収益化の方法を探していました。そこで AdMob のネイティブ広告エクスプレスを実装したところ、日々の広告収入が 100% 増加し、インプレッションも 114% 向上しました。

「ネイティブ広告は今まで以上に直感的なので、アプリの中の目立つ部分に実装しました。ユーザーのクリックスルー率がどう変化したかは、広告のバックエンド情報からリアルタイムで確認できました。そのため、短期間でネイティブ広告の最適化を行い、広告収益を最大化することができたのです」
- Linghit Limited 副社長、Jinnee Lee
Cheetah Mobile は人気のあるBattery Doctor アプリに AdMob のネイティブ広告を導入することによって、広告収入が 4 倍に増加しています。

Cheetah Mobile の Battery Doctor アプリに表示されている AdMob ネイティブ広告

Linghit Limited や Cheetah Mobile がネイティブ広告でアプリを収益化した方法の詳細は、ビデオ ケーススタディに掲載されています。まだネイティブ広告を導入されていない方は、是非こちらの導入ガイドをご参照ください。

AdMobはデベロッパー皆様のアプリ収益化を支援しており、現在、100万以上のアプリにて導入され、たくさんのデベロッパーにご好評いただいています。そして広告主は、このGoogleの巨大なアプリのネットワークを活用することで、モバイル端末に時間を費やしている見込み顧客に効果的にアプローチすることができるのです。


Posted by Posted by Rikako Katayama - AdMob Team

[この記事は Shanea King-Roberson(Twitter: @shaneakr、Instagram: @theshanea)、リード プログラム マネージャーによる Android Developers Blog の記事 "Introducing the Android Basics Nanodegree" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]




アプリのアイデアはあるのに、どこから着手すればよいかわからないということはありませんか。世界中には 10 億台以上の Android 端末が存在し、皆様のアイデアはしかるべきユーザーにしかるべきタイミングで提供できます。Google は Udacity と提携し、誰でも Android 開発に触れ、それを理解できるようにする取り組みを行っています。これによって、どのような背景の人でも、アプリの構築方法を学び周囲の人の生活を改善できるようになります。

新しく誕生した Android Basics Nanodegree にご登録ください。一連のコースとサービスによって、シンプルな Android アプリの構築方法を学ぶことができます。プログラミングの経験がわずかであっても、まったくなくても大丈夫です。Android Basics Nanodegree で学んだ方が構築したアプリをいくつか紹介しましょう。

Arpy Vanyan 氏が作成した「ROP Tutorial」は、失明に至る可能性もある未熟児網膜症と呼ばれる新生児の眼疾患に関する意識を喚起するアプリです。


Charles Tommo 氏は、マラリアを予防する方法を教えてくれる「Dr Malaria」というアプリを作成しました。



Google がデザインしたコースでは、アプリの構築に使えるスキルを身につけ、現実世界の問題解決につなげることができます。Android Studio(Android アプリ開発用の Google の公式ツール)を使ったアプリのユーザー インターフェースのデザインや、Java プログラミング言語を使ったユーザー インタラクションの実装を自分のペースで学べます。

このコースでは、コーヒー ショップ用の注文フォームの作り方、隠れてしまったペットを追跡するアプリ、ネイティブ アメリカンのミウォク族の言葉を学べるアプリ、世界で最近起きた地震を調べるアプリを取り上げ、順を追って学習します。コースの最後には、友達や家族と共有できるさまざまなアプリが掲載されています。

Android Basics Nanodegree を修了すると、継続して Career-track Android Nanodegree(中級デベロッパー向け)の学習に進むこともできます。Android Basics Nanodegree を修了した最初の 50 名の方には、Career-track Android Nanodegree の奨学金を得ることができるチャンスもあります。詳細や資格要件については、udacity.com/legal/scholarship をご覧ください。中級コースでは、テクノロジー企業の立ち上げにも役立つ、完成したラーニング パスが準備されています。最も重要なことは、自分やコミュニティ、そして世界に向けてでも、クールな Android アプリを作成できるようになることです。

Nanodegree を構成する各コースはすべて無償であり、オンラインで udacity.com/google から利用できます。さらに Udacity は、指導員による指導、プロジェクトの助言、学習サポート、仕事のカウンセリング、修了証明書の発行といった有償サービスも提供しています。

※Nanodegree を構成するコースのうち、Android Development for Beginners には日本語字幕がついていますが、その他のコースには字幕はなく、指導や助言、サポートなどもすべて英語で行われます。

以下のスキルを学習すると、Java プログラミング言語におけるコンピュータ サイエンスの初歩的な概念に触れることができます。
  • アプリのユーザー インターフェースを構築する
  • ユーザー インタラクションを実装する
  • データベースに情報を格納する
  • インターネットからアプリにデータを取得する
  • アプリの予期せぬ動作を特定して修正する
  • アプリをローカライズして多言語対応する
Android Basics Nanodegree プログラムに登録するには、こちらをクリックしてください。
クラスでお会いできることを楽しみにしています。


Posted by Takuo Suzuki - Developer Relations Team