RiskFinder6.0リリース

A+ a-

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

Android6 互換モード(3) コンテントプロパイダーの動作

A+ a-

互換モード:「Android6.0以上の端末で、インストールタイムパーミッションモデルで実行しているアプリケーションが、端末の設定画面から、特定のパーミッションをはく奪された時」の動作確認記事三本目です。
連絡先アクセス(コンテントプロパイダー経由)での動作を調査してみました。
結論としては、読み込み時は取得したCursorのsizeが0となりあまり影響はないといった感じです。

以下調査結果です。

Android6.0で削除、追加されたパーミッション(最終版)

A+ a-

Android 6.0で変更になったパーミッションに続いて、削除、追加されたパーミッションです。
前回と同じく、Nexus5X,Nexus6Pで吸い出した物です。


Android 6.0でプロテクションレベルが変更になったパーミッション(最終版)

A+ a-

Android 6.0でRuntime-Permissionモデルが導入されました。このモデルはユーザーに許可を求めるダイアログを出すので、あまり出すとユーザにとって、うざいと思われるのを嫌ってか、多くのパミッションが、dangerousからnormalに変更になりました。

normalパミッションは、はく奪したりできないし、ユーザに知られることなく(ツールを使えば見れますが)使う事ができます。
プライバシー情報を取得可能な、normalパミッションは本当にいやだなーと思います。

ググるとAndroid M Preview版の時の物を公開されている方がいらっしゃいますが、それから変更も加わってますし、Googleのドキュメントも信用できませんので、最終版という事で、Nexus5Xm,Nexus6Pから吸い出した物をアップします。(android. permissionと、com.android)


Androidアプリセキュア開発セミナーを開催します

A+ a-


半年にごとにセキュアスカイ・テクノロジーさんと共催しているAndroidアプリセキュア開発セミナーのお知らせです。
今回はいつもの内容に加えて、Android 6.0で大きく変更されたパーミッションまわりのお話などもさせていただきたいと思っています。

概要
日時:2015年12月9日(水)10:00-17:00 (9:30受付開始)
会場:セキュスカイ・テクノロジー社セミナールーム(PMO 神田司町2F)
対象:Androidアプリケーションの企画、設計、開発のリーダー、およびマネージャ
費用:50,000円/人(税抜き)

詳細はこちら

ABCD金沢の講演資料 (Android6.0のセキュリティ)

A+ a-

2015/11/22-/23日に金沢にて、ABCD 2015 Kanazawaが開催されました。(ハッシュダグ #ABCD2015K)

来場者募集をした当初は、参加登録者約20名程度でとまっておりましたが、最終的には80名となり、会場も結構賑わい大盛況でした。



22日にAndroid Securityについて講演させて頂きました。
その発表資料となります。
ダウンロード(PDF): Android 6.0のセキュリティ事項

私も色々な講演を聞けてとても有意義な二日間でした。
ありがとうございました。

2015/11/23
追記:上記PDFですが、誤ってアクセス制限がかかっていました。
解除しましたのでどなたでもダウンロード可能です。


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

A+ a-

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

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


以下調査結果です。

CheckSelfPermissionの注意事項

A+ a-

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)

A+ a-

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

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

互換モードとは


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

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

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

Android6.0でMODE_MULTI_PROCESSが非推奨になったので、プリファレンスのモード指定は、MODE_PRIVATE一択になりました。

A+ a-


Android6.0 (Marshmallow)で、MODE_MULTI_PROCESSが非推奨になりました。
http://developer.android.com/intl/ja/reference/android/content/Context.html#MODE_MULTI_PROCESS

MODE_MULTI_PROCESS、プレファレンスファイルを作成する時などに、getPreferences等のメソッドの引数に指定されるファイルアクセスモードで、AndroidOS3.0の時に新しく追加され、複数のプロセスから同じプレファレンスファイルにアクセスする時に使用します。

今回、以下のような説明が記載されていました。

API Level23で非推奨
MODE_MULTI_PROCESSは、異なったプロセス間での同時修正を両立するためのメカニズムを提供しません。さらにアンドロイドの一部のバージョンでは確実に動作しません。
アプリケーションは、これを使用しないでください。その代りにContentProviderのようなクロスプロセスでのデータ管理手法を使用してください。
....
確実に動作していなかったようです。

アンドロイドアプリからデバイスロック画面の呼び出し: Confirm Credential

A+ a-



アンドロイドもう8歳らしいです。昔からアンドロイドをやっていた方は、一度はアプリからデバイスロック画面を使って、本人認証できないかと思った事があるかと思います。「権限がなくてできません」と怒られてできなかったのですが、Android 5.0からできるようになってました。Android 6.0のConfirm Credentialを見てて、該当メソッドが、API Level21と記載されており、ええ!!と思い動作確認したら、5.0でも動きました。
多分私以外にも同じような人がいると思いますので、「Confirm Credential」ご紹介です。

   デバイスロック画面



11月末に、Androidセキュリティの講演&展示しに金沢に行ってきます。

A+ a-


2015年11月22日(日)・23日(月祝)に石川県金沢市でアンドロイドの開発者イベント「ABCD 2015 Kanazawa – Android Bazaar and Conference Diverse」が開催されます。
日本アンドロイドの会では展示+講演のイベントを年2回東京にて開催しておりますが、そのミニ版!金沢が終わった後はこの経験を活かし他の県でも実施ってことになるとうれしいです。

22日にAndroid6のセキュリティに関してお話をさせて頂きますが
-Android6.0のRuntimePermissionの説明。
-Androidのセキュリティ全体での注意点
-最近のよくある脆弱性
といった内容になるのではないかと思っています。
(まだ、原稿書いてないです)

RiskFinderの展示もさせて頂きます。自分の検査したいアプリ等持ってきていただければ、こっそり検査しちゃいます。

VRハンズオンやRoBoHon展示などもあり大変充実した内容となっています。
金沢近隣でアンドロイド開発に興味をお持ちの方、ぜひご参加ください。参加は“無料”です。
事前エントリー&詳細はこちら>>

ちょっと、集客?に苦しんでいるようです。情報拡散にお手伝い頂けましたらうれしいです。

名称

ABCD 2015 Kanazawa - Android Bazaar and Conference Diverse -

日程

11月22日 (日) 9:00-20:30
11月23日 (月祝) 9:00-19:00

指紋認証とエミュレータコマンド

A+ a-

Nexus5Xが手もとに届き、ようやく指紋認証に関してきちんと調査する環境が整いました。
調査結果を色々と情報共有したいのですが、なかなか調査も進まないため、
Androidの会10月定例会で指紋認証の話でお話した、エミュレータバグの話はあまりネット上に記載がありませんので本日の記事にしたいと思います。

 Android6.0の指紋認証機能に対応した機器はまだ少数ですので、なかなかテストが難しいと思いますが、エミュレータで指紋認証のテストをすることが可能です。
Android Developer Siteでエミュレータによる指紋認証の記載はあまりなく、以下の2か所にさらっと書いてあるのみです(翻訳するまでもない内容です)
 実際にどのような感じで動作するのか動かしてみましたので、短いですがエミュレーターでの指紋認証について説明したいと思います。


スマートフォン&モバイル EXPO【秋】2015 にてRiskFinderが出展されました。

A+ a-

2015年10月28日〜30日まで、幕張メッセにて「スマートフォン&モバイル EXPO【秋】2015」が開催されました。当日の状況(主催者さん の情報より)

諸般の事情により、弊社は今回出展していませんが、株式会社システナ様より弊社が脆弱性診断エンジンを提供している「 RiskFinder」が出展されました。
「RiskFinder」は、Androidアプリケーションの脆弱性を診断できるWebサービスです。
今回は、このシステナ様の出展の模様をお伝えしたいと思います。

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

A+ a-

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が頭につきます。

Android 6.0で、StickyBoroadcastがDeprecatedになりました。2回目

A+ a-

タオソフトウェア株式会社のブログの方で、昨年「Sticky broadcastsがロリポップで非推奨になりました」というブログを書いたのですが、Android 6.0でもSticky broadcastが非推奨になりました。

何を言っているのかわからないですが....

ContentWrapperのドキュメントを見てたら、StickyBroadcast系の以下のメソッドの記載を見つけてしまいました。
  • removeStickyBroadcast 
  • removeStickyBroadcastAsUser 
  • sendStickyBroadcast 
  • sendStickyBroadcastAsUser 
  • sendStickyOrderedBroadcast 
  • sendStickyOrderedBroadcastAsUser

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

A+ a-

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での変更点

A+ a-

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

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

PermissionInfoクラス


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



Android 6.0でApache HTTP Clientが削除されました。

A+ a-

アンドロイド界隈では、Apache HTTPClientを使うのか、HttpUrlConnectionを使うのかどちらが良いのか悩んだ時期もありました。2011年頃、Android Developer BlogにAndroid'HTTP Clientというブログ記事が出て、HttpUrlConnectionな!と言っていたわけですが、この頃HttpUrlConnection色々癖があって、そうは言われてもなーと思った記憶があります。しかしながら、とうとうAndroid6.0でApache HTTPClientが削除されました。
既に色々な所で言及されている話題なのですが、動作確認まで行いましたので、このブログに記載です。

Android 6.0 Changes - Apache HTTP Client Removal

https://developer.android.com/intl/ja/about/versions/marshmallow/android-6.0-changes.html#behavior-apache-http-client

Android 6.0のリリースで、Apache HTTP Clientのサポートを削除します。
あなたのアプリが、Android 2.3(API Level9)以上をターゲットとしているのなら、代りにHttpURLConnectionクラスを使ってください。このAPIは透過的なデータ圧縮と応答のキャッシングによってネットワークの仕様を減少させるので、より効果的であり消費電力を最小限に抑えます。
ApatchのHTTP APIを引き続き使用するには、Build.gradleファイルに以下のように記載をし、コンパイル時の依存関係を宣言します。

android {
    useLibrary 'org.apache.http.legacy'
} 

ちなみに、上記指定をしても、Android Studio上は、Deprecateだよという取り消し線がメソッドの上についてきます。でも試しにAndroidHttpClient記載したらそちらには取り消し線はついてきませんでした。(これはAndrod Studioの不具合と思われます-現状そんなに影響ありませんが)


少し解説 


今回削除というこで、非推奨よりも強い扱いです。
非推奨は、Android5.1の時に行われており、1年たったからもういいでしょうという感じでしょうか、

Deprecated HTTP Classes
https://developer.android.com/intl/ja/about/versions/android-5.1.html#http

org.apache.httpクラスとandroid.net.http.AndroidHttpClientクラスはアンドロイド5.1で廃止されました。これらのクラスはメンテナンスされなくなり、あなたはできるだけ早くURLConnectionのクラスのAPIを使用するよう移行する必要があります。

AndroidHttpClinetは、途中で便利なの作ったよーと言って、出てきたクラスですが、Apacheの実装依存のため、自動的にこれも削除です。

  • HTTPUrlConnection
    • 推奨 これからも使っていく
  • DefaultHttpClient
    • 削除 Apache HTTP Client実装
  • AndroidHttpClient
    • 削除 DefaultHttpClientのサブクラスだったため、自動的に削除
ということで、いい加減やるか!ということでHTTPUrlConnection等に書き換えを行っている方もいらっしゃると思いますが、先のブログにあるように、Froyo以前で動かす場合は(動かす??)コネクションプーリングのバグがありますので、ざっと見ておく必要があると思いますj。


最後に宣伝、非推奨メソッドの使用、削除メソッドの使用も、RiskFinderで全て検知します。
今回のApache HTTP Clientに関しては、過去のアプリは結構ヒットする率が高いので、単に削除されたメソッド一覧を出すだけでなく、「Apache HTTP Clientメソッドの削除関連警告」を作成し、使用場所、理由、解説等も出力するようにする予定です。
もう、開発終わっちゃってるけど、このアプリどうなの?ソース見当たらないなんて物も、ソースコードなしで検査可能です。ご関心のある方はお問い合わせください。




日本アンドロイドの会10月定例発表資料アップしました(指紋関係)

A+ a-

2015年10月定例会 Android 6.0 Marshmallowの発表資料です。

19:15 -- 19:45 
 アンドロイドの指紋認証機能で出来ること(30min) 
 谷口 岳(リスクファインダー株式会社 代表取締役/日本Androidの会 運営委員)  
概要:Android 6.0では指紋認証機能が追加されました.この指紋認証機能について、使用者の立場、開発者の立場の両方から解説をします。

実機が届くギリギリ前の発表になってしまいました。実機がこれば、AndroidKeyStore周りの調査とか出来て、もっとプログラミング関係に言及できたのですが....

ダウンロード:アンドロイドの指紋認証でできる事.PDF

日本アンドロイドの会10月定例 ロボホン!

A+ a-


来週の月曜日と直近になりますが、日本アンドロイドの会10月定例が10月19日に開催されます。

Android 6.0特集ということで、セキュリティネタを一つと依頼されましたが、Runtime-Permissionの部分は有名ですし、皆さん既に知っているだろうということで、指紋認証についてお話させて頂きます。

ユーザの立場として指紋認証機能の使い方。開発者としての指紋認証機能の使い方について解説致します。

また、幸運なことに、先日電撃発表されました。シャープのロボホンの講演が急遽、OKとの事

ロボホンに興味がある方も、アンドロイド6.0に興味のない方も是非お越しください。


お申込みはこちら
https://www.android-group.jp/event/event41.html

日時 2015年10月19日 19:00 ~ 21:00(開場:18:30) 
場所 KDDI飯田橋駅前ビル(ベルサール飯田橋駅前ビル) 
〒102-0072 東京都千代田区飯田橋3−8−5 
会費:無料タイトル: 
2015年10月定例会 - Android 6.0 Marshmallow- 
内容: 
Google I/O 2015にてAndroid Mとして発表されたAndroid6.0が搭載された端末がいよいよ発売されます. 
日本Androidの会では,ABC2015Summerにて松内さん(Google)に概要や個々の機能について講演いただきました. 
今回は,まだあまりレビューされていない指紋認証などに焦点を当てつつも 
JAGらしく,ARTやDalvikについても振り返って語っていただこうと思っています. 
これからAndroid6.0用のアプリを書こうと思っている方.より深く理解されたいかたなど必見です. 
是非ご来場下さい

Android 6.0 - Auto Backup for Apps made simple 翻訳

A+ a-

先日のConfiguring Auto Backup for Apps 翻訳に続き、アンドロイド6.0で新しくなったバックアップ関係の翻訳です。Androiod Developerブログの記事ですが、既に翻訳されている人がいたのに後になって気が付いたんだけど、もったいないのでアップです。
バックアップ関係の翻訳ドキュメントとしてはこれで終わりです。

Auto Backup for Apps made simple

URL:http://android-developers.blogspot.jp/2015/07/auto-backup-for-apps-made-simple.html

Auto Backup for Appsはアプリデータのバックアップとレストアをアプリケーションに
コードを追加することなくシームレスに実現します。
この機能はAndroid M以上の端末で動作します。
アプリでAutoBackupを有効にするにはtargetSdkVersionを23以上に設定するだけです。

Auto Backup for AppsはGoogleによって提供されるものであり、ユーザと開発者両方とも料金は必要ありません。
さらに嬉しいことに、Google Driveに保存されるバックアップデータはユーザの容量としてカウントされません。
しかしデータ通信はユーザのモバイル通信として課金される可能性があるので注意して下さい。



Configuring Auto Backup for Apps 翻訳

A+ a-

ランタイムパミッションの翻訳をアップした後、指紋認証の話、Android Studioと第三者ライブラリの注意点と、結構バラバラに記事をアップしています。RiskFinderの6.0対応で調べた事が色々たまっており、本当はランタイムパミッションの話を長々と書きたいのですが、他にも注意すべき事項はありますので、なるべく他の人が書いてないセキュリティ物を優先的に書いていきたいと思います。

今回は、Android Developer Siteのバックアップ機能の説明ページの翻訳です。

Android Studioの落とし穴 ライブラリプロジェクト

A+ a-


EclipseからAndroid Studioへの開発環境移行はお済でしょうか?
仕事では、長期の仕事だったり、バージョンアップでもAndroid Studioへ移行するだけの理由がないなど、なかなか移行できませんが、そろそろ一回りしてようやく移行できた!という感じではないでしょうか?

今回はAndroid Studioでライブラリプロジェクトを使用する際の思わぬ落とし穴についてお話します。

最初に結論を言うと、
「知らない間に不要なパーミッションが追加されている可能性がある」
ということです。

それでは、何故このような事が起こるのかを順に説明したいと思います。


アンドロイドの指紋認証機能の使い方(ユーザ編)

A+ a-

アンドロイド6.0でのセキュリティに関する大きなキーワードとしては、指紋認証機能があります。
日本においては、ガラゲー時代に既に指紋認証機能が実現されていたこともあり、富士通等のアンドロイドでは、指紋によるデバイスロック解除等が出来る端末が多くあり目新しい物ではありませんが、アンドロイドOSとしてサポートされたので、今後色々な機能が出てきそうで期待しています。

指紋認証機能が使用できる場所としては、以下の2か所があります。

  • スマートフォンのロック解除
  • アプリ内ユーザ認証(Google Play含む)

ここでは、指紋認証機能のプログラミングの話ではなく、まずユーザとしてどのように指紋認証機能が使えるのかを説明したいと思います。
なお、実際には指紋認証センサーが付いた機械で確認をする必要がありますが、Nexus5X, Nexus6P注文しましたが、もう少し時間かかります。そのためエミュレータ上での確認の解説になります。

注)Android 6.0のイメージを焼いた、Nexus6では、設定に指紋認証メニュー自体表示されませんでした。センサーを持っていないデバイスでは、項目自体非表示になると考えられます。


Permissions Best Practices 翻訳

A+ a-

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 翻訳

A+ a-

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 翻訳

A+ a-

本日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 翻訳

A+ a-

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 翻訳

A+ a-

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について記載がある部分です。プレビューの時は色々書いてあったんですが、すっきりとまとまって少量になってしまいました。


ブログスタート

A+ a-

スマートフォンのセキュリティにもっと力を入れていくために、タオソフトウェア株式会社から、スマフォのセキュリティ専門会社として、リスクファインダー株式会社を設立しました。

従来タオソフトウェアのブログの方で投稿していました、セキュリティ関係の記事は、こちらのブログで書いていきたいと思っております。タオソフトウェアのブログはアンドロイド一般や普通のプログラミングといった所でしょうか、よろしければ、こちらのサイトもブックマークして頂けると嬉しいです。

気持ちを新たにという事で、好きな言葉を載せておきます。