Android 6.0 (Marshmallow) では、アプリでユーザー データを適切に取り扱えるよう、いくつかの変更が加えられています。その目的は、デベロッパーが適切な動作をするアプリを簡単に作れるようにすることです。Marshmallow の普及は進みつつあるため、ぜひこの点に挑戦していただきたいと考えています。

本稿は、 実行時 パーミッションとハードウェアの識別子について、ユーザーの信頼を得るために考慮するべき事項を中心に説明しています。また、アプリの開発において目指すべき点を分かりやすく説明している 新しいベストプラクティス のドキュメントも紹介します。

パーミッションの変更

Marshmallow では、 パーミッションの許可を得るタイミングがインストール時から実行時に変更されています。 これは SDK 23 以降で強制的に適用される変更なので、Android 6.0 を対象とするすべてのアプリとすべてのデベロッパーに影響します。アプリはいずれ更新しなければなりませんが、更新は注意深く行う必要があります。

実行時パーミッションとは、アプリが実際に機密性の高い情報を使用するタイミングで、アクセスのパーミッションを要求することです。こうすることで、アプリがそのパーミッションをなぜ要求するのか、その場でユーザーに説明を提示することができるようになります。これまでのように、インストール前に要求する可能性のある情報を全部長々と提示する必要はなくなるので、ユーザーを不安にさせません。

またパーミッションはグループに分類することもできるようになったので、ユーザーは技術的な難しい専門用語を理解していなくても、内容を理解したうえでパーミッションを与えるかどうかの判断を下すことができます。決定権をユーザーにゆだねることで、ユーザーはパーミッションを与えないこともできますし、以前に付与したパーミッションを取り消すこともできます。したがって、アプリ側で特に注意が必要な点は、拒否される可能性のあるパーミッションが必要な API 呼び出しに注意することと、パーミッションが拒否されてもそれ以外のアプリの機能を使い続けることができるようにエラー処理を工夫することです。

識別子の変更点

ユーザーの信頼を得るにあたってもう 1 つ重要な点は、入力されたデータを適切に処理する必要があることです。Marshmallow では、アプリのデベロッパーに許可していたデータへのアクセスが一部無効になっています。これは、デベロッパーが直接データにアクセスすることを防ぐためです。

最もわかりやすいのは、 ローカルの WiFi や Bluetooth の MAC アドレスへのアクセスが禁止されたことです。 WifiInfo オブジェクトの getMacAddress() メソッドと、BluetoothAdapter.getDefaultAdapter().getAddress() メソッドは、今後どちらも 02:00:00:00:00:00 という値を返すことになります。

ただし、 Google Play サービスではインスタンス ID が提供されており、デバイスで実行中のアプリケーションの各インスタンスは、この ID で区別します。インスタンス ID は、リセットできない端末固有のハードウェア ID に代わる信頼性の高い ID を提供します。インスタンス ID は、端末を出荷時の設定に戻すことでリセットできます。インスタンス ID のスコープは、アプリのインスタンスです。詳細については、Google Developers サイトのインスタンス ID とはを参照してください。

次のトピック

ユーザーがあなたのアプリを信頼するかどうかは、アプリの外観とそれを見た印象によって大きく左右されます。パーミッションや識別子の処理を誤ると、開発者が望んでいない、または意図していないトラッキングが行われるリスクが高まるので、ユーザーはそのアプリに対して、ユーザーに対する配慮に欠けているという印象を持つ恐れがあります。そこで、適切に動作するアプリの開発をサポートするため、以下のドキュメントを新たに公開しました。このドキュメントを活用すると、ユーザーにとって適切な動作のアプリであるかどうかをデベロッパー自身が確認することができます。
それでは、引き続きアプリ開発をお楽しみください。ユーザーがあなたのアプリを気に入ってくれますように。またそれが、あなたのアプリのレビューの評価値に反映されますように。

Posted by Yuichi Araki - Developer Relations Team

昨年11 月のブログ記事で、パフォーマンスとユーザビリティの向上をユーザーにもたらすために、Google Cloud Messaging（GCM）が Android 6.0 Marshmallow の Doze（居眠り）モードと呼ばれる節電機能をどのように扱うかについて紹介しました。優先度が「標準」のメッセージの場合は、端末を Doze モードのままにしておき、優先度が「高」のメッセージの場合は端末を Doze モードから起こし、アクティブにするというものです。本機能の Android における好例とベストプラクティスについて、Twitter 社のエンジニアリング チームと話し合いました。

Twitter 社は、Doze モードの端末をアクティブにする、優先度「高」を付すべきメッセージはどれなのかについて徹底的にリサーチしました。Twitter 社で使う特定のニーズを満たすために、Twitter 社は、ダイレクト メッセージは優先度「高」で、メンションは優先度「標準」で配信する必要がありました。

Twitter 社の Android エンジニアリング マネージャーである Luke Millar 氏は次のように述べています。「Android M を使用するとバッテリーの寿命が伸び、良き市民としての責任を果たすことにつながります。この機能により、どの通知が Doze モードの端末をアクティブにし、どの通知がアクティブにしないかを指定できます。通常は、ユーザーの携帯端末が次回アクティブになるまでプッシュ通知の配信を保留するように GCM を設定します。ただし、ユーザーはダイレクト メッセージなどの一部のプッシュ通知を即座に受け取ることを求めているため、これらの通知には優先度を「高」に設定します。この機能は、これらの通知がユーザーに配信されるタイミングと方法を指定できるので便利です。」

Twitter 社のエンジニアは Doze モードをテストするため、Android デベロッパー サイトに記載されているステップを実行しました。このサイトには、adb コマンドを使用して物理端末または仮想端末で Doze モードをシミュレートする方法が示されています。Twitter 社はこの方法を使用して、メッセージングの優先度が実際の環境でどのように機能するかをテストできました。

また同社は、Twitter ハイライトを配信するなどの大きなペイロードの送信時にもう 1 つのベスト プラクティスを使用しました。それは、通知でメタデータを渡し、そのメタデータを使用してアプリを同期し、リクエストしたハイライトを取得するということです。言い換えると、通知でハイライトのコンテンツを送信せず、同期メカニズムをトリガーして、アプリのコンテンツをアップデートしました。

スタンバイ環境にあるアプリで GCM を使用する場合の詳細については、このドキュメントをご覧ください。

GCM の詳細と、Android、iOS、ウェブ アプリケーションで GCM を通知に使用する方法については、こちらの Google デベロッパー サイトをご覧ください。

Posted by Eiji Kitamura - Developer Relations Team

1. 設定: 非対称鍵のペアの作成

まず、次のように非対称鍵のペアを作成します。
KeyPairGenerator.getInstance(KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore");
keyPairGenerator.initialize(
        new KeyGenParameterSpec.Builder(KEY_NAME,
                KeyProperties.PURPOSE_SIGN)
                .setDigests(KeyProperties.DIGEST_SHA256)
                .setAlgorithmParameterSpec(new ECGenParameterSpec("secp256r1"))
                .setUserAuthenticationRequired(true)
                .build());
keyPairGenerator.generateKeyPair();
.setUserAuthenticationRequired(true) ã«æ³¨ç›®ã—てください。このメソッドを呼ぶことにより、秘密鍵を使用する前に、登録した指紋の認証を強制できるようになります。

次に作成した秘密鍵と公開鍵を以下のように取得します。
KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
PublicKey publicKey =
        keyStore.getCertificate(MainActivity.KEY_NAME).getPublicKey();
KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
PrivateKey key = (PrivateKey) keyStore.getKey(KEY_NAME, null);

2. 登録: サーバーへの公開鍵の登録

次に、公開鍵をバックエンドに送信し、その後のユーザの購入がユーザーによって承認されていること（この公開鍵に対応する秘密鍵によって署名されていること）をバックエンドが確認する必要があります。このサンプルでは、公開鍵の送信を模擬的に再現するためにバックエンド実装を端末上で動作する模擬コードを使用していますが、実際には公開鍵をネットワーク経由で送信する必要があります。
boolean enroll(String userId, String password, PublicKey publicKey);

3. 認証: 指紋による署名処理

商品購入などでユーザーが処理を認証できるように、指紋センサーへのタッチを促すプロンプトを表示します。
続いて、次のように指紋の読み込みを開始します。

Signature.getInstance("SHA256withECDSA");
KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
PrivateKey key = (PrivateKey) keyStore.getKey(KEY_NAME, null);
signature.initSign(key);
CryptoObject cryptObject = new FingerprintManager.CryptoObject(signature);
CancellationSignal cancellationSignal = new CancellationSignal();
FingerprintManager fingerprintManager =
        context.getSystemService(FingerprintManager.class);
fingerprintManager.authenticate(cryptoObject, cancellationSignal, 0, this, null);

4. 最終処理: バックエンドへのデータ送信と照合

認証が成功したら、次のように署名済みのデータ（このサンプルでは、購入処理の内容）をバックエンドに送信します。
Signature signature = cryptoObject.getSignature();
// Include a client nonce in the transaction so that the nonce is also signed 
// by the private key and the backend can verify that the same nonce can't be used 
// to prevent replay attacks.
Transaction transaction = new Transaction("user", 1, new SecureRandom().nextLong());
try {
    signature.update(transaction.toByteArray());
    byte[] sigBytes = signature.sign();
    // Send the transaction and signedTransaction to the dummy backend
    if (mStoreBackend.verify(transaction, sigBytes)) {
        mActivity.onPurchased(sigBytes);
        dismiss();
    } else {
        mActivity.onPurchaseFailed();
        dismiss();
    }
} catch (SignatureException e) {
    throw new RuntimeException(e);
}

最後に、ステップ 2 で登録した公開鍵を使用し、バックエンドにある署名済みデータと照合します。
@Override
public boolean verify(Transaction transaction, byte[] transactionSignature) {
    try {
        if (mReceivedTransactions.contains(transaction)) {
            // It verifies the equality of the transaction including the client nonce
            // So attackers can't do replay attacks.
            return false;
        }
        mReceivedTransactions.add(transaction);
        PublicKey publicKey = mPublicKeys.get(transaction.getUserId());
        Signature verificationFunction = Signature.getInstance("SHA256withECDSA");
        verificationFunction.initVerify(publicKey);
        verificationFunction.update(transaction.toByteArray());
        if (verificationFunction.verify(transactionSignature)) {
            // Transaction is verified with the public key associated with the user
            // Do some post purchase processing in the server
            return true;
        }
    } catch (NoSuchAlgorithmException | InvalidKeyException | SignatureException e) {
        // In a real world, better to send some error message to the user
    }
    return false;
}

ステップ 1 で述べたとおり、秘密鍵を使用する前にユーザー認証が毎回必要であるため、この時点でユーザー自身の指紋が正しく認証されているとみなすことができます。バックエンドで購入後の処理を実行し、ユーザーに処理が成功したことを通知しましょう。

その他の更新されたサンプル

その他に、 Android for Work API に関連する Marshmallow で更新された機能についてサンプルを更新しました。




  • AppRestrictionEnforcer と AppRestrictionSchema のサンプルは、Android 5.0 Lollipop の Android for Work API の一部として アプリ制限機能導入時にリリースされました。AppRestrictionEnforcer は、プロファイル オーナーとして他のアプリに制限を設定する方法について説明しています。AppRestrictionSchema は、AppRestrictionEnforcer で制御できるいくつかの制限を定義しています。この更新は、Android 6.0 で追加導入された 2 つの制限タイプの使用方法について説明しています。

    • 更新されたサンプルがデベロッパーの皆様のお役に立てればと思います。サンプルについてのご質問は、GitHub ページ ã§ Issue を登録するか、Pull Request ã‚’送っていただくようお願い致します。


    Posted by Takeshi Hagikura - Developer Relations Team


    WhatsApp のメッセージをロシア語で作成

    この機能は Android のテキスト選択機能を使用している Android アプリではすでに利用可能となっているので、追加設定などは不要です。アプリでカスタマイズしたテキスト選択機能を導入しているデベロッパーは、以下のステップで、この機能を簡単に実装できます。

    PROCESS_TEXT インテント フィルタを持つすべてのパッケージ（例: com.google.android.apps.translate - インストール済みの場合）を PackageManager でスキャンし、アプリの TextView 選択に MenuItems として追加します。
    1. Package Manager を照会するには、最初にそのアクションのインテントを作成します。 
      private Intent createProcessTextIntent() {
    return new Intent()
            .setAction(Intent.ACTION_PROCESS_TEXT)
            .setType("text/plain");
}
    2. 次に、サポート済みのアクティビティを取得します。 
      private List getSupportedActivities() {
    PackageManager packageManager =
mTextView.getContext().getPackageManager();
    return
packageManager.queryIntentActivities(createProcessTextIntent(),
0);
}
    3. 取得した各アクティビティにアイテムを追加し、インテントを付与してアクションを起動させます。 
      public void onInitializeMenu(Menu menu) {
    // Start with a menu Item order value that is high enough
    // so that your "PROCESS_TEXT" menu items appear after the
    // standard selection menu items like Cut, Copy, Paste.
    int menuItemOrder = 100;
    for (ResolveInfo resolveInfo : getSupportedActivities()) {
        menu.add(Menu.NONE, Menu.NONE,
                menuItemOrder++,
                getLabel(resolveInfo))
                .setIntent(createProcessTextIntentForResolveInfo(resolveInfo))
                .setShowAsAction(MenuItem.SHOW_AS_ACTION_IF_ROOM);
    }
}
    次のコードで各アイテムのラベルを取得できます。 
    resolveInfo.loadLabel(mPackageManager);

    各アイテムのインテントは、前に定義したインテント フィルタを再使用して不足データを追加して作成します。
    private Intent createProcessTextIntentForResolveInfo(ResolveInfo info) {
    return createProcessTextIntent()
            .putExtra(Intent.EXTRA_PROCESS_TEXT_READONLY, !
mTextView.isTextEditable())
            .setClassName(info.activityInfo.packageName, 
info.activityInfo.name);
}
    デフォルトの Android テキスト選択機能を使用していない場合、コードを 2～3 行追加するだけでアプリのテキスト選択メニューに翻訳オプションを追加できます。ユーザーが翻訳対象となるテキストを作成する場合、翻訳アプリの起動時にアプリで選択したままにしておく必要があることに注意してください。

    この新機能を使えば、Android の翻訳アプリユーザーはアプリで簡単に翻訳できるようになります。今後、この機能に関するドキュメントやサンプルコードをさらに追加していきます。

    Posted by Eiji Kitamura - Developer Relations Team


    Nexus 6P
    Nexus 5X は、LG と協力して開発されました。5.2 インチ 1080p の FHD LCD ディスプレイ、Snapdragon™ 808 プロセッサ (1.8 GHz ヘキサコア、64 ビット)、12.3 MP リア カメラを備えています。コンパクトで軽量、トップレベルのパフォーマンスを提供します。

    Huawei と協力して開発された Nexus 6P は 5.7 インチの WQHD AMOLED ディスプレイ、Snapdragon™ 810 v2.1 プロセッサ (2.0 GHz オクタコア、64 ビット)、前面ステレオ スピーカー、12.3 MP リア カメラを備えており、これらすべてがダイヤカット加工されたアルミ製ボディに収められています。

    両方の Nexus 端末には、USB Type-C ポートと指紋センサーがあり、Android Sensor Hub、チャネル選択やバッチ処理、BSSID ホットリストを備えた省電力の Wi-Fi スキャン、超省電力の BLE 通知機能を備えた Bluetooth 4.2 など、最新のハードウェア機能が搭載されています。

    アプリの準備

    これらの端末を使用するユーザーに最高のモバイル エクスペリエンスを提供するには、あらかじめアプリとゲームの状態を確認する必要があります。

    素材の確認

    解像度 画面サイズ 密度
    Nexus 5X 1920 x 1080 px (730 x 410 dp) 通常 420 dpi
    Nexus 6P 2560 x 1440 px (730 x 410 dp) 通常 560 dpi


    Nexus 5X の画面密度は 420 dpi なので、最も密度の高いバケットである xhdpi と xxhdpi の中間の解像度になります。Nexus 6P は画面密度が 560 dpi なので、xxhdpi と xxxhdpi の中間の解像度になります。プラットフォームは、密度の高い方の解像度バケットの素材をスケールダウン表示しますが、ない場合は、低い方の密度バケットの素材をスケールアップして表示します。

    ランチャーで最適な表示を行うには、大きなアプリ アイコンを表示するため、最低でも xxxhdpi のアプリアイコンを使用することをお勧めします。

    残りの素材については、ベクター素材を使用するか、オプションでさらに高い密度バケットを追加できます。これにより、画像がよりシャープになりますが、apk のサイズが大きくなってしまうので、アプリごとに適切な判断が必要です。

    Google Play でフィルタされていないことを確認

    <compatible-screens>: 要素は新しい端末が発売されるたびにアプリをリコンパイルして公開することに対応できないため、AndroidManifest.xml ファイルでこの要素を使用している場合は、使用を中止してください。Nexus 5X は新しい密度バケット (420) を使用するため、この要素を使用する必要がある場合は、マニフェストをアップデートして、Nexus 5X の新しい構成を追加するようにしてください。そうしないと、これらの端末の Google Play でアプリが除外される可能性があります。

    M デベロッパー プレビューの終了

    3 つのプレビューがリリースされ、最終 OTA リリースが間もなく公開されるため、Android M デベロッパー プレビューを終了することになりました。いただいたフィードバックのおかげで、Android 6.0 はさらにアプリとゲームに優しいプラットフォームになりました。200 以上の国のデベロッパーがこのデベロッパー プレビューを使用して、世界中の Android 6.0 Marshmallow ユーザー向けにアプリを準備しています。

    デベロッパー向けリソースがさらに豊富に

    Android 6.0 Marshmallow をまだご覧になっていない場合は、developer.android.com/mm にアクセスしてみてください。ランタイム パーミッション、Doze と App Standby のアイドル モード、アプリの自動バックアップ、指紋サポートなど、デベロッパー向けの新しい機能やアプリに関連する重要な変更について詳細を確認できます。

    またデベロッパー向けに、Android 6.0 Marshmallow の新機能の利用方法を説明した動画も作成しました。以下をご確認ください。

    最終テストとアップデート

    最終テストを行い、公開に向けた準備を進めてください。最終テストのための、デベロッパー プレビュー 3 のシステム イメージは10 月初旬まで使用できます。Android 6.0 が正式に公開されると、Nexus の出荷時のイメージ ページから最終イメージを、Android Studio から最終エミュレータ イメージをそれぞれダウンロードできます。

    お知らせ: M デベロッパー プレビュー ビルドをフラッシュした端末は、Android 6.0 アップデートを自動的に受け取りません。最初に、正式に公開されているイメージをこれらの端末に手動でフラッシュする必要があります。

    アプリを Google Play にアップロード

    アプリの準備ができたら、すべてのリリース チャンネル (アルファ版、ベータ版、製品版) のデベロッパー コンソールからアプリを Google Play にアップロードできます。API レベル 23 を対象にしているアプリの場合、Google Play は、Android 6.0 の実行時パーミッション モデルに基づいて、最適化された新しいダウンロードと自動アップデート フローを提供します。ぜひお試しください。

    アップデートされたアプリを Android 6.0 Marshmallow および以前のバージョンで正しく実行するには、Google Play の新しくなったベータ テスト機能を使用して、初期フィードバックを取得することをお勧めします。その後、新しいバージョンをすべてのユーザーに公開するときに、段階的ロールアウトを実施できます。

    次のトピック

    10 月中旬に M デベロッパー プレビュー コミュニティと M デベロッパー プレビュー Issue Tracker を終了します。プレビューのバグを登録していて、Android 6.0 の最終ビルド向けにそれらのバグを公開したままにする場合は、AOSP Issue Tracker に新しい問題を登録できます。

    Android M デベロッパー プレビューへのご参加ありがとうございました。アンケートに回答し、今年のプレビューがデベロッパーのニーズをどの程度満たしていたかをお知らせください。いただいたフィードバックは、将来のリリース計画に反映します。


    Posted by Yuichi Araki - Developer Relations Team

    明らかにパーミッションが必要な場合は事前に要求されます

    多くの場合、既存のインテント システムを使ってパーミッションを回避できます。アプリ内でフル エクスペリエンスを構築するのではなく、既存の専門アプリを活用します。例としては、独自のカメラ エクスペリエンスを構築するのではなく、ACTION_IMAGE_CAPTURE を使って、ユーザーが使いなれている既存のカメラ アプリを起動することなどです。詳細については、「パーミッションとインテント」を参照してください。

    ただし、実行時パーミッションが必要な場合は、役立つツールが数多くあります。アプリがパーミッションを付与されているかどうかの確認は、ContextCompat.checkSelfPermission()（下位互換性確認のために support-v4 ライブラリの改訂 23 の一部が利用可能）で可能です。また、パーミッションの要求は、requestPermissions() を使えば可能です。パーミッションを付与されていない場合には、システム制御パーミッション ダイアログを提示して、ユーザーがパーミッションを付与できるようにします。ユーザーはシステム設定を通じていつでもパーミッションを取り消せるため、パーミッションを毎回常に確認する必要があることを覚えておいてください。

    shouldShowRequestPermissionRationale() については、特別に注意する必要があります。「今後このメッセージを表示しない」オプション（パーミッション ダイアログが 2 回目以降に表示されるときに出てくるオプション）を選択していないにもかかわらず、ユーザーがパーミッション要求を少なくとも一度拒否した場合、このメソッドは true を返します。ここで、機能やパーミッションが必要な理由について、ユーザーに説明することができます。詳細については、アプリにパーミッションが必要な理由を参照してください。

    設計ガイドラインとデベロッパー ガイドを読み、アプリを Android 6.0 と実行時パーミッションに対応させる準備を進めてください。アプリのインストールを簡単にし、ユーザーの情報へのアクセスが必要な理由を説明できれば、より優れたアプリの開発が可能になります。

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

    アプリの自動バックアップとは

    デフォルトでは、バックアップを必要とするユーザーのために、アプリのすべてのデータ ファイルがユーザーのドライブに自動的にコピーされます。これにはデータベース、共有プリファレンス、アプリケーションのプライベート ディレクトリ内のその他のコンテンツが含まれ、アプリごとに最大 25 メガバイトに制限されます。Context.getCacheDir()、Context.getCodeCacheDir() および Context.getNoBackupFilesDir() で指定されている場所に保存されているデータはすべてバックアップから除外されます。外部ストレージ上のデータについては、Context.getExternalFilesDir() 内のデータだけがバックアップされます。

    バックアップ対象の指定方法

    バックアップ対象にすることができるアプリ データをカスタマイズするには、res/xml フォルダ内にバックアップ構成ファイルを作成し、アプリのマニフェストで参照します: 
    
<application
        android:fullBackupContent="@xml/mybackupscheme">
    構成ファイルで、デフォルトのバックアップ エージェントの動作を微調整するために必要な <include/> ルールまたは <exclude/> ルールを指定します。このドキュメントに記載されている、ルールの構文の詳細説明を参照してください。

    バックアップから除外する内容

    特定のアプリ データは、バックアップの対象とすることができません。このようなデータについては、上記のメカニズムのいずれかを使用してください。例:
    多種多様なアプリが存在することを考えると、開発者にとって重要なのは、自動バックアップがもたらすユーザーへのメリットをどうしたら最大限にできるか、を検討することです。目標は、新しいデバイスの設定の手間を省くことです。ほとんどの場合、これはユーザーのプリファレンスやローカルに保存されたコンテンツを転送することを意味します。

    たとえば、インストール時に復元できるよう共有プリファレンスに保存されたユーザーのアカウントがある場合、ユーザーは、以前のサインイン時に使用したアカウントについて考える必要さえなく、パスワードを送信して続行することができます!

    さまざまなログイン (Google サインインやその他のプロバイダー、ユーザー名/パスワード) をサポートする場合、以前に使用したログイン方法を容易に記憶できるため、ユーザーがそのような情報を覚えておく必要がありません。

    主要/重要なバックアップからの移行

    従来の主要/重要なバックアップを、BackupAgent をサブクラス化してマニフェスト (android:backupAgent) で設定することによって実装していた場合、完全なデータのバックアップに移行するのは非常に簡単です。単に android:fullBackupOnly="true" 属性を <application/> に追加するだけですみます。これは M バージョンより前のバージョンの Android では無視されます。つまり、onBackup/onRestore は呼び出されますが、M+ デバイス上では、独自の BackupAgent を提供しながら完全なデータのバックアップを使用したいという意向がシステムに通知されます。

    主要/重要なバックアップを使用せず、onCreate(), onFullBackup() でカスタム処理を実行する場合や、onRestoreFinished() でのリストア処理の発生時に通知を受け取る場合でも、同じアプローチを使用できます。XML の include/exclude ルールの実装を保持する場合は、super.onFullBackup() を呼び出すことを忘れないでください。

    バックアップ/復元のライフサイクル

    データの復元は、ユーザーがアプリを起動できるようになる前に、パッケージのインストールの一部として実行されます。デバイスの充電中に Wi-Fi に接続されている場合、1 日に 1 回バックアップが実行されます。アプリがデータの制限 (現在は 25 MB に設定されている) を超えた場合、その後のバックアップは実行されず、最後に保存されたスナップショットがその後の復元に使用されます。アプリのプロセスが bmgr コマンドを使用して手動で開始された場合、完全なバックアップの実行後、復元の前に、そのプロセスが停止されます (詳細については、以下を参照)。

    今すぐアプリをテスト

    自動バックアップのテストを開始する前に、デバイスまたはエミュレータに最新の M Developer Preview が存在していることを確認してください。APK をインストールした後で、adb shell コマンドを使用して bmgr ツールにアクセスしてください。
    Bmgr はバックアップ マネージャーの操作に使用できるツールです。
    bmgr run を起動することを忘れた場合、fullbackup コマンドや restore コマンドを試行したときに Logcat にエラーが表示されることがあります。問題が解決しない場合は、バックアップが有効になっていて、システムの [設定] > [バックアップとリセット] で Google アカウントが設定されていることを確認してください。

    詳細はこちらから

    GitHub で、自動バックアップの使用方法を示すサンプル アプリケーションを検索できます。完全なドキュメントは developer.android.com で入手できます。

    Android M 機能の詳細を参照するには、Google+ Android M Developer Preview Community に参加してください。自動バックアップでバグを見つけた場合、Bug Tracker での報告をお願いします。


    Posted by Ryuichi Hoshi - Developer Relations Team
    Share on Twitter Share on Facebook


    袋から出してそのままでも、炙って表面はきつね色、中はとろとろにしてあげても、あるいはマシュマロクリームでも、マシュマロが嫌いな人なんているでしょうか。私たちは大好きです！ 5 月に開催された Google I/O で Android M Developer Preview を公開して以来、多くの開発者からのたくさんのフィードバックをいただき、それらを反映させてきました。本日、 M Developer Preview 最終版へ更新するとともに、公式に Android 6.0 SDK を公開し、 Google Play においても Android Marshmallow 向けに新しい API Level 23 をターゲットとしたアプリを公開可能となりました。

    アプリを Android Marshmallow 対応にしましょう

    Android 6.0 SDK 最終版は Android Studio の SDK Manager 経由でダウンロード可能です。 Android 6.0 SDK では、最終版 Android M API と最新のビルドツールを利用し、API Level 23 をターゲットとして開発していただけます。Android 6.0 SDK を Android Studio にダウンロードし、プロジェクトの compileSdkVersion  ã‚’ 23 に更新すれば、すぐに最新の Android M プラットフォームでのアプリの動作を検証できます。 また targetSdkVersion  ã‚’ 23 に更新することで、自動バックアップや新しいパーミッション機能のような API Level 23 から利用できる機能の動作をお試しいただけます。

    Android 6.0 SDK にあわせて Android Support Library も v23 に更新しました。新しい Android Support Library を使用することで、後方互換性を保った上で新しいパーミッションモデルや指紋認証のサポートなど新しい API を簡単に組み込むことができます。今回のリリースでは customtabs、 percent、 recommendation、 preference-v7、 preference-v14、 preference-leanback-v17 など新しいライブラリが多く追加されています。

    アプリのパーミッションを確認しましょう

    指紋認証 API や Doze 省電力モードといった新しい機能とともに、 Android Marshmallow ではアプリのインストールやアップデートのユーザー体験をよりスムーズにする新しいパーミッションモデルが提供されています。Android Marshmallow のユーザは、状況に応じて柔軟にアプリの特定のパーミッションを無効にすることができます。このときもあなたのアプリが問題なく動作できるよう、アプリのターゲット API を 23 にして、 Android Marshmallow ユーザーとしての幅広い動作テストを実施してください。

    M Preview ビルドの取得方法について

    お手元の端末で動作検証していただくために、Android エミューレーターシステムイメージと Developer Preview システムイメージの最新版を Nexus端末（Nexus 5 、Nexus 6 、Nexus 9 そして Nexus Player ）向けに公開しました。デバイスシステムイメージは Developer Preview のサイトからダウンロードできます。また、過去の開発者向けアップデートと同様、すでに M Preview を実行中の Nexus 端末に対しては数日以内に Over-the-Air (OTA) 配信を予定しています。

    Android 6.0 SDK は最終版ではありますが、デバイスシステムイメージは引き続き Developer Preview 版と呼ばれています。 Developer Preview イメージは Android M 最終版にほぼ近いものではありますが、一般消費者向けではありません。 一般消費者向け OTA をお手元の Nexus 端末で受信し続けるためには、 Android 6.0 Marshmallow が今秋後半に公開されたときに、手動で端末に工場出荷時イメージを再度フラッシュする必要があることにご留意ください。

    最新情報


    Android Marshmallow 対応のアプリを Google Play にアップロードする

    Google Play では API Level 23 のアプリを Google Play Developer Console から、すべてのリリースチャンネル（アルファ、ベータ、プロダクション）に提供していただけるようになりました。今秋の一般利用者向けリリースとあわせて予定されている Google Play ストアの更新により、アプリのインストールと更新の処理が API Level 23 を使っているアプリ向けの新しいパーミッションモデルに対応します。

    API Level 23 に対応したアプリが確実に Android Marshmallow と従来の Android バージョンで動作するようにしましょう。 Google Play の最近改善したベータテスト機能を使って、一般公開する前にフィードバックを集め、段階的なロールアウトを実施しながら最新版をすべてのユーザーに公開していただくことをおすすめします。

    Posted by Yoshifumi Yamaguchi - Developer Relations Team
    Share on Twitter Share on Facebook