由于本人英文能力实在有限，不足之初敬请谅解，希望大家落脚同时能指出不足。
本博客只要没有注明“转”，那么均为原创，转贴请注明链接
android activity开发文档翻译 - 1 - 基础篇
android activity开发文档翻译 - 2 - 生命周期篇
android task与back stack 开发文档翻译 - 1
android task与back stack 开发文档翻译 - 2
android task与back stack 开发文档翻译 - 3
本系列并没有对原文100%翻译，可能没有100%的贴出原文
Designing for Security
为安全而设计
Android was designed so that most developers will be able to build applications using the default settings and not be confronted with difficult decisions about security.
Android also has a number of security features built into the operating system that significantly reduce the frequency and impact of application security issues.
Android被设计成大多数开发者有能力建立应用使用默认设置并且不用面对关于安全的困难的决定。
Android也有大量的安全特征构建到操作系统中，极大的减少应用安全问题的频率和影响。
Some of the security features that help developers build secure applications include:
一些安全特征帮助开发者建立安全的应用，包括：
1.The Android Application Sandbox that isolates data and code execution on a per-application basis.
2.Android application framework with robust implementations of common security functionality such as cryptography, permissions, and secure IPC.
3.Technologies like ASLR, NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD calloc, and Linux mmap_min_addr to mitigate risks associated with common memory management errors
4.An encrypted filesystem that can be enabled to protect data on lost or stolen devices.
1.Android应用沙箱隔离数据和代码基于每一个应用执行。
2.Android应用框架拥有强壮的常见的安全功能,比如加密，权限和安全的IPC
3.ASLR, NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD calloc和Linux mmap_min_addr技术用来减轻与常见的内存管理错误相关的风险
4.加密文件系统能够在丢失的或者被偷的设备上面保护数据
Nevertheless, it is important for developers to be familiar with Android security best practices to make sure they take advantage of these capabilities and to reduce the likelihood of inadvertently introducing security issues that can affect their applications.
对开发者来说熟悉Android安全最好的练习是保证他们利用这些能力来减少可能无意中引入的能影响他们的应用的安全问题
This document is organized around common APIs and development techniques that can have security implications for your application and its users.
As these best practices are constantly evolving, we recommend you check back occasionally throughout your application development process.
这个文档是围绕牵连你的应用和它的用户的安全的常见API和开发技术。
由于这些最佳练习是不断地发展，我们推荐你在你的应用开发进程中，偶尔的回头检查。
Using Dalvik Code
使用Dalvik代码
Writing secure code that runs in virtual machines is a well-studied topic and many of the issues are not specific to Android.
Rather than attempting to rehash these topics, we’d recommend that you familiarize yourself with the existing literature.
Two of the more popular resources are:
编写运行在虚拟机的安全代码是一个精心研究的话题，很多问题并不特指在Android上。
相比尝试重新讲解这些话题，我们推荐你熟悉已经存在的文献。
1.http://www.securingjava.com/toc.html
2.https://www.owasp.org/index.php/Java_Security_Resources
This document is focused on the areas which are Android specific and/or different from other environments.
For developers experienced with VM programming in other environments, there are two broad issues that may be different about writing apps for Android:
这个文档集中于Android专有的并/或者与其他环境不同地方。
对于有在其他环境上的VM编程经验开发者，这有这有两个普遍的问题也许对于编写Android应用来说有些不同
Some virtual machines, such as the JVM or .net runtime, act as a security boundary, isolating code from the underlying operating system capabilities.
On Android, the Dalvik VM is not a security boundary -- the application sandbox is implemented at the OS level, so Dalvik can interoperate with native code in the same application without any security constraints.
一些虚拟机，比如JVM或者.net，担任一个安全的边界作用，代码与底层操作系统能力相隔离。
在Android上，Dalvik VM不是一个安全边界 -- 应用沙箱是在系统级别实现的，所以Dalvik可以在同一个应用与native代码相互操作没有任何约束。
Given the limited storage on mobile devices, it’s common for developers to want to build modular applications and use dynamic class loading.
When doing this consider both the source where you retrieve your application logic and where you store it locally.
Do not use dynamic class loading from sources that are not verified, such as unsecured network sources or external storage, since that code can be modified to include malicious behavior.
已知的手机上的存储限制，对来发者来说，想要建立模块化应用和使用动态类加载是很常见的。
当这么做的时候，要考虑两个资源一个是 你在哪里恢复你的应用逻辑 另一个是你在哪里存储它们
不要从未验证的资源使用动态类加载器，比如不安全的网络资源或者外部存储，因为那些代码可能被修改为包含恶意的行为。
Using Native Code
使用Native代码
In general, we encourage developers to use the Android SDK for most application development, rather than using native code.
Applications built with native code are more complex, less portable, and more like to include common memory corruption errors such as buffer overflows.
一般来说，对于大多数应用开发，我们鼓励开发者使用Android SDK而不是使用native代码
编译native代码的应用更为复杂，移植性差，更容易包含常见的内存崩溃错误，比如缓冲区溢出。
Android is built using the Linux kernel and being familiar with Linux development security best practices is especially useful if you are going to use native code.
This document is too short to discuss all of those best practices, but one of the most popular resources is “Secure Programming for Linux and Unix HOWTO”, available at http://www.dwheeler.com/secure-programs.
Android使用Linux内核编译并且与Linux开发相似，如果你打算使用native代码，安全最佳实践尤其有用。
这篇文档讨论这些所有的最佳实践实在太短了，但是最受欢迎的资源之一是“Secure Programming for Linux and Unix HOWTO”，在这里可以找到http://www.dwheeler.com/secure-programs
An important difference between Android and most Linux environments is the Application Sandbox.
On Android, all applications run in the Application Sandbox, including those written with native code.
At the most basic level, a good way to think about it for developers familiar with Linux is to know that every application is given a unique UID with very limited permissions.
This is discussed in more detail in the Android Security Overview and you should be familiar with application permissions even if you are using native code.
Android和大多数Linux环境之前的一个重要区别是应用沙箱。
在Android中，所有的应用运行在应用沙箱中，包括那些用native代码编写的应用。
在最基本的级别中，对于开发者来说，一种考虑它的好的办法与Linux相似，知道每一个应用被分配一个具有非常有限权限的唯一UID。
这里讨论的比Android Security Overview中更细节化，你应该熟悉应用许可，即使你使用的是native代码
Storing Data
数据存储
Using internal files
使用内部文件
By default, files created on internal storage are only accessible to the application that created the file.
This protection is implemented by Android and is sufficient for most applications.
默认的，建立在内部存储中的文件只对建立此文件的应用可访问。
这种保护是由Android执行的，对大多数应用来说足矣。
Use of world writable or world readable files for IPC is discouraged because it does not provide the ability to limit data access to particular applications, nor does it provide any control on data format.
As an alternative, you might consider using a ContentProvider which provides read and write permissions, and can make dynamic permission grants on a case-by-case basis.
IPC（进程间通信）使用world writable或者world readable文件是令人沮丧的，因为它不提供对特定应用限制数据访问的能力，也不提供任何数据格式化控制。
作为替代方案，你应该考虑使用一个ContentProvider提供读写许可，并且能建立基于具体问题具体分析的动态许可保证
To provide additional protection for sensitive data, some applications choose to encrypt local files using a key that is not accessible to the application. (For example, a key can be placed in a KeyStore and protected with a user password that is not stored on the device).
While this does not protect data from a root compromise that can monitor the user inputting the password, it can provide protection for a lost device without file system encryption.
为了提供对附加的敏感数据保护，一些应用选择使用一个应用不可访问的key加密本地文件（比如：一个key可能存放在KeyStore并且受一个存储在设备之外的密码保护）
这并不会保护数据以防可以监听用户输入密码的根权限入侵，它可以为丢失的没有文件系统加密的设备提供保护。
Using external storage
使用外部存储
Files created on external storage, such as SD Cards, are globally readable and writable.
Since external storage can be removed by the user and also modified by any application, applications should not store sensitive information using external storage.
建立在外部存储的文件，比如sd卡，是全局可读写的。
因为外部存储可以被用户移除并且可被任何应用修改，应用不应该使用外部存储存储敏感信息。
As with data from any untrusted source, applications should perform input validation when handling data from external storage (see Input Validation section).
We strongly recommend that applications not store executables or class files on external storage prior to dynamic loading.
If an application does retrieve executable files from external storage they should be signed and cryptographically verified prior to dynamic loading.
当处理从外部存储来的数据时应用应该执行输入验证（参看输入验证章节）
我们强烈建议应用在动态加载之前不把可执行或者是class文件存储到外部存储中。
如果一个应用从外部存储检索可执行文件，在动态加载之前，他们应该被签名和加密验证。
Using content providers
使用content providers
ContentProviders provide a structured storage mechanism that can be limited to your own application, or exported to allow access by other applications.
By default, a ContentProvider is exported for use by other applications.
If you do not intend to provide other applications with access to your ContentProvider, mark them as android:exported=false in the application manifest.
ContentProviders提供一个结构存储机制，可以限制你自己的应用，或者导出给其他应用程序允许访问
默认的，一个ContentProvider由其他应用为使用而导出。（for using？）
如果你不打算为其他应用提供访问你的ContentProvider功能，在manifest中标记他们为android:exported=false即可。
When creating a ContentProvider that will be exported for use by other applications, you can specify a single permission for reading and writing, or distinct permissions for reading and writing within the manifest.
We recommend that you limit your permissions to those required to accomplish the task at hand.
Keep in mind that it’s usually easier to add permissions later to expose new functionality than it is to take them away and break existing users.
当建立一个由其他应用为使用而导出的ContentProvider，你可以为读写指定一个单一的许可，或者在manifest中为读写指定确切的许可
我们强烈建议你把你的许可限制在那些必要的事情上来完成临近的任务。
记住，通常显示新功能稍后加入许可要比把许可拿开并且打断已经存在的用户要容易。
If you are using a ContentProvider for sharing data between applications built by the same developer, it is preferable to use signature level permissions.
Signature permissions do not require user confirmation, so they provide a better user experience and more controlled access to the ContentProvider.
如果你正在使用ContentProvider在相同开发者的应用间来分享数据，使用签名级别的许可是更可取的。
签名许可不需要用户确认，所以这提供一个更好的用户体验并且更能控制ContentProvider访问。
ContentProviders can also provide more granular access by declaring the grantUriPermissions element and using the FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION flags in the Intent object that activates the component.
The scope of these permissions can be further limited by the grant-uri-permission element.
ContentProviders也可以通过声明grantUriPermissions元素并且在触发组件的Intent对象中使用FLAG_GRANT_READ_URI_PERMISSION和FLAG_GRANT_WRITE_URI_PERMISSION标志提供更颗粒状的访问。
这些许可的作用域可以通过grant-uri-permission元素进一步的限制
When accessing a ContentProvider, use parameterized query methods such as query(), update(), and delete() to avoid potential SQL Injection from untrusted data.
Note that using parameterized methods is not sufficient if the selection is built by concatenating user data prior to submitting it to the method.
当访问一个ContentProvider时，使用参数化的查询方法，比如query(), update(),和delete()来避免来自不被新人的数据潜在的SQL注入。
注意，如果提交到方法之前的选择是通过连接用户数据建立的，使用参数化的方法是不够的。
Do not have a false sense of security about the write permission.
Consider that the write permission allows SQL statements which make it possible for some data to be confirmed using creative WHERE clauses and parsing the results.
For example, an attacker might probe for presence of a specific phone number in a call-log by modifying a row only if that phone number already exists.
If the content provider data has predictable structure, the write permission may be equivalent to providing both reading and writing.
不要对“写”的许可安全有一个错误的观念
考虑“写”的许可允许sql语句使得一些数据被确认使用创造性的WHERE从句并且分析结果变为可能。
例如：一个入侵者可能在通话记录中通过修改一条记录来侦察一个存在的特定的电话号码，只要那个电话号码已经存在。
如果content provider数据有可预见的结构，“写”许可也许与提供了“读写”等效了。
原文地址如下，英文水平实在有限，希望拍砖同时能给予指正。
http://developer.android.com/guide/practices/security.html
转贴请保留以下链接
本人blog地址
163
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
