Android PermissionWord文档格式.docx
《Android PermissionWord文档格式.docx》由会员分享，可在线阅读，更多相关《Android PermissionWord文档格式.docx（5页珍藏版）》请在冰豆网上搜索。
所有的Android应用程序（.apk文件）必须用证书进行签名认证，而这个证书的私钥是由开发者保有的。
该证书可以用以识别应用程序的作者。
该证书也不需要CA签名认证（注：
CA就是一个第三方的证书认证机构，如verisign等）。
Android应用程序允许而且一般也都是使用self-signed证书（即自签名证书）。
证书是用于在应用程序之间建立信任关系，而不是用于控制程序是否可以安装。
签名影响安全性的最重要的方式是通过决定谁可以进入基于签名的permisssions，以及谁可以share用户IDs。
用户IDs和文件存取每一个Android应用程序（.apk文件）都会在安装时就分配一个独有的Linux用户ID，这就为它建立了一个沙盒，使其不能与其他应用程序进行接触（也不会让其它应用程序接触它）。
这个用户ID会在安装时分配给它，并在该设备上一直保持同一个数值。
由于安全性限制措施是发生进程级，所以两个package中的代码不会运行在同一个进程当中，他们要作为不同的Linux用户出现。
我们可以通过使用AndroidManifest.xml文件中的manifest标签中的sharedUserId属性，来使不同的package共用同一个用户ID。
通过这种方式，这两个package就会被认为是同一个应用程序，拥有同一个用户ID（实际不一定），并且拥有同样的文件存取权限。
注意：
为了保持安全，只有当两个应用程序被同一个签名签署的时候（并且请求了同一个sharedUserId）才会被分配同样的用户ID.所有存储在应用程序中的数据都会赋予一个属性-该应用程序的用户ID,这使得其他package无法访问这些数据。
当通过这些方法getSharedPreferences（String,int）,openFileOutput（String,int）,oropenOrCreateDatabase（String,int,SQLiteDatabase.CursorFactory）来创建一个新文件时，你可以通过使用MODE_WORLD_READABLEand/orMODE_WORLD_WRITEABLE标志位来设置是否允许其他package来访问读写这个文件。
当设置这些标志位时，该文件仍然属于该应用程序，但是它的globalreadand/orwrite权限已经被设置，使得它对于其他任何应用程序都是可见的。
SecurityandPermissions安全与权限（三）UsingPermissions使用权限一个基本的Android程序通常是没有任何permissions与之关联的，这就是说它不能做任何扰乱用户或破坏数据的勾当。
那么为了使用设备被保护的features，我们就必须在AndroidManifest.xml添加一个或多个标签，用以声明你的应用程序需要的permissions.下面是个例子Forexample,anapplicationthatneedstomonitorincomingSMSmessageswouldspecify:
Xml代码1.3.4.5.6.应用程序安装的时候，应用程序请求的permissions是通过packageinstaller来批准获取的。
packageinstaller是通过检查该应用程序的签名和/或用户的交换结果来确定是否给予该程序request的权限。
在用户使用过程中不会去检查权限，也就是说要么在安装的时候就批准该权限，使其按照设计可以使用该权限；
要么就不批准，这样用户也就根本无法使用该feature,也不会有任何提示告知用户尝试失败。
很多时候,一个permissionfailure会导致一个SecurityException被抛回该应用程序.但是Android并不保证这种情况会处处发生。
例如，当数据被deliver到每一个receiver的时候，sendBroadcast（Intent）方法会去检查permissions,在这个方法调用返回之后，你也不会收到任何exception。
几乎绝大多数情况，一个permissionfailure都会打印到log当中。
Android系统定义的权限可以在Manifest.permission中找到。
任何一个程序都可以定义并强制执行自己独有的permissions，因此Manifest.permission中定义的permissions并不是一个完整的列表（即有肯能有自定义的permissions）。
Aparticularpermissionmaybeenforcedatanumberofplacesduringyourprogramsoperation:
一个特定的permission可能会在程序操作的很多地方都被强制实施：
Atthetimeofacallintothesystem,topreventanapplicationfromexecutingcertainfunctions.当系统有来电的时候，用以阻止程序执行其它功能。
Whenstartinganactivity,topreventapplicationsfromlaunchingactivitiesofotherapplications.当启动一个activity的时候，会阻止应用程序启动其它应用的Acitivity。
Bothsendingandreceivingbroadcasts,tocontrolwhocanreceiveyourbroadcastorwhocansendabroadcasttoyou.在发送和接收广播的时候，去控制谁可以接收你的广播或谁可以发送广播给你。
Whenaccessingandoperatingonacontentprovider.当进入并操作一个contentprovider的时候Bindingorstartingaservice.当绑定或开始一个service的时候为了实现你自己的permissions，你必须首先在AndroidManifest.xml文件中声明该permissions.通常我们通过使用一到多个tag来进行声明。
下面例子说明了一个应用程序它想控制谁才可以启动它的Activity：
Java代码1.3.4.9.10.这里属性是需要声明的（通常系统自有的permission都会有它对应的protectionlevel，而我们自己定义的permission一般都需要定义protecdtionlevel，若不去定义，则默认为normal）。
通过声明该属性，我们就可以告知系统如何去通告用户以及通告哪些内容，或者告知系统谁才可以拥有该permission。
具体请参看链接的文档。
这我多说两句啊，这个protectionLevel分四个等级，分别是Normal,Dangerous,Signature,SignatureOrSystem,越往后安全等级越高。
这个属性是可选项,只是用于帮助系统显示permissions给用户（实际是告知系统该permission是属于哪个permissiongroup的）。
你通常会选择使用标准的systemgroup来设定该属性，或者用你自己定义的group（更为罕见）。
通常使用一个已经存在的group会更合适，因为这样UI显示的时候会更简单。
需要注意的是label和description都是需要为permission提供的。
这些都是字符串资源，当用户去看permission列表（android:
label）或者某个permission的详细信息（android:
description）时，这些字符串资源就可以显示给用户。
label应当尽量简短，之需要告知用户该permission是在保护什么功能就行。
而description可以用于具体描述获取该permission的程序可以做哪些事情，实际上让用户可以知道如果他们同意程序获取该权限的话，该程序可以做什么。
我们通常用两句话来描述permission，第一句描述该permission，第二句警告用户如果批准该权限会可能有什么不好的事情发生。
下面是一个描述CALL_PHONEpermission的label和description的例子：
Xml代码1.directlycallphonenumbers2.Allowstheapplicationtocall3.phonenumberswithoutyourintervention.Maliciousapplicationsmay4.causeunexpectedcallsonyourphonebill.Notethatthisdoesnot5.allowtheapplicationtocallemergencynumbers.你可以通过shell指令adbshellpmlistpermissions来查看目前系统已有的permissions.特别的，-s选项会以一种用户会看到的格式一样的格式来显示这些permissions.SecurityandPermissions安全与权限（五）用于限制进入系统或应用程序的Components的高层permissions可以再AndroidManifest.xml中实现.所有这些都可以通过在相应的component中包含android:
permission属性，命名该permission以使其被用以控制进入的权限。
Activitypermissions限制了谁才可以启动相应的activity.permission会在Context.startActivity（）和Activity.startActivityForResult（）的时候进行检查。
如果caller没有所需的权限，则会抛出一个SecurityException。
Servicepermissions用于限制谁才可以start或bind该service。
在Context.startService（）,Context.stopService（）和Context.bindService（）调用的时候会进行权限检查。
BroadcastReceiverpermissions用于限制谁才可以向该receiver发送广播。
权限检查会在Context.sendBroadcast（）返回时进行，由系统去发送已经提交的广播给相应的Receiver。
最终，一个permissionfailure不会再返回给Caller一个exception；
它只是不会去deliver该Intent而已。
同样地，Context.registerReceiver（）也可以有自己permission用于限制谁才可以向一个在程序中注册的receiver发送广播。
另一种方式是，一个permission也可以提供给Context.sendBroadcast（）用以限制哪一个BroadcastReceiver才可以接收该广播。
ContentProviderpermission用于限制谁才可以访问ContentProvider提供的数据。
（Contentproviders有一套而外的安全机制叫做URIpermissions，这些在稍后讨论）不同于其它的Components，这里有两种不同的permission属性可以设置:
android:
readPermission用于限制谁可以读取provider中的数据，而android:
writePermission用于限制谁才可以向provider中写入数据。
需要注意的是如果provider既被readpermis保护，也被writepermission保护的话，如果这时只有writepermission并不意味着你就可以读取provider中的数据了。
当你第一次获取provider的时候就要进行权限检查（如果你没有任何permission，则会抛出SecurityException）,并且这时你对provider执行了某些操作。
当使用ContentResolver.query（）时需要读权限，而当使用ContentResolver.insert（）,ContentResolver.update（）,ContentResolver.delete（）时需要写权限。
在所有这些情况下，没有所需的permission将会导致SecurityException被抛出。
除了之前说过的Permission（用于限制谁才可以发送广播给相应的broadcastReceiver），你还可以在发送广播的时候指定一个permission。
在调用Context.sendBroadcast（）的时候使用一个permissionstring，你就可以要求receiver的宿主程序必须有相应的permission。
值得注意的是Receiver和broadcaster都可以要求permission。
当这种情况发生时，这两种permission检查都需要通过后才会将相应的intent发送给相关的目的地。
SecurityandPermissions安全与权限（七）|SecurityandPermissions安全与权限（五）在调用service的过程中可以设置任意的fine-grainedpermissions（这里我理解的是更为细化的权限）。
这是通过Context.checkCallingPermission（）方法来完成的。
呼叫的时候使用一个想得到的permissionstring，并且当该权限获批的时候可以返回给呼叫方一个Integer（没有获批也会返回一个Integer）。
需要注意的是这种情况只能发生在来自另一个进程的呼叫，通常是一个service发布的IDL接口或者是其他方式提供给其他的进程。
Android提供了很多其他的方式用于检查permissions。
如果你有另一个进程的pid，你就可以通过contextmethodContext.checkPermission（String,int,int）去针对那个pid去检查permission。
如果你有另一个应用程序的packagename，你可以直接用PackageManagermethodPackageManager.checkPermission（String,String）来确定该package是否已经拥有了相应的权限。
到目前为止我们讨论的标准的permission系统对于contentprovider来说是不够的。
一个contentprovider可能想保护它的读写权限，而同时与它对应的直属客户端也需要将特定的URI传递给其它应用程序，以便其它应用程序对该URI进行操作。
一个典型的例子就是邮件程序处理带有附件的邮件。
进入邮件需要使用permission来保护，因为这些是敏感的用户数据。
然而，如果有一个指向图片附件的URI需要传递给图片浏览器，那个图片浏览器是不会有访问附件的权利的，因为他不可能拥有所有的邮件的访问权限。
针对这个问题的解决方案就是per-URIpermission:
当启动一个activity或者给一个activity返回结果的时候，呼叫方可以设置Intent.FLAG_GRANT_READ_URI_PERMISSION和/或Intent.FLAG_GRANT_WRITE_URI_PERMISSION.这会使接收该intent的activity获取到进入该Intent指定的URI的权限，而不论它是否有权限进入该intent对应的contentprovider。
这种机制允许一个通常的capability-style模型，这种模型是以用户交互（如打开一个附件,从列表中选择一个联系人）为驱动，特别获取更细粒化的权限。
这是一种减少不必要权限的重要方式，这种方式主要针对的就是那些和程序的行为直接相关的权限。
这些URIpermission的获取需要contentprovider（包含那些URI）的配合。
强烈推荐在contentprovider中提供这种能力，并通过android:
grantUriPermissions或者标签来声明支持。
更多的信息可以参考Context.grantUriPermission（）,Context.revokeUriPermission（）,andContext.checkUriPermission（）methods.
升级会员 