自从学习苹果开发以来买了很多书，但是市面上所有的书几乎都是对于iOS 4或者以前xCode也用的都是老版本，和现在的开发环境完全搭配不上，尤其是xCode4.2 推出的storyboards ，就连在线文档都是12年1月9号进行的last update，去哪里找出，就连英文的原版书也没有将4.2的。更别说iOS 5或者iCould的内容了。所以暂时先去学习Object-C。。。
之前有下载过公开课，里面有iPhone开发的课程，网易上提供的是翻译最多的，但是里面一样还是过时的开发环境，所以用了一段时间学完了斯坦福的106A&B（Programming Methodology& Programming Abstractions)两门课，受益匪浅啊。建议所有在计算机开发上想由一定成绩的人都应该去学习一下。
前段时间Apple发布了iBook 2.0 于是去AppStore上去下载更新，想起了iPhone开发的公开课上提到过大学用于教育目的使用的开发者账号，于是想看看了解一下，但是不知道怎么就突然发现了iTunes U，里面有很多最新的公开课，排名第二的就是iPad and iPhone Application Development. 一看介绍居然是2011Fall 的，里面讲解的都是xCode 4.2在iOS 5上的开发，视频，讲义，作业的都是可以下载的，而且质量都是高清的。简直太酷了，唯一就是下载起来比较慢，于是我开着机用了40多个小时终于把所有的课程都下载下来了，一共20多个G，昨天一口气看了2节课，现在正在慢慢消化中。我后来又把课程同步到我的iPad和Air笔记本上了，随时随地的可以学习，而且配合iCould他会直到你看到哪里了，你在iPad上看了20分钟，再用电脑打开他会继续播放，包括讲义也会精确定位到你上次看的页数，想起2010WWDC大会上乔布斯的演讲，关于云，你不需要了解或者设置太多，但是他就是work！
突然看到以前写过一个总结，做j2me的 小雷电，发个帖子 看看有用没，
如果做android游戏，这些多少也是基础，有用了可以看看
初始化多个子弹(原理是子弹运动的角度不同)
void doFire() {
int m = 0;
for (int i = 0; i < Balls.length; i++) {
if (Balls[i][0] == 0) {
m++;
Balls[i][0] = 1;
Balls[i][1] = shipX + shipImg.getWidth() / 2 - 3;
Balls[i][2] = shipY - 20;
Balls[i][3] = m;
switch (m) {
case 1: Balls[i][4] = 9; break;
case 2: Balls[i][4] = 8; break;
case 3: Balls[i][4] = 10; break;
case 4: Balls[i][4] = 7; break;
case 5: Balls[i][4] = 11; break;
}
if (m >= 5) break;
} }
小球撞墙,宝物移动
之前初始化x,y和inx, incy的坐标(位置移动，如果越界根据inx,iny的正负确定移动方向，从而位置纠正)
x+= incX;
y+= incY;
if (x] <= 0|| x + giftImg.getWidth() >= width) {
x = incX > 0 ? width- giftImg.getWidth() : 0;
incX = -incX;
}
if (y <= 0 || y + giftImg.getHeight() >= height) {
y = incY > 0 ? height- giftImg.getHeight() : 0;
incY = -incY;
}
宝物飞机碰撞, 飞机处理碰撞的原理等碰撞的原理(利用坐标和长和宽确定两个矩形 是否相交)
boolean checkCollide(int x1, int y1, int w1, int h1, int x2, int y2,int w2, int h2) {
if (x1 + w1 >= x2 && x1 <= x2 + w2 && y1 + h1 >= y2 && y1 <= y2 + h2) {
return true;
}
return false;
}
组合键的实现
int keyQueue[]=new int [3];
void putKey(int keyCode){
keyQueue[2]=keyQueue[1];
keyQueue[1]=keyQueue[0];
keyQueue[0]=keyCode;
}
void clearKey(){
keyQueue[2]=keyQueue[1]=keyQueue[0]=0;
}
protected void keyPressed(int keyCode){
if(System.currentTimeMillis()-keyReleasedTime>400){ clearKey();}
putKey(keyCode);
}
protected void keyReleased(int keyCode){
keyReleasedTime=System.currentTimeMillis();
}
抛物线:
int [][] enemyFleets=new int [14][4];//active ,x,y,type
//初始化抛物线运动
void createEnemyFleets(){
int p=0;
for(int i=0;i<enemyFleets.length;i++){
if(enemyFleets[i][0]==0){
p++;
enemyFleets[i][0]=1;
enemyFleets[i][2]=-enemyFleetImg.getHeight();
enemyFleets[i][3]=p;
if(p>=2){
break;
}
}
}
}
//画抛物线
int [][] enemyFleets=new int [14][4];//active ,x,y,type
for(int i=0;i<enemyFleets.length;i++){
if(enemyFleets[i][0]==1){
enemyFleets[i][2]+=7;
if(enemyFleets[i][3]==1){
enemyFleets[i][1]=-enemyFleets[i][2]*enemyFleets[i][2]/200+width/2-enemyFleetImg.getWidth();
}
else{
enemyFleets[i][1]=enemyFleets[i][2]*enemyFleets[i][2]/200+width/2;
}
if(enemyFleets[i][2]>height){
enemyFleets[i][0]=0;
}
g.drawImage(enemyFleetImg, enemyFleets[i][1], enemyFleets[i][2], 20);
}
}
【翻译】(43)安全与权限
see
http://developer.android.com/guide/topics/security/security.html
原文见
http://developer.android.com/guide/topics/security/security.html
-------------------------------
Security and Permissions
安全与权限
-------------------------------
In this document
本文目录
* Security Architecture 安全架构
* Application Signing 应用程序签名
* User IDs and File Access 用户ID和文件访问权
* Using Permissions 使用权限
* Declaring and Enforcing Permissions 声明和实施权限
* ...in AndroidManifest.xml 在AndroidManifest.xml中实施权限（注：此处原文省略了前半句Enforcing Permissions）
* ...when Sending Broadcasts 当发送广播时实施权限（注：此处原文省略了前半句Enforcing Permissions）
* Other Permission Enforcement 其它权限实施
* URI Permissions URI权限
-------------------------------
This document describes how application developers can use the security features provided by Android. A more general Android Security Overview is provided in the Android Open Source Project.
本文描述应用程序开发者如何可以使用Android提供的安全特性。一个更通常的Android安全概览在Android开源项目中提供。
Android is a privilege-separated operating system, in which each application runs with a distinct system identity (Linux user ID and group ID). Parts of the system are also separated into distinct identities. Linux thereby isolates applications from each other and from the system.
Android是特权分离的操作系统，其中每个应用程序用不同的系统标识符运行（Linux用户ID和组ID）。系统有些部分还被分离进不同的标识符。因此，Linux能隔离每一个应用程序和系统。
Additional finer-grained security features are provided through a "permission" mechanism that enforces restrictions on the specific operations that a particular process can perform, and per-URI permissions for granting ad-hoc access to specific pieces of data.
额外的较细粒度的安全特性通过在一个特定进程可以执行的特定操作上实施限制的“权限”机制，以及用于授权对特定数据块的特别访问权的个别URI权限来提供。
-------------------------------
Security Architecture
安全架构
A central design point of the Android security architecture is that no application, by default, has permission to perform any operations that would adversely impact other applications, the operating system, or the user. This includes reading or writing the user's private data (such as contacts or e-mails), reading or writing another application's files, performing network access, keeping the device awake, etc.
Android安全架构的中心设计点是，默认下没有应用程序拥有权限执行不利地冲击其它应用程序、操作系统或用户的任何操作。它包括读取或写入用户的私有数据（诸如电话簿或电子邮箱），读取或写入另一个应用程序的文件，执行网络访问，保持设备唤醒，等等。
Because Android sandboxes applications from each other, applications must explicitly share resources and data. They do this by declaring the permissions they need for additional capabilities not provided by the basic sandbox. Applications statically declare the permissions they require, and the Android system prompts the user for consent at the time the application is installed. Android has no mechanism for granting permissions dynamically (at run-time) because it complicates the user experience to the detriment of security.
因为Android相互沙箱了应用程序，所以应用程序必须显式地共享资源和数据。它们通过声明它们得到不是由基本沙箱提供的额外能力所需权限来做到这一点。应用程序静态地声明它们需要的权限，而且Android系统在安装应用程序的时候询问用户是否同意。Android没有机制用于动态（在运行时）授权权限，因为它把用户体验复杂化到安全的伤害。
The application sandbox does not depend on the technology used to build an application. In particular the Dalvik VM is not a security boundary, and any app can run native code (see the Android NDK). All types of applications — Java, native, and hybrid — are sandboxed in the same way and have the same degree of security from each other.
应用程序的沙箱不依赖于用于构建应用程序的技术。特别地Dalvik虚拟机不是一个安全范围，而且任意应用可以运行原生代码（见Android NDK）。所有应用程序类型——Java，原生，以及混合——以相同的方式被沙箱，并且各自拥有相同的安全度。
-------------------------------
Application Signing
应用程序签名
All Android applications (.apk files) must be signed with a certificate whose private key is held by their developer. This certificate identifies the author of the application. The certificate does not need to be signed by a certificate authority: it is perfectly allowable, and typical, for Android applications to use self-signed certificates. The purpose of certificates in Android is to distinguish application authors. This allows the system to grant or deny applications access to signature-level permissions and to grant or deny an application's request to be given the same Linux identity as another application.
所有Android应用程序（.apk文件）必须用证书签名，证书的私钥由它们的开发者持有。证书标识应用程序的作者。证书不需要由证书认证中心（注：CA，Certificate Authority，维基的中文翻译为电子商务认证授权机构）签名：Android程序使用自签名证书是完全允许的和惯常的。在Android中证书的目的是区分应用程序的作者。它允许系统授权或拒绝应用程序对签名层面的权限的访问权以及授权或拒绝一个应用程序请求给予和另一个应用程序相同的Linux标识符。
-------------------------------
User IDs and File Access
用户ID和文件访问权
At install time, Android gives each package a distinct Linux user ID. The identity remains constant for the duration of the package's life on that device. On a different device, the same package may have a different UID; what matters is that each package has a distinct UID on a given device.
在安装期，Android给予每个包一个不同的Linux用户ID。在那台设备上的包的生命期期间，标识符保持不变。在一台不同的设备上，相同的包可能有一个不同的UID（注：用户ID）；问题是在一台给定的设备上每个包有一个不同的UID。
Because security enforcement happens at the process level, the code of any two packages can not normally run in the same process, since they need to run as different Linux users. You can use the sharedUserId attribute in the AndroidManifest.xml's manifest tag of each package to have them assigned the same user ID. By doing this, for purposes of security the two packages are then treated as being the same application, with the same user ID and file permissions. Note that in order to retain security, only two applications signed with the same signature (and requesting the same sharedUserId) will be given the same user ID.
因为安全实施发生在进程层面上，任意两个包的代码不能正常地运行在相同的进程上，是因为它们需要作为不同的Linux用户来运行。你可以在AndroidManifest.xml中的每个包的清单标签中使用sharedUserId属性以让它签上相同的用户ID。然后出于安全的目的，通过这样做，两个包被视为相同的应用程序，带有相同的用户ID和文件权限。注意为了保持安全，只有签上相同签名的两个应用程序（并且请求相同的sharedUserId）才会被给予相同的用户ID。
Any data stored by an application will be assigned that application's user ID, and not normally accessible to other packages. When creating a new file with getSharedPreferences(String, int), openFileOutput(String, int), or openOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory), you can use the MODE_WORLD_READABLE and/or MODE_WORLD_WRITEABLE flags to allow any other package to read/write the file. When setting these flags, the file is still owned by your application, but its global read and/or write permissions have been set appropriately so any other application can see it.
任何被一个应用程序保存的数据将被赋予那个应用程序的用户ID，并且通常对于其它包是不可访问的。当用getSharedPreferences(String, int)，openFileOutput(String, int)，或openOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory)创建一个新文件时，你可以使用MODE_WORLD_READABLE和/或MODE_WORLD_WRITEABLE标志以允许其它任何包读/写文件。当设置这些标志时，文件仍然被你的应用程序拥有，但它的全局读和/或写权限已经被合适地设置，使其它任意应用程序可以看到它。
-------------------------------
Using Permissions
使用权限
A basic Android application has no permissions associated with it, meaning it can not do anything that would adversely impact the user experience or any data on the device. To make use of protected features of the device, you must include in your AndroidManifest.xml one or more <uses-permission> tags declaring the permissions that your application needs.
一个基本的Android应用程序没有权限与它关联，这意味着它不能做任何不利地冲击用户体验或设备上的任意数据的事情。为了利用设备的被保护特性，你必须在你的AndroidManifest.xml中包含一个或多个<uses-permission>标签，声明你的应用程序需要的权限。
For example, an application that needs to monitor incoming SMS messages would specify:
例如，一个需要监视输入的SMS（注：Short Messaging Service，短信服务的缩写）消息的应用程序应该指定：
-------------------------------
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.android.app.myapp" >
<uses-permission android:name="android.permission.RECEIVE_SMS" />
...
</manifest>
-------------------------------
At application install time, permissions requested by the application are granted to it by the package installer, based on checks against the signatures of the applications declaring those permissions and/or interaction with the user. No checks with the user are done while an application is running: it either was granted a particular permission when installed, and can use that feature as desired, or the permission was not granted and any attempt to use the feature will fail without prompting the user.
在应用程序的安装期，包安装器把应用程序请求的权限授权给它，基于对声明那些权限和/或与用户交互的应用程序的签名的检查。应用程序正在运行时不会检查用户：它要么在被安装时被授权一个特定的权限，并且可以如期待那样使用那个特性，或者权限不被授权，并且任何使用该特性的尝试将失败而不会提示用户。
Often times a permission failure will result in a SecurityException being thrown back to the application. However, this is not guaranteed to occur everywhere. For example, the sendBroadcast(Intent) method checks permissions as data is being delivered to each receiver, after the method call has returned, so you will not receive an exception if there are permission failures. In almost all cases, however, a permission failure will be printed to the system log.
通常权限的失败将导致SecurityException被抛回给应用程序。然而，它不保证在任何地方都会发生。例如，当数据正在被传输给每个接收器，在该方法的调用已经返回后，sendBroadcast(Intent)方法检查权限，使你将不会接收到异常，如果存在权限失败的话。然而，几乎所有情况下，权限失败将被打印到系统日志中。
The permissions provided by the Android system can be found at Manifest.permission. Any application may also define and enforce its own permissions, so this is not a comprehensive list of all possible permissions.
Android系统提供的权限可以在Manifest.permission上找到。任意应用程序还可能定义和实施它自己的权限，所以这不是所有可能权限的综合列表。
A particular permission may be enforced at a number of places during your program's operation:
一个特定权限可能在你的程序的操作期间实施在一些地方：
* At the time of a call into the system, to prevent an application from executing certain functions.
* 在一个调用进入系统的时候，阻止一个应用程序执行某些功能。
* When starting an activity, to prevent applications from launching activities of other applications.
* 当启动一个活动时，阻止应用程序启动其它应用程序的活动。
* Both sending and receiving broadcasts, to control who can receive your broadcast or who can send a broadcast to you.
* 发送和接收广播，控制谁可以接收你的广播或者谁可以发送广播给你。
* When accessing and operating on a content provider.
* 当访问和操作在一个内容提供者时。
* Binding to or starting a service.
* 绑定到或启动一个服务。
-------------------------------
Declaring and Enforcing Permissions
声明和实施权限
To enforce your own permissions, you must first declare them in your AndroidManifest.xml using one or more <permission> tags.
为了实施你自己的权限，你必须首先在你的AndroidManifest.xml中声明它们，使用一个或多个<permission>标签。
For example, an application that wants to control who can start one of its activities could declare a permission for this operation as follows:
例如，一个希望控制谁可以启动它的其中一个活动的应用程序可以声明一个用于此操作的权限，如下所示：
-------------------------------
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.me.app.myapp" >
<permission android:name="com.me.app.myapp.permission.DEADLY_ACTIVITY"
android:label="@string/permlab_deadlyActivity"
android:description="@string/permdesc_deadlyActivity"
android:permissionGroup="android.permission-group.COST_MONEY"
android:protectionLevel="dangerous" />
...
</manifest>
-------------------------------
The <protectionLevel> attribute is required, telling the system how the user is to be informed of applications requiring the permission, or who is allowed to hold that permission, as described in the linked documentation.
<protectionLevel>属性是必需的，告诉系统用户如何被告知应用程序需要权限，或者谁被允许持有那个权限，如同被链接的文档中描述的那样（注：应该是指<protectionLevel>的参考文档，见android.R.styleable.AndroidManifestPermission_protectionLevel）。
The <permissionGroup> attribute is optional, and only used to help the system display permissions to the user. You will usually want to set this to either a standard system group (listed in android.Manifest.permission_group) or in more rare cases to one defined by yourself. It is preferred to use an existing group, as this simplifies the permission UI shown to the user.
<permissionGroup>属性是可选的，并且只用于帮助系统显示权限给用户。你将通常希望设置它为一个标准系统分组（列举在android.Manifest.permission_group中）或者在更罕见的情况下设置为你自己定义的分组。它倾向于使用一个现存分组，此时它简化了显示给用户的权限用户界面。
Note that both a label and description should be supplied for the permission. These are string resources that can be displayed to the user when they are viewing a list of permissions (android:label) or details on a single permission ( android:description). The label should be short, a few words describing the key piece of functionality the permission is protecting. The description should be a couple sentences describing what the permission allows a holder to do. Our convention for the description is two sentences, the first describing the permission, the second warning the user of what bad things can happen if an application is granted the permission.
注意应该同时提供标签和描述给权限。当他们查看一列权限（android:label）或者关于一个单一权限的细节信息（android:description）时有字符串资源可以被显示给用户。标签应该是短的，少量的描述该权限正在保护的关键功能块的单词。描述应该是几句描述该权限允许一个持有者做什么的句子。我们对描述的约定是两句话，第一句描述权限，第二句警告用户，如果应用程序被授权该权限，可能发生什么不好的事情。
Here is an example of a label and description for the CALL_PHONE permission:
这里有一个CALL_PHONE权限的标签和描述示例
-------------------------------
<string name="permlab_callPhone">directly call phone numbers</string>
<string name="permdesc_callPhone">Allows the application to call
phone numbers without your intervention. Malicious applications may
cause unexpected calls on your phone bill. Note that this does not
allow the application to call emergency numbers.</string>
<string name="permlab_callPhone">直接拨打电话号码</string>
<string name="permdesc_callPhone">允许应用程序拨打电话号码而不受你的干预。
恶意的应用程序可能导致在你的电话账单上不可预料的呼叫。
注意它不允许应用程序拨打紧急号码。</string>
-------------------------------
You can look at the permissions currently defined in the system with the Settings app and the shell command adb shell pm list permissions. To use the Settings app, go to Settings > Applications. Pick an app and scroll down to see the permissions that the app uses. For developers, the adb '-s' option displays the permissions in a form similar to how the user will see them:
你可以用Settings应用和外壳命令adb shell pm list permissions来查看当前定义系统中的权限。要想使用Settings应用，请转至设置>应用程序。挑选一个应用并向下滚动以查看应用使用的权限。对于开发者，adb的'-s'开关以类似于用户看到它们的格式来显示权限：
-------------------------------
$ adb shell pm list permissions -s
All Permissions:
Network communication: view Wi-Fi state, create Bluetooth connections, full
Internet access, view network state
Your location: access extra location provider commands, fine (GPS) location,
mock location sources for testing, coarse (network-based) location
Services that cost you money: send SMS messages, directly call phone numbers
...
（注：翻译如下：
$ adb shell pm list permissions -s
所有权限：
网络通信：查看Wi-Fi状态，创建蓝牙连接，
完全互联网访问，查看网络状态
你的位置：访问额外位置提供者命令，良好的（GPS）位置，
用于测试的模拟位置源，模糊的（基于网络的）位置
花费你的金钱的服务：发送短信服务消息，直接拨打电话号码
...
）
-------------------------------
Enforcing Permissions in AndroidManifest.xml
在AndroidManifest.xml中实施权限
High-level permissions restricting access to entire components of the system or application can be applied through your AndroidManifest.xml. All that this requires is including an android:permission attribute on the desired component, naming the permission that will be used to control access to it.
对整个系统组件或应用程序的高层次权限限制访问可以通过你的AndroidManifest.xml来应用。它所需的所有东西是包含一个android:permission属性在期待的组件上，命名将被用于控制对它的访问权的权限。
Activity permissions (applied to the <activity> tag) restrict who can start the associated activity. The permission is checked during Context.startActivity() and Activity.startActivityForResult(); if the caller does not have the required permission then SecurityException is thrown from the call.
Activity权限（应用到<activity>标签）限制谁可以启动被关联的活动。权限在Context.startActivity()和Activity.startActivityForResult()期间被检查；如果调用方没有必需的权限，那么SecurityException将从调用中被抛出。
Service permissions (applied to the <service> tag) restrict who can start or bind to the associated service. The permission is checked during Context.startService(), Context.stopService() and Context.bindService(); if the caller does not have the required permission then SecurityException is thrown from the call.
Service权限（应用到<service>标签）限制谁可以启动或绑定到被关联的服务。权限在Context.startService()，Context.stopService()和Context.bindService()期间被检查；如果调用方没有必需的权限，那么SecurityException将从调用中被抛出。
BroadcastReceiver permissions (applied to the <receiver> tag) restrict who can send broadcasts to the associated receiver. The permission is checked after Context.sendBroadcast() returns, as the system tries to deliver the submitted broadcast to the given receiver. As a result, a permission failure will not result in an exception being thrown back to the caller; it will just not deliver the intent. In the same way, a permission can be supplied to Context.registerReceiver() to control who can broadcast to a programmatically registered receiver. Going the other way, a permission can be supplied when calling Context.sendBroadcast() to restrict which BroadcastReceiver objects are allowed to receive the broadcast (see below).
BroadcastReceiver权限（应用到<receiver>标签）限制谁可以发送广播到关联的接收器。权限在Context.sendBroadcast()返回后被检查，此时系统尝试传递提交的广播给给定的接收器。因此，一个权限失败将不会导致一个异常被抛回给调用方；它将只是不传递意图。以相同的方式，一个权限可以提供给Context.registerReceiver()以控制谁可以广播到一个在程序中注册的接收器。用其它做法的话，可以在调用Context.sendBroadcast()时提供一个权限来限制哪个BroadcastReceiver对象允许接收广播（见下）。
ContentProvider permissions (applied to the <provider> tag) restrict who can access the data in a ContentProvider. (Content providers have an important additional security facility available to them called URI permissions which is described later.) Unlike the other components, there are two separate permission attributes you can set: android:readPermission restricts who can read from the provider, and android:writePermission restricts who can write to it. Note that if a provider is protected with both a read and write permission, holding only the write permission does not mean you can read from a provider. The permissions are checked when you first retrieve a provider (if you don't have either permission, a SecurityException will be thrown), and as you perform operations on the provider. Using ContentResolver.query() requires holding the read permission; using ContentResolver.insert(), ContentResolver.update(), ContentResolver.delete() requires the write permission. In all of these cases, not holding the required permission results in a SecurityException being thrown from the call.
ContentProvider权限（应用到<provider>标签）限制谁可以访问ContentProvider中的数据。（内容提供者拥有一个重要的对它们可用的附加安全设施，被称为URI权限，稍后会描述它。）不像其它组件，你可以设置两个分离的权限属性：android:readPermission限制谁可以从提供者中读取，而android:writePermission限制谁可以写入它。注意如果一个提供者同时用读和写权限来保护，那么只持有写权限并不意味着你可以读一个提供者。当你第一次取出一个提供者时检查权限（如果你两个权限都没有，那么一个SecurityException将被抛出），并且此时你在提供者上执行操作。使用ContentResolver.query()需要持有读权限；使用ContentResolver.insert()，ContentResolver.update()，ContentResolver.delete()需要写权限。在所有这些情况下，没有持有必需的权限会导致一个SecurityException从调用中被抛出。
Enforcing Permissions when Sending Broadcasts
当发送广播时实施权限
In addition to the permission enforcing who can send Intents to a registered BroadcastReceiver (as described above), you can also specify a required permission when sending a broadcast. By calling Context.sendBroadcast() with a permission string, you require that a receiver's application must hold that permission in order to receive your broadcast.
除了权限可以强制谁可以发送Intents给一个已注册的BroadcastReceiver（正如上面所描述的那样）外，当发送广播时你还可以指定一个必需的权限。通过用一个权限字符串调用Context.sendBroadcast()，你需要一个接收器的应用程序必须持有那个权限以接收你的广播。
Note that both a receiver and a broadcaster can require a permission. When this happens, both permission checks must pass for the Intent to be delivered to the associated target.
注意接收器和广播器都可能需要权限。当它发生时，两者的权限检查必须通过，以便让Intent传递给关联的目标。
Other Permission Enforcement
其它权限实施
Arbitrarily fine-grained permissions can be enforced at any call into a service. This is accomplished with the Context.checkCallingPermission() method. Call with a desired permission string and it will return an integer indicating whether that permission has been granted to the current calling process. Note that this can only be used when you are executing a call coming in from another process, usually through an IDL interface published from a service or in some other way given to another process.
细粒度权限可以任意地实施在任何进入一个服务的调用。它用Context.checkCallingPermission()来完成。有一个期待权限字符串来调用，它将返回一个整型，指示哪个权限是否已经被授权到当前的调用进程。注意它可以仅在你正在执行从另一个进程传入的调用时被使用，通常是通过从一个服务中发布的IDL（注：Interactive Data Language，交互式数据语言，这里应该是指AIDL）接口，或者是传给（注：given的意思待考）另一个进程的一些其它方式。
There are a number of other useful ways to check permissions. If you have the pid of another process, you can use the Context method Context.checkPermission(String, int, int) to check a permission against that pid. If you have the package name of another application, you can use the direct PackageManager method PackageManager.checkPermission(String, String) to find out whether that particular package has been granted a specific permission.
有一些其它有用的方法检查权限。如果你有另一个进程的pid（注：进程ID），你可以使用Context的方法Context.checkPermission(String, int, int)来检查对应于那个pid的权限。如果你有另一个应用程序的包名，你可以使用直接的PackageManager方法PackageManager.checkPermission(String, String)来找出特定包是否已经被授权一个指定的权限。
-------------------------------
URI Permissions
URI权限
The standard permission system described so far is often not sufficient when used with content providers. A content provider may want to protect itself with read and write permissions, while its direct clients also need to hand specific URIs to other applications for them to operate on. A typical example is attachments in a mail application. Access to the mail should be protected by permissions, since this is sensitive user data. However, if a URI to an image attachment is given to an image viewer, that image viewer will not have permission to open the attachment since it has no reason to hold a permission to access all e-mail.
到目前为止描述的标准权限系统在和内容提供者一起使用时常常是不足够的。一个内容提供者可能希望用读和写权限来保护自身，当它的直接客户端也需要把指定的URI交给其他应用程序，让它们来操作。一个典型的例子是邮件应用程序中的附件。邮件的访问应该被权限保护，因为它是敏感的用户数据。然而，如果把一个指向图片附件的URI交给一个图片查看器，那么那个图片查看器将没有权限打开附件，因为它没有理由持有访问所有电子邮件的权限。
The solution to this problem is per-URI permissions: when starting an activity or returning a result to an activity, the caller can set Intent.FLAG_GRANT_READ_URI_PERMISSION and/or Intent.FLAG_GRANT_WRITE_URI_PERMISSION. This grants the receiving activity permission access the specific data URI in the Intent, regardless of whether it has any permission to access data in the content provider corresponding to the Intent.
这个问题的是个别URI权限：当启动一个活动或返回结果给一个活动时，调用方可以设置Intent.FLAG_GRANT_READ_URI_PERMISSION和/或Intent.FLAG_GRANT_WRITE_URI_PERMISSION。它授权接收活动访问Intent中指定的数据URI的权限，不管它是否有访问对应于Intent的内容提供者中的数据的任何权限。
This mechanism allows a common capability-style model where user interaction (opening an attachment, selecting a contact from a list, etc) drives ad-hoc granting of fine-grained permission. This can be a key facility for reducing the permissions needed by applications to only those directly related to their behavior.
这种机制允许一个通用兼容性风格的模型，在那里用户交互（打开一个附件，从列表中选择电话簿，等等）驱动细粒度权限的特别授权。它可以是一个关键的设施，用于把应用程序需要的权限降低到只是那些直接关系到它们的行为的权限。
The granting of fine-grained URI permissions does, however, require some cooperation with the content provider holding those URIs. It is strongly recommended that content providers implement this facility, and declare that they support it through the android:grantUriPermissions attribute or <grant-uri-permissions> tag.
然而，细粒度URI权限的授权需要一些和持有那些URI的内容提供者的合作。强烈建议内容提供者实现这个设施，并且通过android:grantUriPermissions属性或<grant-uri-permissions>标签声明它们支持它。
More information can be found in the Context.grantUriPermission(), Context.revokeUriPermission(), and Context.checkUriPermission() methods.
更多信息可以在Context.grantUriPermission()，Context.revokeUriPermission()，和Context.checkUriPermission()方法中找到。
Except as noted, this content is licensed under Apache 2.0. For details and restrictions, see the Content License.
除特别说明外，本文在Apache 2.0下许可。细节和限制请参考内容许可证。
Android 4.0 r1 - 20 Jan 2012 22:25
-------------------------------
Portions of this page are modifications based on work created and shared by the Android Open Source Project and used according to terms described in the Creative Commons 2.5 Attribution License.
（此页部分内容基于Android开源项目，以及使用根据创作公共2.5来源许可证描述的条款进行修改）
（本人翻译质量欠佳，请以官方最新内容为准，或者参考其它翻译版本：
* ソフトウェア技術ドキュメントを勝手に翻訳
http://www.techdoctranslator.com/android
* Ley's Blog
http://leybreeze.com/blog/
* 农民伯伯
http://www.cnblogs.com/over140/
* Android中文翻译组
http://androidbox.sinaapp.com/
）