ラベル Runtime Permission の投稿を表示しています。 すべての投稿を表示
ラベル Runtime Permission の投稿を表示しています。 すべての投稿を表示

ソフトウェアデザイン2月号にアンドロイドのランタイムパミッションの記事を書きました。

Software Designには、年に1回程度記事を書かせて頂いています。
現在発売中の2016年2月号には、「コミュニティメンバーが伝える Androidで広がるエンジニアの愉しみ」企画の第二回として、「Android6.0の新しいセキュリティモデル」について書かせていただきました。



ランタイムパミッションに関しては、話題が多いため、6ページという制限内では、細かい所や、あまり知られていないマニアックな点等は記載できませんでしたが、ソフトウェアデザインという雑誌は、様々な分野の方が読まれるため、あまりアンドロイドに詳しくない方でもわかるような内容になっております。



特集が、MySQLとPostgresSQLです。この辺りの古くて、でも使われている物は、新しく本になったり、ブログ等で記載する人も少ないので、最新情報をなんとなく耳に入れておくのが難しいです。そういった意味で結構うれしかったりします。

よろしければ手に取ってみてください。

ソフトウェアデザイン 2016年 02 月号




RiskFinder6.0リリース

本日、RiskFinder6.0をリリースしました。
ここでは、RiskFinder6.0で追加された機能や情報について簡単にお知らせしたいと思います。

Android6 互換モード(2):カメラAPIへのアクセスはRuntimeException

Android6.0でランタイムパミッションモデルについて、調査した事項を色々と情報共有しています。
先日の「ランタイムパミッションの互換性(1)」の記事のタイトルに1とついていますが、今回はその2で、カメラAPIの互換モードについてです。互換モードとは、一言で言えば、「Android6.0以上の端末で、インストールタイムパーミッションモデルで実行しているアプリケーションが、端末の設定画面から、特定のパーミッションをはく奪された時の事を言います。」詳しくは「ランタイムパミッションの互換性(1)」を参照してください。

結論から言えば、飛びます。カメラアプリは要修正です。Android Developer Siteでは、互換モードでは、ContentProvider系では0件を返したりして、それなりに動くと書いてありますが、何故かカメラは飛びます。


以下調査結果です。


CheckSelfPermissionの注意事項

Android 6.0(マシュマロ)でランタイムパミッションが導入され、ランタイムパミッション周りのメソッドが新規追加されました。
主に以下のメソッドに対して、アンドキュメント動作やサポートライブラリを含めると色々と注意事項があるので、個々に解説したいと思っております。

  • checkSelfPermission()
  • shouldShowRequestPermissionRationale()
  • requestPermissions()

CheckSelfPermission

 int checkSelfPermission (String permission)

アプリケーションが指定したパミッションを持っているかを判断するメソッド

  • パーミッションが取得済の場合は、PERMISSION_GRANTED
  • パーミッションが未取得の場合は、PERMISSION_DENIEDを返す。
  • 互換モードの時(設定→拒否)の場合は、PERMISSION_DENIED_APP_OPを返す。(PermissionChecker.checkSelfPermissionのみ)
(※ 互換モードに関しては、ランタイムパミッションの互換性(1)を参照してください)

またcheckSelfPermissionはクラス違いで3つ存在しそれぞれ使い分けをします。


ランタイムパミッションの互換性(1)

Android OS 6.0(Marshmallow)でランタイムパーミッションが導入されましたが、Android OS 6.0端末を持っているのは、ほんの一握りのユーザです。現状ではAndroid6.0以下も考慮しつつアプリケーションを作成していく必要があります。
ランタイムパーミッションの互換性及び注意事項について、以下の二点に関して記載していきたいと思います。

  • 互換モードの動作
  • サポートライブラリ―

互換モードとは


互換モードとは、Android6.0以上の端末で、インストールタイムパーミッションモデルで実行しているアプリケーションが、端末の設定画面から、特定のパーミッションをはく奪された時の事を言います。(わかりにくい)

※「互換モード」という用語は、わかりにくくあまり良くない気もしますが、Developer Previewの説明でそのような記載がGoogleにあり、また良い言葉が見つからないので、互換モードという言葉を以後使いたいと思います。

まず、TargetSdkVersionと実行環境とインストールタイムパーミッションモデルとランタイムパーミッションモデルについておさらいをしたいと思います。


AndroidDevSiteの記載間違っていたので、PermissionGroupとPermissionの対応表作りました。

Android M Developer Preview時代に、パミッショングループの記事「Android M Permission-Groupの大抜擢」を書きました。Android 6.0になりなんとなくどうなっていたのかは把握していたのですが、あれ?どうだったっけ?という項目があり、Android Developer Siteの何処にかいてあるかなー!?と調べてみたら。開発→APIガイド→SystemPermissionsのPermission Groupsの所にパミッションとパミッショングループの対応表が載っていました。
が!しかし、USE_FINGERPRINTが載ってません...
このページ信用できないじゃんと思い、Nexus6に落ちてきたイメージから情報を取ったので置いておきます。(どちらかというと、自分の備忘です)

adb shell pm list permissions -g -u

の結果です。
色を変えてある所が、Developer Siteの記載との違いです。


Permisson GroupPermissions
CALENDARREAD_CALENDAR

WRITE_CALENDAR
CAMERACAMERA
CONTACTSREAD_CONTACTS

WRITE_CONTACTS

GET_ACCOUNTS
LOCATIONACCESS_FINE_LOCATION

ACCESS_COARSE_LOCATION

CAR_SPEED
PHONEREAD_PHONE_STATE

CALL_PHONE

READ_CALL_LOG

WRITE_CALL_LOG

ADD_VOICEMAIL

USE_SIP

PROCESS_OUTGOING_CALLS
SENSORSBODY_SENSORS

USE_FINGERPRINT(Normal)
SMSSEND_SMS

RECEIVE_SMS

READ_SMS

RECEIVE_WAP_PUSH

RECEIVE_MMS

READ_CELL_BROADCASTS
STORAGEREAD_EXTERNAL_STORAGE

WRITE_EXTERNAL_STORAGE
MICROPHONERECORD_AUDIO
com.google.android.gms.permission.
CAR_INFORMATION
CAR_VENDOR_EXTENSION

CAR_MILEAGE

CAR_FUEL
USE_FINGER_PRINTが抜けてたのと、MICROPHONEグループのRECORD_AUDIOも抜けてました。

また、USE_FINGERPRINTは、ProtectionLevel Normalとなっておりますので注意してください
他のパミッションは全てdangerousです。

 CAR_INFORMATIONは、googleのグループなのでcom.google.android.gms.permission.ですが
その他は、android.permission-groupが頭につきます。

uses-permission-sdk-23はないやろと思った件

Android M Preview版のドキュメントで<uses-permission-sdk-m>というのがあり、最後までドキュメントから消えなかったのですが、Android 6.0としてリリースされた時にPreviewの説明ページと共になくなりました。良かった、良かったと思っていたら、<uses-permission-sdk-23>という物がこっそりと入っていました。
http://developer.android.com/intl/ja/guide/topics/manifest/uses-permission-sdk23-element.html

    <uses-permission-sdk-23 android:name="string"
            android:maxSdkVersion="integer" />

<uses-permission>は、マニフェスト内でパミッションを利用宣言するに使われます。
<uses-permission-sdk-23>は、一言で言うとAPI Level23(Android 6.0)以上で有効になるパミッションを利用宣言する時に使用します。23未満だと、そんな単語しらないという事でシステムで無視されます。
Android M Previewの時にあった、<uses-permission-sdk-m>が名前変わっただけで残っていました。


プロテクションレベルの歴史とAndroid 6.0での変更点

Android6.0でパミッションモデルの大きな変更が加わりました、その中でINTERNETパミッションのプロテクションレベルがDANGEROUSからNORMALに変更されるなどパミッションのプロテクションレベルの再調整も行われました。

パミッションのプロテクションレベルの変更だけではなく、プロテクションレベルの値の持ち方も変更になりましたので、簡単に解説したいと思います。只開発に役立つか?というと、特殊な領域やっている開発者以外は殆ど役立たない小ネタ知識なので、頭の隅にでもおいておいてもらえたらと思います。

PermissionInfoクラス


PermissionInfoというパミッション情報を纏めるクラスがありますが、Developer Siteを見ると、Android6.0になり記載事項が多くなっておりかなり変更があるように感じられます。実際追加された値も多くなっています。




Permissions Best Practices 翻訳

Android Developer Siteのトレーニングページ、Working With System Permissionの最後のページの翻訳になります。

本ブログ内のトレーニング翻訳ページをまとめると以下となります。

Working with System Permissions 翻訳


Permissions Best Practices


パミッションの要求機能により、ユーザを失望させるのは簡単です。
ユーザが、アプリのイライラする点を見つけたり、ユーザ情報で何かやっているのではと心配している場合は、ユーザはアプリケーションを使わないようにしたり、また完全にアンインストールする事ができます。
次のベストプラクティスを使用すると、悪いユーザエキスペリエンスを回避する事ができます。

Consider Using an Intent


(パミッションの必要な)タスクをアプリケーションで実行する場合、多くの場合2つの方法のどちらかを選択する事ができます。
一つは、ユーザにパミッションの許可をもらい自分自身で実装する方法
もう一つは、インテントを用いて他のアプリケーションにその機能を実行される方法です。

例えば、アプリケーションでカメラで写真を撮る事ができるようにする必要があるとします。
あなたのアプリは、カメラに直接アクセスできるCAMERAパミッションを要求します。
あなたのアプリは、カメラAPIを使用し、カメラをコントロールし、写真を撮ります。
このアプローチは、写真を撮るプロセス全てをコントロールする事ができ、カメラのUIを組み込む事ができます。

一方、このような完全なコントロールを必要としない場合、ACTION_IMAGE_CAPTUREインテントを用いて写真を要求する事ができます。
このインテントを投げた時、システムはカメラアプリ選択画面をユーザに表示します(デフォルトカメラアプリが設定されていない場合)
ユーザは選択したアプリで写真を撮影しアプリケーションはアプリケーションのonActivityResult()メソッドで写真を返します。

同じように、電話をかける必要がある場合、ユーザの連絡先にアクセスする場合も、インテントを作成するか、パミッションを要求して直接オブジェクトをアクセスする2種類の方法があります。各アプローチには長所と短所があります。

パミッションを使用する時


  • あなたが実現したいユーザエキスペリエンスを完全に実現できます。しかしながら、適切なUIを設計する必要があるので、広範囲の制御が必要になり複雑になります。(訳注:バグが入り込む可能性が高くなり、工数も増えます)
  • ランタイムパミッション、インストールパミッションのどちらかにせよ(ユーザのアンドロイドバージョンに依存)、ユーザは一度パミッションを許可する必要があります。その後アプリはユーザとの何らかの追加の操作を必要とせずに処理を進める事ができます。しかしながら、ユーザが許可を与えなかった場合(また、後から設定画面から許可の取り消しもできます)アプリケーションは、パミッションに関わる全ての機能を実行できなくなります。

インテントを使用する時


  • UI設計をする必要がありません。インテントを受け取るアプリがUIを提供します。しかしながらこれは、ユーザエキスペリエンスを制御できない事を意味します。ユーザはあなたが知らないアプリを操作します。(訳注:第三者のアプリのバグを自分のアプリのせいにされる可能性もあります)
  • ユーザがインテントを処理するデフォルトアプリを設定していない場合、システムはアプリを選択するダイアログを表示します。ユーザがデフォルトアプリを指定しない場合、操作を実行する毎に同じダイアログが表示され煩雑になります。

Requesting Permissions at Run Time 翻訳

Android Developersサイトにあるトレーニングページの翻訳です。
今回は、Android6.0で導入されたRun Time Permissionの解説そのものになります。

Requesting Permissions at Run Time

URL: http://developer.android.com/intl/ja/training/permissions/requesting.html

アンドロイド6.0(API Level23)からアプリケーションのインストール時ではなく、実行時にパミッションを付与するようになりました。
このアプローチは、インストール、アップデート時にパミッションを付与する必要がないので、アプリのインストールプロセスが合理化されました。
また、これにより、ユーザはアプリケーションの機能をより詳細に制御できます。例えばカメラアプリに対して、位置情報の権限は与えずにカメラ機能へのアクセスのみ与えるといった事ができます。
また、ユーザは、アンドロイドの設定画面に移動して、任意のタイミングで、アプリに付与したパミッションを取り消す事ができます。


システムパミッションは、「Normal」「Dangerous」の二つのカテゴリ(Protection level)に分類されます。

  • Normal Permissionは、ユーザのプライバシーに直接危険がない物です。アプリのマニュフェストファイルに、ノーマルパミッションの利用宣言をした時、システムは自動的にそれらのパミッションの権限を付与します。
  • Dangerous Permissionは、ユーザの機密データにアクセス権を与える事ができます。アプリのマニュフェストファイルにノーマルパミッションの利用宣言をした時、システムは自動的にそれらのパミッションの権限を付与します。デンジャラスパミッションは、ユーザが明示的にアプリに許可を与えます。
さらに詳しい情報は、「Normal and Dangerous Permissions」を参考にしてください。

アンドロイドの全てのバージョンで、アプリケーションは、アプリケーションで使用するNormal,Dangerous両方のタイプのパミッションをマニュフェスト上に利用宣言する必要があります。(「Declaring Permissions」で説明したように)
しかしながら、その宣言の効果は、システムのバージョンとアプリケーションのtarget SDKレベルに応じて異なります。

Android5.1以下の場合か、アプリのTargetSDKが22以下の時:

マニュフェストに記載されたDangerousパミッションは、ユーザがアプリをインストール時に権限を付与する必要があります。権限を付与したくない場合、システムはアプリをインストールしません。
(訳注:アップデートインストール時も考慮した説明になっている)

 Android 6.0以上の場合、かつアプリのTargetSDKが23以上の時

アプリは、マニュフェストにパミッションの記載をしており、アプリケーションが動作中に必要な時にDangerousパミッションの利用許可も求めます。ユーザはそれぞれのパミッションに対して、許可・不許可がする事が可能で、ユーザがパミッションを不許可にした場合でも、限られた範囲の中で動作し続けるようにします。

NOTE:
このレッスンでは、API Level23以上での新しいパミッション要求の実装をし、アンドロイド6.0(API Level23)以上のデバイスで実行している場合の方法について説明します。デバイス、アプリ、tartgetSdkVersionが22以下の場合、システムはインストール時及びアップデート時に、全てのDangerousパミッションの権限の付与をユーザに要求します。
 このレッスンでは、アンドロイドのサポートライブラリを用いて、パミッションのチェック、要求する方法について説明します。アンドロイドのフレームワークは、Android6.0(API Level23)と同様のメソッドを提供します。アプリケーションは、実行しているアンドロイドのバージョンをチェックする必要はありませんので、サポートライブラリを利用すると簡単になります。

Check For Permissions


あなたのアプリがDangerousパミッションを必要とする時、そのパミッションを必要とする操作を実行するたびに、その権限を持っているかを確認する必要があります。
これは、ユーザは何時でも自由に権限を取り消す事が出来るからです。アプリは昨日カメラ機能を使ったとしても、今日そのカメラパミッションを持っているとは限りません。
(訳注:システム設定で、アプリケーションからパミッションの許可を取り消すことが可能。アプリケーションが動作している時でも、タスク切り替えによりパミッションの許可を取り消す事が可能な事に注意する事)

パミッションを持っているかのチェックは、ContextCompat.checkSelfPermission()メソッドを使用します。
例えば以下のスニペットは、アクティビティがカレンダーへの書き込みのパミッションを持っているかをどのようにチェックしているかを表しています。

// Assume thisActivity is the current activity
int permissionCheck = ContextCompat.checkSelfPermission(thisActivity,
        Manifest.permission.WRITE_CALENDAR);

アプリケーションがWRITE_CALENDARパミッションを持っている場合、このメソッドはPackageManager.PERMISSION_GRANTEDを返し、アプリはカレンダーへの書き込み処理を続行できます。
アプリケーションがWRITE_CALENDAR権限を持っていない場合は、メソッドは、PERMISSION_DENIEDを返し、アプリは、ユーザに明示的にパミッションの使用許可を求めていきます。

 Request Permissions

マニュフェストに記載したDangerousパミッションが必要な時は、ユーザに許可を依頼する必要があります。
アンドロイドにはパミッションのリクエストをするためのいくつかのメソッドが用意されています。
これらのメソッドを呼び出すと、標準のアンドロイドダイアログが表示されます。これらのダイアログはカスタマイズをする事ができません。

Explain why the app needs permissions

いくつかの状況では、あなたのアプリがパミッションを何故必要とするのかをユーザが理解するさせたい事があります。
例えば、ユーザが写真撮影アプリを起動した時、そのアプリがカメラパミッションを要求したとしても驚かないでしょう。しかし、場所や連絡先データへのアクセスを要求した時、その理由はユーザにはわからない場合があります。
従って、権限を要求する前に、ユーザへの説明を提供する事を検討すべきです。
ユーザを圧倒するほど説明をしないように注意してください。あまりに多くの説明を提供している場合、ユーザはアンインストールして別のアプリにしてしまう事があります

説明を提供する一つの手法としては、ユーザが一度パミッションの使用を拒否した時にのみ説明を提供する事です。
ユーザが許可要求を拒否し、チェックボックス「今後は使用しない(Never Ask Again)」にチェックをしていない時は、おそらくアプリがそのパミッションを必要とする理由をユーザが理解していない事を示しています。
そのような状況で、説明を表示する事をお勧めします。

このような、ユーザが説明を必要としているかもしれない状況を見つけるために、アンドロイドはユーティリティメソッドshouldShowRequestPermissionRationale()を用意しています。
このメソッドは、以前にこの権限を要求し、ユーザが要求を拒否した場合、trueを返します。

NOTE:
ユーザがパミッションの要求を拒否し、チェックボックス「今後は使用しない(Never Ask Again)」にチェックを入れたとき、このメソッドはfalseを返します。
このメソッドは、デバイスポリシによりアプリがこのパミッションを持つのを禁止している場合falseを返します

 Request the permissions you need

 アプリが必要な権限を持っていない場合。アプリケーションは、適切なパミッションを要求するためにrequestPermissions()メソッドを呼び出す必要があります。
requestPermissions()メソッドには、取得したいパミッション(複数可)と許可要求を識別するための「リクエストコード」と呼ばれるIntegerの値を渡します。
このメソッドは非同期です:このメソッドはユーザが、ダイアログボックスに応答した後すぐに帰ってきます。システムはアプリケーションのコールバックメソッドを結果と、requestPermissions()メソッドに渡したリクエストコードを付けて呼び出します。

 以下のコードは、アプリは、ユーザの連絡先の読み取り権限を持っているかをチェックし、必要であれば読み取り権限を取得します

// Here, thisActivity is the current activity
if (ContextCompat.checkSelfPermission(thisActivity,
                Manifest.permission.READ_CONTACTS)
        != PackageManager.PERMISSION_GRANTED) {

    // Should we show an explanation?
    if (ActivityCompat.shouldShowRequestPermissionRationale(thisActivity,
            Manifest.permission.READ_CONTACTS)) {

        // Show an expanation to the user *asynchronously* -- don't block
        // this thread waiting for the user's response! After the user
        // sees the explanation, try again to request the permission.

    } else {

        // No explanation needed, we can request the permission.

        ActivityCompat.requestPermissions(thisActivity,
                new String[]{Manifest.permission.READ_CONTACTS},
                MY_PERMISSIONS_REQUEST_READ_CONTACTS);

        // MY_PERMISSIONS_REQUEST_READ_CONTACTS is an
        // app-defined int constant. The callback method gets the
        // result of the request.
    }
}
 NOTE:
アプリがrequestPermissions()を呼び出した時、システムはユーザに標準のダイアログボックスを表示します。
あなたのアプリは、このダイアログボックスを変更したり、他の物に変える事はできません。
もし、ユーザに(パミッションについての)情報や説明を提供する必要があれば、requestPermissions()を呼ぶ前に何故アプリがパミッションを必要とする理由を説明してください。

 Handle the permissions request response

 アプリがパミッションを要求すると、システムはユーザにダイアログボックスを表示します。
ユーザがダイアログボックスに応答(許可・不許可等)すると、システムは、ユーザの応答結果と共にアプリケーションのonRequestPermissionsResult()メソッドを呼び出します。
アプリは権限が付与されたかどうかを確認するために、onRequestPermissionsResult()をオーバーライドする必要があります。
コールバックには、requestPermissions()に渡された同じ「リクエストコード」が渡されます。


例えばアプリがREAD_CONTACTSへのアクセスを要求する場合。以下のようなコールバックメソッドを実装する必要があります。

@Override
public void onRequestPermissionsResult(int requestCode,
        String permissions[], int[] grantResults) {
    switch (requestCode) {
        case MY_PERMISSIONS_REQUEST_READ_CONTACTS: {
            // If request is cancelled, the result arrays are empty.
            if (grantResults.length > 0
                && grantResults[0] == PackageManager.PERMISSION_GRANTED) {

                // permission was granted, yay! Do the
                // contacts-related task you need to do.

            } else {

                // permission denied, boo! Disable the
                // functionality that depends on this permission.
            }
            return;
        }

        // other 'case' lines to check for other
        // permissions this app might request
    }
}
 システムによって表示されるダイアログボックスは、アプリケーションが必要とするパミッショングループを表示します。(訳注:パミッションを指定するが、パミッショングループが表示されます)
指定したパミッションは表示されません。例えばREAD_CONTACTSパミッションを要求した時、システムダイアログは、「連絡先へのアクセスの許可を付与しますか?と表示します。
ユーザは、各パミッショングループに1度だけアクセス許可を与える必要があります。
あなたのアプリが、パミッショングループ内の他のパミッションを要求し許可された場合(もちろんアプリのマニュフェストには記載済の事)、システムは自動的にアクセス権限を付与します。
パミッションを要求すると、システムはアプリのonRequestPermissionsResult()コールバックメソッドにPERMISSION_GRANTEDを渡して呼び出します。これはユーザがあなたのリクエストに応じてシステムダイアログで許可を与えた事を表します。

NOTE:
アプリは同じグループに所属している場合であっても、全てのパミッションを要求する必要があります。
パミッションのグループ化は、将来のアンドロイドのリリースで変更される事があります。
あなたのコードは、特定のパミッションが同じグループに所属しているか、いないかの前提に依存すべきではありません。
(訳注:同じグループに所属しているので、requestPermissions()にREAD_CONTACTSだけ指定すれば良いといった方針は間違いで、将来WRITE_CONTACTSがコンタクトグループの所属から外れる事も考えられるので(例ですが)ちゃんと全てリクエストするようにしてくださいという事)
例えば、アプリケーションのマニュフェストファイルにREAD_CONTACTSとWRITE_CONTACTSが記載されているとします。
READ_CONTACTSのパミッションを要求し、ユーザがその許可を与え、次にWRITE_CONTACTSのパミッションを要求した場合、ユーザによる許可は必要とせずにすぐにその権限を付与します。

ユーザがパミッションの要求を拒否した場合も想定して、アプリケーションは適切な処理をする必要があります。
例えば、何故ユーザが要求した機能を実行できないのか理由を説明するダイアログを表示する事もあるでしょう

システムがユーザにパミッションの許可を求める時、「今後は使用しない(Never Ask Again)」チェックボックスをオプション表示します。チェックされた時、requestPermissions()を使用してパミッションを再度要求しても、システムはその要求を拒否します。その後システムによって呼ばれるonRequestPermissionsResult()メソッドにPERMISSION_DENIEDが渡されます。この値はユーザが明示的にUI上で拒否した時の値と同じです。
これは、requestPermissions()した時に、ユーザが直接明示的にUI上で拒否をしたのか、「今後は使用しない(Never Ask Again)」チェックが付いているためにUI表示されず拒否されたのか区別がつかない事を表します。

Working with Permissionチュートリアル

Declaring Permissions(パミッションの宣言) 原文
Declaring Permissions(パミッションの宣言) 翻訳


Requesting Permissions at Run Time(実行時のパミッション要求 原文
Requesting Permissions at Run Time(実行時のパミッション要求 翻訳


Permissions Best Practices(ベストプラクティス)原文
Permissions Best Practices(ベストプラクティス)翻訳

Declaring Permission 翻訳

本日Nexusのイメージが公開されました。早速ダウンロードして入れて見ましたが、これでようやく最終的なAndroid 6.0の動作確認の検証ができます。
パミッションを実機から抜き取ったり少し大忙しです。

さて、今回は前回に引き続き、Androidの公式ページのトレーニング内にある、パミッション周りの解説ページの翻訳(超訳)です。

前回 Working with System Permission翻訳は、トップページのさらっとしたところだけでしたが、今回は、「Declaring Permissions」ということで、マニュフェストにパミッションを利用宣言する所がメインとなります。

Declaring Permissions

URL:http://developer.android.com/intl/ja/training/permissions/declaring.html

全てのアンドロイドアプリケーションは、アクセス制御されたサンドボックスの中で実行されます。
アプリケーションは、自分のサンドボックス外のリソースや情報を使用する必要がある場合は、適切な許可(パミッション)を要求する必要があります。
あなたのアプリは、Manifestファイルにパミッションを記述する事で、アプリケーションがそれらのパミッションを必要とすることを宣言します。

どれぐらいセンシティブな情報を扱うパミッションであるか(Normal,Dangerous)によって、システムは自動的にパミッションを許可したり、デバイスユーザ(Device Admin)が要求を許可する場合があります。
例えば、あなたのアプリが、デバイスのフラッシュライトをONにする権限をリクエストした時、システムは自動的にその権限を付与します。
アプリがユーザの電話帳を読む必要がある場合、システムはユーザにそのパミッションを許可するようユーザに要求します。(システムが勝手に許可をしない)
実行環境のバージョンによって、ユーザは、アプリケーションのインストール時(Android 5.1以下)、アプリケーションの実行時(Android 6.0以上) のいずれかの方法で許可を与えます



Working with System Permissions 翻訳

Android 6.0(API Level23)で導入された、Runtime Permissionの説明は、トレーニングページと、API Guideの方に正式版として記載されました。
トレーニングページの方は、あれ?こんな所に解説ページあったんだと、皆さんきっと見落とし?あるかと思いますので、トレーニングページ上でのパミッション説明ページの翻訳及び解説を展開していきたいと思います。



Working with System Permissions


URL: http://developer.android.com/training/permissions/index.html

システムの整合性とユーザのプライバシーを保護するために、アンドロイドはそれぞれのアプリケーションをアクセス制限されたサンドボックス内で動かします。 アプリケーションがサンドボックス外のリソースや情報が欲しい時、アプリケーションは明示的にそのパミッションを要求する必要があります。 アプリケーション要求したパミッションの種類に応じて、システムが自動的に許可を与えるか、システムがユーザに許可を与えるように求めます。 このクラス(Javaのクラスの事ではなくて)は、アプリケーションでどのように宣言するのか、パミッションの要求をするのかを示します。

Lessons


Declaring Permissions(パミッションの宣言)

Manifestファイル内にどのようにパミッションの利用宣言をするのか学びます。

Requesting Permissions at Run Time(実行時のパミッション要求)

アプリケーション実行時に、どのようにユーザにパミッションの要求をするのか学びます。
このレッスンはAndroid6.0(API Level23)以上の環境での動作のみです。

Permissions Best Practices(ベストプラクティス)

パミッションの要求とアクセス権を資料した、最高のユーザエクスペリエンスを作成するためのガイドライン

最後に

本日はこれだけです。(このページは、殆ど外部に公開してないので、少量でも気楽です)明日からは順に、パミッションの宣言、実行時のパミッション要求、ベストプラクティスと進んでいきたいと思います。何日続くでしょうか...





Android 6.0 Changes : Runtime Permissions 翻訳

2015年9月29日に開催されたGoogleの新製品発表イベントで、新端末Nexus5X, Nexus6P等が発表されました。去年はNexus6が発表されましたが、端末が大きくて普段使いには非常に使いにくいため、Nexus5を使ったり、時々浮気して違う端末を使って、またNexus5を使うといった、Nexus5メインの使い方でした。待望の5インチNexusなので、例年どおり?売り切れる事が予想されたので、眠い目をこすりながらリアルタイムで視聴(全然面白くない部分もありました)、購入開始と共に予約注文したのですが、現時点でもまだまだ在庫があるようです。
その後、ドコモ、Ymobileからも発売されるという事が発表され、今回は全然焦る必要はなかった模様。まぁ10月後半に届くという事なので楽しみにしております。



さて、この発表を受けて、GoogleのAndroid M Developer Previewサイトが、Android 6.0 Marshmallowサイトに変更になり、ドキュメント等も更新されました、内容をざっと見た感じでは、内容が少なくなったり、あらたに解説ページが新設されたり、不明瞭な部分が加筆されたりと、ちょこちょこ変更になりましたので、確認の意味も込めて、Android Developer Preview内のパミッション関係のページを複数回に分けて再翻訳(調訳)していきたいと思います。

Android Preview時代のパミッションに関する翻訳記事

翻訳の最初は、Android 6.0の変更点解説ページで、Runtime Permissionsについて記載がある部分です。プレビューの時は色々書いてあったんですが、すっきりとまとまって少量になってしまいました。