android权限管理框架

1. 如何判断android用户拒绝了某项权限

Android框架包含了对各种Camera以及其上可用的Camera功能的支持，它允许你在应用程序中抓拍照片和视频。
注意事项
在开启应用程序使用Android设备上的Camera功能之前，要考虑一些打算如何使用这些硬件功能的问题：
1. Camera需求：要考虑应用程序是否必须要运行在有Camera的设备上，如果必须，就要在应用程序的清单中声明Camera需求；
2. 快照或定制Camera：应用程序准备如何使用Camera？是只对抓拍或视频剪辑感兴趣？还是要应用程序提供使用Camera的新方法？对于抓拍或剪辑，要考虑使用既存的Camera应用程序。对于开发定制化的Camera功能，请看下文的“构建Camera应用程序”
基础
Android框架通过Camera API或Camera Intent来支持拍照和录像，以下是相关的类：
Camera
这个类是控制设备Camera的主API。在构建一个Camera应用程序时，它被用于拍照或录像。
SurfaceView
这个类用于向用户实时的展现Camera的预览。
MediaRecorder
这个类用于记录来自Camera的视频
Intent
MediaStore.ACTION_IMAGE_CAPTURE或MediaStore.ACTION_VIDEO_CAPTURE类型的Intent动作被用于不直接使用Camera对象来拍照或录像。
清单声明
在开始使用Camera API开发应用程序之前，要确保清单文件已经有了适当的声明，以允许使用Camera硬件和其他相关的功能。
1. Camera权限：应用程序必须申请使用设备Camera的权限。
<uses-permissionandroid:name="android.permission.CAMERA"/>
注意：如果通过Intent来使用Camera，应用程序就不需要申请这个权限。
2. Camera功能：应用程序还必须要声明打算使用的Camera功能，例如：
<uses-featureandroid:name="android.hardware.camera"/>
把Camera功能添加到应用程序的清单中，会让Google Play防止把程序安装到不包含Camera或不支持你所需要的Camera功能的设备上。关于如何使用基于功能过滤的Google Play，请看Google Play和基于功能的过滤
如果应用程序能够使用Camera或正确的操作Camera功能，但却不需要它，那么就应该在清单中指定android:required属性，并把属性值设置为false：
<uses-feature android:name="android.hardware.camera" android:required="false" />

3. 存储权限：如果应用程序要把图片或视频保存到设备的外部存储器上（如SD卡），就必须在清单中指定这个权限：
<uses-permissionandroid:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

4. 音频录音权限：对于视频采集的音频录音，应用程序必须要申请音频采集权限：
<uses-permissionandroid:name="android.permission.RECORD_AUDIO"/>

5. 位置定位权限：如果应用程序要给图片标记GPS位置信息，就必须申请位置定位权限：
<uses-permissionandroid:name="android.permission.ACCESS_FINE_LOCATION"/>
关于获得用户位置的更多信息，请看“定位策略”
使用既存的Camera应用
在应用程序中不需要太多的额外代码就可以快速的开启拍照或录像的方法是：使用Intent来调用一个既存的Android Camera应用程序。一个Camera Intent能够通过既存的Camera应用程序和它返回给应用程序的播放控制来申请采集一张照片或一段视频。本节会向你展示如何使用这项技术来采集一张图片或一段视频。
调用Camera Intent的过程会遵循以下这些大概的步骤：
1. 编写一个Camera Intent：创建一个申请图片或视频的Intent对象，使用以下Intent类型之一：
MediaStore.ACTION_IMAGE_CAPTURE：从一个既存的Camera应用中申请图片功能的Intent动作类型；
MediaStore.ACTION_VIDEO_CAPTURE：从一个既存的Camera应用中申请视频功能的Intent动作类型。
2. 启动Camera的Intent：使用startActivityForResult()方法来执行Camera的Intent。Intent启动后，该Camera应用程序的用户界面会显示在屏幕上，并且用户能够拍照或录像；
3. 接收Intent的结果：在你的应用程序中建立一个onActivityResult()方法来接收来自Camera Intent的回调和数据。当用户完成成拍照或录像（或者是取消操作），系统会调用这个方法。
图像采集Intent
使用Camera Intent来采集图像是你的应用程序用最少的代码来拍照的快捷方式。一个图片采集Intent能够包含以下额外的信息：
MediaStore.EXTRA_OUTPUT：这个设置需要一个指定了保存图片路径和文件名的Uri对象。这个设置是可选，但强烈推荐使用。如果不指定这个值，Camera应用程序会用默认的名称把采集到的图片保存到默认的位置，这些默认值在Intent.getData()方法的返回字段中指定。
以下示例演示了如何构建一个图片采集Intent，并执行它。示例中GetOutputMediaFileUri()方法引用了下面“保存媒体文件”一节中的示例代码：
private static final int CAPTURE_IMAGE_ACTIVITY_REQUEST_CODE = 100;
private Uri fileUri;

@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);

// create Intent to take a picture and return control to the calling application
Intent intent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);

fileUri = getOutputMediaFileUri(MEDIA_TYPE_IMAGE); // create a file to save the image
intent.putExtra(MediaStore.EXTRA_OUTPUT, fileUri); // set the image file name

// start the image capture Intent
startActivityForResult(intent, CAPTURE_IMAGE_ACTIVITY_REQUEST_CODE);
}
startActivityResult()方法执行完成后，用户就会看到Camera应用程序的界面。用户完成拍照（或取消操作）之后，用户界面就会返回到你的应用程序中，并且你必须监听onActivityResult()方法来接收Intent的结果，并继续你的应用程序的执行。
视频采集Intent
使用Camera Intent采集视频是让你的应用程序能够用最少的代码来录像的一中快捷方式。视频采集Intent能够包含以下额外信息：
MediaStore.EXTRA_OUTPUT：这个设置要求用一个URI来指定保存视频的路径和文件名。虽然它是可选的，但强烈推荐使用这个设置。如果没有指定这个设置，那么Camera应用程序会把采集到的视频用默认的名称保存到默认的位置，默认的设置是在Intent的Intent.getData()方法域中返回的。
MediaStore.EXTRA_VIDEO_QUALITY：这个值的范围是0~1，0的时候质量最差且文件最小，1的时候质量最高且文件最大。
MediaStore.EXTRA_DURATION_LIMIT：这个值以秒为单位，显示视频采集的时长。
MediaStore.EXTRA_SIZE_LIMIT：这个值以字节为单位，限制视频采集的文件大小。
下面的示例演示了如何构造一个视频采集的Intent，并执行它。这个例子中的getOutputMediaFileUri()方法引用了下文的“保存媒体文件”中的示例代码：
private static final int CAPTURE_VIDEO_ACTIVITY_REQUEST_CODE = 200;
private Uri fileUri;

@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);

//create new Intent
Intent intent = new Intent(MediaStore.ACTION_VIDEO_CAPTURE);

fileUri = getOutputMediaFileUri(MEDIA_TYPE_VIDEO); // create a file to save the video
intent.putExtra(MediaStore.EXTRA_OUTPUT, fileUri); // set the image file name

intent.putExtra(MediaStore.EXTRA_VIDEO_QUALITY, 1); // set the video image quality to high

// start the Video Capture Intent
startActivityForResult(intent, CAPTURE_VIDEO_ACTIVITY_REQUEST_CODE);
}
当startActivityForResult()方法被执行时，用户就会看到一个可编辑的Camera应用程序界面。在用户完成录像（或取消操作）之后，该用户界面就会返回到你的应用程序中，并且你必须监听onActivityResult()方法来接收Intent的结果，并继续执行你的应用程序。
接收Camera Intent结果
一旦你构建并执行了一个图片或视频的Camera Intent，那么就必须要配置你应用程序来接收Intent的结果。本节向你展示了如何监听来自Camera Intent的回调，以便应用程序能够对采集到的图片或视频做进一步的处理。
为了接收Intent的结果，必须在启动Intent的那个Activity中重写onActivityResult()方法。下面的示例演示了如何重写onActivityResult()方法来采集图片Camera Intent或视频Camera Intent的返回结果：
private static final int CAPTURE_IMAGE_ACTIVITY_REQUEST_CODE = 100;
private static final int CAPTURE_VIDEO_ACTIVITY_REQUEST_CODE = 200;

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
if (requestCode == CAPTURE_IMAGE_ACTIVITY_REQUEST_CODE) {
if (resultCode == RESULT_OK) {
// Image captured and saved to fileUri specified in the Intent
Toast.makeText(this, "Image saved to:\n" +
data.getData(), Toast.LENGTH_LONG).show();
} else if (resultCode == RESULT_CANCELED) {
// User cancelled the image capture
} else {
// Image capture failed, advise user
}
}

if (requestCode == CAPTURE_VIDEO_ACTIVITY_REQUEST_CODE) {
if (resultCode == RESULT_OK) {
// Video captured and saved to fileUri specified in the Intent
Toast.makeText(this, "Video saved to:\n" +
data.getData(), Toast.LENGTH_LONG).show();
} else if (resultCode == RESULT_CANCELED) {
// User cancelled the video capture
} else {
// Video capture failed, advise user
}
}
}
一旦Activity接收到一个成功的结果，那么你的应用程序就可以访问指定位置中的被采集的图片或视频。

2. Android 的权限管理是怎么实现的

根据用户的使用过程体验，可以将 Android 涉及的权限大致分为如下三类：

（1）Android 手机所有者权限：自用户购买 Android 手机后，用户不需要输入任何密码，就具有安装一般应用软件、使用应用程序等的权限；

（2）Android root 权限：该权限为 Android 系统的最高权限，可以对所有系统中文件、数据进行任意操作。出厂时默认没有该权限，需要使用 z4Root 等软件进行获取，然而，并不鼓励进行此操作，因为可能由此使用户失去手机原厂保修的权益。同样，如果将 Android 手机进行 root 权限提升，则此后用户不需要输入任何密码，都将能以 Android root 权限来使用手机。

（3）Android 应用程序权限：Android 提供了丰富的 SDK（Software development kit），开发人员可以根据其开发 Android 中的应用程序。而应用程序对 Android 系统资源的访问需要有相应的访问权限，这个权限就称为 Android 应用程序权限，它在应用程序设计时设定，在 Android 系统中初次安装时即生效。值得注意的是：如果应用程序设计的权限大于 Android 手机所有者权限，则该应用程序无法运行。如：没有获取 Android root 权限的手机无法运行 Root Explorer，因为运行该应用程序需要 Android root 权限。

Android 系统权限定义

Android 系统在 /system/core/private/android_filesystem_config.h 头文件中对 Android 用户 / 用户组作了如下定义，且权限均基于该用户 / 用户组设置。

在 Android 系统中，上述用户 / 用户组对文件的访问遵循 Linux 系统的访问控制原则，即根据长度为 10 个字符的权限控制符来决定用户 / 用户组对文件的访问权限。该控制符的格式遵循下列规则：

第 1 个字符：表示一种特殊的文件类型。其中字符可为 d( 表示该文件是一个目录 )、b( 表示该文件是一个系统设备，使用块输入 / 输出与外界交互，通常为一个磁盘 )、c( 表示该文件是一个系统设备，使用连续的字符输入 / 输出与外界交互，如串口和声音设备 )，“.”表示该文件是一个普通文件，没有特殊属性。

2 ～ 4 个字符：用来确定文件的用户 (user) 权限；

5 ～ 7 个字符：用来确定文件的组 (group) 权限；

8 ～ 10 个字符：用来确定文件的其它用户 (other user，既不是文件所有者，也不是组成员的用户 ) 的权限。

第 2、5、8 个字符是用来控制文件的读权限的，该位字符为 r 表示允许用户、组成员或其它人可从该文件中读取数据。短线“-”则表示不允许该成员读取数据。

第 3、6、9 位的字符控制文件的写权限，该位若为 w 表示允许写，若为“-”表示不允许写。

第 4、7、10 位的字符用来控制文件的制造权限，该位若为 x 表示允许执行，若为“-”表示不允许执行。

举个例子，“drwxrwxr--2 rootroot40962 月 11 10:36 lu”表示的访问控制权限（黑色字体标明）为：因为 lu 的第 1 个位置的字符是 d，所以由此知道 lu 是一个目录。第 2 至 4 位置上的属性是 rwx，表示用户 root 拥有权限列表显示 lu 中所有的文件、创建新文件或者删除 lu 中现有的文件，或者将 lu 作为当前工作目录。第 5 至 7 个位置上的权限是 rwx，表示 root 组的成员拥有和 root 一样的权限。第 8 至 10 位上的权限仅是 r--，表示不是 root 的用户及不属于 root 组的成员只有对 lu 目录列表的权限。这些用户不能创建或者删除 lu 中的文件、执行 junk 中的可执行文件，或者将 junk 作为他们的当前工作目录。

Android 应用程序权限申请

每个应用程序的 APK 包里面都包含有一个 AndroidMainifest.xml 文件，该文件除了罗列应用程序运行时库、运行依赖关系等之外，还会详细地罗列出该应用程序所需的系统访问。程序员在进行应用软件开发时，需要通过设置该文件的 uses-permission 字段来显式地向 Android 系统申请访问权限。

3. Android有哪些"权限"

Android是在Linux内核上建立一个硬件抽象层(Android HAL)，通过Dalvik以及各种库来执行android应用的。在手机启动时，首先需要由Bootloader(HTC手机上称作Hboot)引导Linux及手机上各个硬件设备的驱动程序，之后才启动Android系统。所以其实我们会涉及到四种不同涵义的权限：
Android权限(Permission)
这指Android中的一系列"Android.Permission.*"对象，是本文的中心内容。
Google在Android框架内把各种对象(包括设备上的各类数据，传感器，拨打电话，发送信息，控制别的应用程序等)的访问权限进行了详细的划分，列出了约一百条"Android.Permission"。应用程序在运行前必须向Android系统声明它将会用到的权限，否则Android将会拒绝该应用程序访问通过该"Permission"许可的内容。
比方说，搜狗输入法提供了一个智能通讯录的功能，用户可以在输入联系人拼音的前几个字符，或首字母，输入法就能自动呈现相关联系人的名字。为了实现这个功能，输入法必须声明它需要读取手机中联系人的能力，也就是在相关代码中加上声明"android.permission.READ_CONTACTS"对象。
图5 搜狗输入法的智能联系人功能
原生Android只提供了对"一刀切"式的管理，要么同意使用，否则就根本就不安装应用程序。当用户遇到希望使用程序的同时，又想禁止部分Permission的场合，他就无路可走。
于是，不少开发者就捣鼓出了"第三条道路"；可惜的是，没有一种方法能同时做到既不需要将手机固件Root，又完全不涉及对原始应用程序进行反向工程的方法。
RootRoot指获得Android所在的Linux系统的Root(根)权限，有了根权限，你才能对Linux做出任意的修改。iOS中的越狱(Jailbreak) 相当于获得iOS系统的Root权限(iOS是一种类Unix系统，和Linux都使用Root的概念)。在已Root的设备中，通常都是使用一个叫"Superuser"(简称SU)的应用程序来向许可的程序授以Root权限。
Bootloader的解锁(Unlock)
利用数字签名，Bootloader可以限定只有正确签名的系统可以被引导。在修改固件以获得Root以前，解锁Bootloader通常是必须的。安装第三方修改、编译的固件也需要解锁Bootloader。
基带(Radio)解锁
在Android系统中，基带是上层软件与手机中无线设备(手机网络，Wi-Fi，蓝牙等)的驱动程序之间的中介。国外的网络运营商很喜欢锁定基带，从而保证用户只能使用运营商自己指定的sim卡。在我国，锁定基带是非法的，手机制造商、网络运营商也不可以通过锁定基带的方法对待违约客户。iOS的"解锁"就是解锁iOS中的基带软件。
鱼和熊掌不可兼得，Android的世界有很多自由，坏人也能自由地做坏事。它的生态系统很强调自主：用户可以自主地减小风险，仅使用官方市场的应用程序，也可以自主地解除安全限制，从而获得更多自由。因此，在遇到坏事的时候，用户也不得不自主一下：
1， 抵制不道德，乃至非法行为
几乎所有的Android安全软件都能对来电、信息进行控制，以减少骚扰。
另一方面，很多应用都会要求它们实际功能以外的权限，表现在非(主动)告知地搜集设备序列号，位置信息，诱使用户默认地上传联系人列表等方面。
更坏一点的应用程序，则会踏入犯罪的范畴，比如能偷偷发出扣费信息，或是作为黑客的偷窥工具。
2， 减少恶意软件的损害
恶意软件即便潜伏成功，也难以获得权限，从而减少损失。
3， 用户有权自主地在抑制应用程序的部分权限时，继续使用该应用程序，而只承担由于自行设置不当而带来的后果。
用户拥有设备的所有权，因此有权自主控制设备上的内容、传感器等对象的访问；同时有权(不)运行，(不)编译设备上的应用程序。
大多数应用程序在运行时，并未达成主动告知的义务，是失误；然而即使主动告知，用户还是可以不理会。
通过Android官方市场，"打包安装器"安装应用程序时，所显示的"权限"仅是在安装包内AndroidManifest.xml声明的值，而非应用程序实际上会调用的内容。该值仅用来表明Android系统能向应用授予的最大可能的权限。即便一个"Hello World"式的应用程序，也可以在AndroidManifest.xml中声明所有可能的Android Permission。
这就是说，在AndroidManifest.xml中声明的值与应用程序实际调用的权限有关联，但不等同，且这种提示是由Android系统负责实施的强制行为。
正确的理解是："应用程序(被迫地)让Android系统告知用户，它在AndroidManifest.xml中所声明的事项。"
这意味着应用程序在使用重要权限前，依然需要自行、主动地通知用户相关事宜。

4. 安卓上有没有无需ROOT就可以禁用应用权限的东西

1 为什么Android总是事无巨细地告诉你应用索取的每一项权限？

相比Apple，Microsoft严格控制生态系统（从苹果给开发者的“App Store Guideline”可见一斑），只允许通过官方应用商店安装应用，并对每份上传进行仔细地审查而言，Android的开放就意味着，Google需要向 用户提供一系列用于为自己负责的流程、工具。所以在安装应用前，Android总是要事无巨细地告诉你，应用肯需要控制什么权限。

同样，开发者也制作了一系列易用的工具，用以鉴别可疑的应用程序，或是控制权限。

图1 Android 官方市场会强制提醒用

Andoird哪里开放了？

在Android中，用户能自由从本地安装应用，自由地对SD卡进行操作，自由选择应用市场。

如果愿意放弃保修，用户还能轻易地实行root，解锁基带（baseband）。只有一些产品会严密地锁定bootloader（如摩托罗拉）。

最重要的是，因为ASOP（Android源代码开放计划）的存在，绝大部分的Android代码都是开源的，开发者可以由此对Android系统进行 深入的修改，甚至可以自行编写一个符合Android规范的系统实例（如Cyanogen Mod）。正是因为ASOP，这篇文章才可能介绍多达5种原理不同的权限控制方法。

图2 Android开源计划的标志

开放的风险

不考虑Symbian，Windows Phone 6.5（及以下）平台，那么几乎所有的智能手机病毒都是Android平台的，甚至官方Android Market也闹过几次乌龙。在国内水货横行的市场，情况更是火上浇油，不法业者可以在手机的ROM，甚至是bootloader中做好手脚，让用户有病无法医。

在Android中，用户可以允许系统安装来自“未知源”（也就是非Google官方的，或手机预置市场的）应用程序。于是，移动平台最重要的门神------数字签名就被绕过了。

图3 Android 允许未知安装未知来源的应用程

出于Android的开放性，也有不允许“未知源”的反例：亚马逊的Kindle Fire平板使用了深度定制的Android，它只允许安装来自亚马逊官方商店的应用程序。

图4 亚马逊的 Kindle Fire 仅允许通过自带的市场安装应用

2 Android有哪些“权限”

首先需要明确一下Android中的种种“权限”。Android是在Linux内核上建立一个硬件抽象层（Android HAL），通过Dalvik以及各种库来执行android应用的。在手机启动时，首先需要由Bootloader（HTC手机上称作Hboot）引导 Linux及手机上各个硬件设备的驱动程序，之后才启动Android系统。所以其实我们会涉及到四种不同涵义的权限：

Android权限（Permission）

这指Android中的一系列“Android.Permission.*”对象，是本文的中心内容。

Google在Android框架内把各种对象（包括设备上的各类数据，传感器，拨打电话，发送信息，控制别的应用程序等）的访问权限进行了详细的划 分，列出了约一百条“Android.Permission”。应用程序在运行前必须向Android系统声明它将会用到的权限，否则Android将会 拒绝该应用程序访问通过该“Permission”许可的内容。

比方说，搜狗输入法提供了一个智能通讯录的功能，用户可以在输入联系人 拼音的前几个字符，或首字母，输入法就能自动呈现相关联系人的名字。为了实现这个功能，输入法必须声明它需要读取手机中联系人的能力，也就是在相关代码中 加上声明“android.permission.READ_CONTACTS”对象。

图5 搜狗输入法的智能联系人功能

原生Android只提供了对“一刀切”式的管理，要么同意使用，否则就根本就不安装应用程序。当用户遇到希望使用程序的同时，又想禁止部分Permission的场合，他就无路可走。

于是，不少开发者就捣鼓出了“第三条道路”；可惜的是，没有一种方法能同时做到既不需要将手机固件Root，又完全不涉及对原始应用程序进行反向工程的方法。

Root

Root指获得Android所在的Linux系统的Root（根）权限，有了根权限，你才能对Linux做出任意的修改。iOS中的越狱 （Jailbreak） 相当于获得iOS系统的Root权限（iOS是一种类Unix系统，和Linux都使用Root的概念）。在已Root的设备中，通常都是使用一个 叫“Superuser”（简称SU）的应用程序来向许可的程序授以Root权限。

Bootloader的解锁（Unlock）

利用数字签名，Bootloader可以限定只有正确签名的系统可以被引导。在修改固件以获得Root以前，解锁Bootloader通常是必须的。安装第三方修改、编译的固件也需要解锁Bootloader。

基带（Radio）解锁

在Android系统中，基带是上层软件与手机中无线设备（手机网络，Wi-Fi，蓝牙等）的驱动程序之间的中介。国外的网络运营商很喜欢锁定基带，从 而保证用户只能使用运营商自己指定的sim卡。在我国，锁定基带是非法的，手机制造商、网络运营商也不可以通过锁定基带的方法对待违约客户。iOS的“解 锁”就是解锁iOS中的基带软件。

为什么要控制Android权限

鱼和熊掌不可兼得，Android的世界有很多自由，坏人也能自由地做坏事。它的生态系统很强调自主：用户可以自主地减小风险，仅使用官方市场的应用程序，也可以自主地解除安全限制，从而获得更多自由。因此，在遇到坏事的时候，用户也不得不自主一下：

1， 抵制不道德，乃至非法行为

几乎所有的Android安全软件都能对来电、信息进行控制，以减少骚扰。

另一方面，很多应用都会要求它们实际功能以外的权限，表现在非（主动）告知地搜集设备序列号，位置信息，诱使用户默认地上传联系人列表等方面。

更坏一点的应用程序，则会踏入犯罪的范畴，比如能偷偷发出扣费信息，或是作为黑客的偷窥工具。

2， 减少恶意软件的损害

恶意软件即便潜伏成功，也难以获得权限，从而减少损失。

3， 用户有权自主地在抑制应用程序的部分权限时，继续使用该应用程序，而只承担由于自行设置不当而带来的后果。

用户拥有设备的所有权，因此有权自主控制设备上的内容、传感器等对象的访问；同时有权（不）运行，（不）编译设备上的应用程序。

大多数应用程序在运行时，并未达成主动告知的义务，是失误；然而即使主动告知，用户还是可以不理会。

为什么Android官方市场的强制提醒权限的行为不属于主动告知：

通过Android官方市场，“打包安装器”安装应用程序时，所显示的“权限”仅是在安装包内AndroidManifest.xml声明的值，而非应 用程序实际上会调用的内容。该值仅用来表明Android系统能向应用授予的最大可能的权限。即便一个“Hello World”式的应用程序，也可以在AndroidManifest.xml中声明所有可能的Android Permission。

这就是说，在AndroidManifest.xml中声明的值与应用程序实际调用的权限有关联，但不等同，且这种提示是由Android系统负责实施的强制行为。

正确的理解是：“应用程序（被迫地）让Android系统告知用户，它在AndroidManifest.xml中所声明的事项。”

这意味着应用程序在使用重要权限前，依然需要自行、主动地通知用户相关事宜。

图6 应用程序须要AndroidManifest.xml中声明调用到的权限

然而，即便只是让一半的应用程序达到以上的标准，也是不可能的。应用程序需要通过收集用户信息，程序的错误日志。从而统计用户的喜好，改进程序。另一方 面，这也是发送精确广告但不追溯到用户身份信息的方式，这一点对于免费应用而言，是极其重要的。我们之所以能知道不同型号手机的占有率，应用软件的流行 度，是与这样的统计不可分离的。

一旦每个应用程序都专业地主动发出提醒，不专业的用户（大多数用户都是不专业的）通常会将之视为如同海啸警报一般的危机。

这么做对谁都没有好处------用户方的隐私权是毋庸置疑的，然而应用程序方面的获取信息记录的需求也是无可阻挡的。如果每个用户都打算阻止，只会落得被迫接受不平等条约的下场，在温饱以前，不会有人考虑小康的问题。

于是，现状就变得有趣：用户人享受着相同的服务；其中大部分用户出于不知情/好意，默默地向开发者、广告商提供了信息，剩下的少数用户则能阻断这种劳务。而作为维持Android平台的信息商人Google，只确保在它的地盘里，不会发生触碰底线的事情。

一句话总结：

设备是我的，不管你怎么说，反正我说了算，但我说的话大多是不算数的。

3 权限控制的方法

这里开始介绍各种控制Android权限的办法。可惜的是，几乎所有的手段都需要对设备进行Root，如果不这么做，则需要付出不小代价。

App Shield（国内常见的名字：权限修改器）

它是一个需要付费的Android应用，其原理是修改应用程序的apk安装包，删除其中AndroidManifest.xml文件内，用于声明权限的 对应“Android.Permission.*”条目，然后再用一个公开的证书对安装包重新签名（需要允许“未知源”），这样一来，应用程序就不会向系 统申请原先所需的权限。当应用运行至相应的流程时，系统将直接拒绝，从而达到用户控制权限的目的。

对于已安装的应用，AppShield也会按照同样方法制作好apk安装包，然后让用户先卸载原始的应用，再安装调整过的应用。除了该应用数字签名外，用户可以随时通过执行同样的流程，将吊销的权限恢复。

图7 AppShield

Apk文件的结构

Android应用都是打包成以.apk扩展名结尾，实际上是zip的文件格式。

一个合法的apk至少需要这些成分：

根目录下的“AndroidManifest.xml”文件，用以向Android系统声明所需Android权限等运行应用所需的条件。

根目录下的classes.dex（dex指Dalvik Exceptionable），应用（application）本身的可执行文件（Dalvik字节码） 。

根目录下的res目录，包含应用的界面设定。（如果仅是一个后台执行的“service”对象，则不必需）

Apk根目录下的META-INF目录也是必须的，它用以存放应用作者的公钥证书与应用的数字签名。

当应用被安装后，这个apk文件会原封不动地移至设备的data/app目录下，实际运行的，则是Dalvik将其中Classes.dex进行编译后 的Classes.odex（存放在Dalvik缓存中，刷机时的‘cache wipe就是清除Dalvik的odex文件缓存’）。

优点：

完全不需要Root，适用于所有版本的Android设备。不会损坏系统，可以吊销任意一项Android权限。

问题：

1，需要重新安装应用，该行为可能会丢失应用的配置、历史记录。

2，执行权限吊销的应用的数字签名会被更改，无法直接更新。对于那些设计不良（没有意料到‘不声明权限’情况的），或有额外自校验的应用，可能会无法运行。

3，无法用于设备上的预装应用，除非制造商好心地将该应用设置为“可以删除”的状态。

4，这个方法修改了apk包中的内容------尽管实际上AndroidManifest.xml和数字签名并不算是应用程序的本身，但修改它们可能引发着作权的问题。

5，需要开启“未知源”。

6，这是一个收费应用。

CyanogenMod 7.1（及以上版本）

Cyanogenmod是一款着名的第三方编写的开源Android ROM。

CM7.1加入了控制权限的开关，官方的名称是“Permission Revoking”，任何非系统/保护应用在安装后，可直接吊销任意一项权限，其效果等价于直接删除apk包中AndroidManifest.xml的 对应条目，但不会引发自校验的问题。CM的权限工具的作用等同于AppShield，无非是在Android自身的权限系统中添加了一个开关。

图8 Cyanogen Mod 7.1中的权限吊销（Permission Revoking）设定

优点：

免费，使用简便，可随时，任意地吊销、恢复非预装应用的任意一项权限；不存在数字签名的问题，因而不影响使用自校验的应用程序。

问题：

此功能仅在Cyanogen Mod 7.1及以上版本提供，无法用于其它rom。因为是由Android系统出面吊销权限，其实现原理与App Shield完全相同，同样的，应用程序会因为设计不良而出现崩溃。

Permission Denied

这是可以吊销任意Android应用（注意，不当地吊销系统应用的权限可能会导致手机固件损坏，无法启动）的任意权限，对权限的修改在重启后生效。

实现原理应该与Cyanogen Mod 7.1+完全相同，适用于任何已经Root的系统，因为一般的Android系统虽然事实上支持权限吊销，但没有像Cyanogen Mod那样放置接口，因此需要重启后才能应用权限配置。同样也有系统出面拒绝权限而导致的崩溃现象。

图9 Permission Denied免费版吊销应用程序权限的场景

优点：

效果与Cyanogen Mod中的权限吊销效果一致，且可吊销系统应用的权限。同时提供了免费与收费版本，免费版并没有基本功能的缺失。适用于所有版本号不低于1.6的Android设备。

问题：

调整后的权限需要重启才能生效。设计不良的应用会崩溃。不恰当的权限修改会损坏系统，导致无法开机。

PDroid

PDroid实际上是一个Android内核补丁加上一个用于管理的外部应用。补丁需要在Recover环境中刷入系统，也可以由开发者自行移植入系 统。该软件在Android ASOP 2.3.4代码基础上开发，仅适用于没有改动内核的Android 2.3系统，目前还未支持Android 4。

图10 PDroid的界面

为了避免Cyanogen Mod 7.1+权限吊销（Permission revoking）导致的崩溃问题，以及后台服务（如LBE，QQ手机管家等，PDroid的作者认为通过后台服务拦截权限并不是好办法），PDroid 并不阻止应用程序声明权限，但会在其实际索取相关信息时，予以阻止。通俗地说，就是签署协议但不执行。在PDroid的用户界面，用户能随时精确地控制涉 及隐私的各项权限。对于某些内容，除了阻止外，用户还可以伪造一个随机或指定的数据。

可控制的内容包括：

IMEI（可伪造）

IMSI（可伪造）

SIM卡序列号（可伪造）

手机号码（可伪造）

来，去电号码

SIM卡信息

当前蜂窝网络信息

（以上七者均来自Android.Permission.READ_PHONE_STATE）

GPS定位信息 （可伪造，来自Android.Permission.FINE_LOCATION）

基站定位 （可伪造，来自Android.Permission.COARSE_LOCATION）

系统自带浏览器的历史，书签（Android.Permission.BOOKMARKS）

联系人 （android.permission.READ_CONTACTS）

通话记录 （android.permission.READ_CONTACTS）

系统日志 （android.permission.READ_LOGS）

当前账户列表 （android.permission.GET_ACCOUNTS）

当前账户的授权码 （android.permission.USE_CREDENTIALS）

短信，彩信 （可能与这5个权限有关）

android.permission.READ_SMS

android.permission.RECEIVE_SMS

android.permission.SEND_SMS

android.permission.WRITE_SMS

android.permission.RECEIVE_MMS

日历 android.permission.READ_CALENDAR

PDroid的内核补丁并不通用，每一个Rom都需要特定的补丁。开发者除了提供了几个特定机型下Cyanogen Mod，HTC Sense修改版ROM的专用补丁外，还推出了一个补丁生成工具（PDroid Patcher），用户可以给自己的ROM生成专用的内核补丁。使用该Patcher需要安装JDK（java Development Kit）。

优点：

PDroid避免了通过Android系统进行权限吊销的导致的潜在崩溃问题，也不需要后台服务。对隐私信息的控制是最精细的。尽管设备必须Root，但应用本身不需要Root权限。

问题：

安装过程是最繁琐，最不可靠的，容易导致ROM损坏，适用范围也小，需要用户有相当的技能（能安装JDK，会刷机）才可使用；只提供对隐私有关权限的控制，不提供网络访问，的控制。以这些为代价，它几乎没有其它缺点。

LBE安全大师

实际上最常用的是以LBE为代表的通过一个Root权限的后台服务来拦截相关行为的工具。除了LBE外，还有QQ手机管家等应用。这里以LBE安全大师为例介绍。

图11 LBE安全大师

LBE是国内一个叫“LBE安全小组”开发的工具，支持Android2.0～4.0。它的核心功能是像杀毒软件一般，通过一个需要Root权限的后台 服务，劫持所有调用权限的行为，并放行用户许可的部分（其官方宣传为‘API级别拦截’）。它和PDroid一样几乎不会引发应用程序崩溃，它支持拦截几 个涉及用户的关键权限（LBE手机管家3.1/3.2）：

读取短信 （android.permission.READ_CONTACTS）

联系人记录 （android.permission.READ_CONTACTS）

通话记录 （android.permission.READ_CONTACTS）

定位 （Android.Permission.COARSE_LOCATION

Android.Permission.FINE_LOCATION）

手机识别码 （与Android.Permission.READ_PHONE_STATE有关）

通话状态 （与Android.Permission.READ_PHONE_STATE有关）

发送短信（具体原理不明，同样类似于禁止这五个权限

android.permission.READ_SMS

android.permission.RECEIVE_SMS

android.permission.SEND_SMS

android.permission.WRITE_SMS

android.permission.RECEIVE_MMS）

拨打电话 （android.permission.CALL_PHONE）

通话监听 （android.permission.PROCESS_OUTGOING_CALLS）

除此以外，LBE还可以分别控制应用在Wifi，手机网络的联网权限，其原理是依靠IPtables防火墙，而非通过Android的“Internet”权限。

此外LBE手机管家还提供基于智能内容审查的短信拦截、来电归属地显示，以及禁用系统（保护）应用，进程管理，杀毒等功能。

LBE提供两个版本，一个叫“LBE安全大师”，是一个全面的手机管家类应用，更新比较频繁，另一个版本（LBE手机隐私卫士，LBE Security lite）仅提供权限方面的管理。

考虑到主要市场在国内，LBE的发行策略看上去有些奇怪，它在Google的官方市场并不发行最新版。通常只能只能在LBE的官方网页，以及国内的应用市场获得最新版本。

优点：

使用非常简单，功能强大而全面，风险很小，可以控制系统应用。适用范围广，有很多替代产品。

问题：

需要后台服务 （尽管蚕豆网有个评测，认为它对能耗几乎没有影响），不能控制所有的Android权限。

4 .自启动的控制

Android对后台服务有着最好的支持。

在Android中可以自由地开发一种称为‘Service’的后台运行的对象，加上没有苹果公司对应用程序的严格限制。诸如QQ挂机，即时调用第三方应用程序之类的形式都可以轻易实现。

为了全面支持后台服务，也为了适应移动设备资源紧张，不得不经常清理内存的问题，应用可在系统中设置触发器，当系统发生了某个特定特定事件时（系统启动，拨打电话，收发信息，安装、卸载应用，插上电源等，或应用程序自行定义的事件），就会触发启动应用程序。

AutoStarts 自启动管理

AutoStarts是一个收费应用，通过它，用户能了解系统中每一项程序会在什么场合下被触发运行。如果提供Root权限，则还能禁止这样的行为。

这里以Google Maps应用6.2版为例。默认情况下，这款应用总是会保持后台运行，并每小时向Google发送一次当前用户的位置信息。为了阻止这样的行为，需要联合 使用AutoStarts与任意一款进程管理应用：在AutoStarts中，阻止Google Maps的自行启动（如图），在每次使用完后，把Google Maps的进程杀掉。

图12 AutoStarts可以对自启动项目进行修改

5. 其他

Root带来的风险

有一个钻牛角尖的说法认为，一旦对设备进行了Root，便无安全一说，只要恶意程序一旦偷偷获得Root级别，一切都是空谈。

这种说法之所以钻牛角尖，是因为：一方面Android中的Root权限通常都是需要用户通过Superuser应用进行授权的，这已经够用，虽然不能 指望Superuser无懈可击；另一方面，控制Android权限主要是为了让应用程序在“灰色地带”的行为收敛一些，它们实际显然不是病毒等犯罪软 件。

着作权的问题 (作者不是法律方面的专家，以下言论仅供参考）

我们知 道，Android中的应用程序是基于Java语言编写的。而为了达到跨平台的目的，Java软件是以字节码（或叫中间代码，bytecode），而非计 算机能直接执行的机器码（Machine Code，有时也叫作Binary）的形式存在。因此执行Java软件时，需要一个Java虚拟机（Android系统中的Java虚拟机就是 Dalvik）负责解释运行，有的时候，虚拟机还会通过即时编译（JIT）的方法将字节码编译为机器码后再运行，以提高程序的执行效率。

这就出现一个很有趣的现象：

除非另行规定，作为设备的拥有者，用户总是可以自行决定如何使用软件，能自行决定程序能否访问用户自己的计算机（移动设备亦然）里面的各个内容、对象。

由此衍生出，在需要对代码编译、解释的场合，用户也能通过对编译器（解释器）的干预，来影响代码的执行效果。在Android中，用户还可以在Dalvik解释、编译的时候动手。

这是因为，着作权仅保护了软件代码不受到非授权的反向工程，未授权传播等侵犯。另一方面，对于Android上的Java，网页中的 javascript程序，赋予用户解释、编译的权利是程序能执行的先决条件；同时，软件发行者发通常也会主动提出放弃这种权利（表现为‘软件按原样提供 ’、‘不对使用软件造成的后果负责’等条目）

在编译、解释的过程中，需要通过汇编（Assemble），连接（Link）等方法将编译 好的对象（Object）、方法（Function）联系起来。默认情况下，这些行为是由原始的代码（源代码、中间代码）与编译器（解释器）决定的，但是 用户可以通过制约编译器（解释器）的设置，从而影响到最终代码。这么做是没有问题的。

还有一种，应用程序在安装后，会在系统中产生一些 缓存，或注册一些信息。当其中的内容有关用户数据时，读取或修改它们也是没有问题的。这就是所谓“只要是你的东西总是你的”；也是Cyanogen Mod、Permission Denied不会涉及版权问题的原因所在。

总之，一个Android应用之所以能运行的前提是：

1，首先，用户允许使用这个应用

这也可以理解成：用户安装了应用（以及因此设定的后台对象），购买了预装应用的手机。这一点即不影响应用程序的主动通知义务，也不影响用户事后的干预。

2，接下来，用户允许Dalvik对该应用使用“解释”，“JIT”的方法，从而该应用程序得以执行。

3，用户随时可以对该应用作出任意不违反版权的干预。

所以，在没有另行规定的前提下，用户总是可以自行决定，通过给应用程序分配自定义的权限；或是在应用程序调取内容，对象时予以阻断。同时，用户也需要自行承担因不当操作产生的后果。

附录：

1、 数字签名

数字签名是一种使用了公钥加密领域的技术实现，用于鉴别数字信息的方法。一套数字签名通常定义两种互补的运算，一个用于签名，另一个用于验证。数字签名可以轻易地验证完整性（正确性），合法签署的数字签名具有不可否认性。 （摘录自维基网络“数字签名”条目，有修改）

2、 版权声明

文章中引用的图标，图片或图片的部分，以及部分文字的引用，仅出于合理使用的目的，可能是持有人版权所有的。

3、 一些行为的说明

不道德行为

应用程序在启动时，或在主动告知以前，试图索取、收集电话号码、邮箱地址、位置信息等与个人身份直接关联的内容。如果是与个人关联，但不能直接联系到个人信息的IMEI等设备、SIM卡的串号，则稍微好一些。

附图1，不道德的应用程序在启动的第一时间就试图获取隐私信息

（新浪微博2.8），无论用户是否绑定了手机，应用都会第一时间记录当前手机的号码

（UC浏览器，快拍二维码），应用总是会不主动通知地记录设备的位置信息

没有实行主动通知的例子

附图2 这个应用程序在第一次启动时便开始收集位置信息，用户需要切换六次屏幕才能看到有关位置信息的提示。这项提示还有意忽略应用程序本身就会记录用户位置信息，即便用户并不使用需要位置信息的服务

主动通知的例子

附图3 主动通知就是在第一屏的醒目处，或用醒目的对比色等强调方式进行通告

5. Android 权限常量保存在哪个类中

1. 保存键值对（Saving Key-Value Sets）
如果你要存储存储小型的键值对（key-value）数据集的话，可以使用SharedPreferences API。SharedPreferences对象是一个包含键值对的文件，提供了读和写的方法。每一个SharedPreferences文件都被框架（framework）管理，并且既可以是私有的，也可以使公有的。以下内容主要是：使用SharedPreferences APIs 来存储和检索简单的数值。


Write to Shared Preferences
要写入数据，
1.先在SharedPreferences通过调用edit()方法创建一个SharedPreferences.Editor 。
2.通过putInt()和putString()来把键值对写入，
3.然后调用commit()方法来保存。
For example:
//新建一个SharedPreferences文件，设定为private模式
SharedPreferences sharedPref = getActivity().getPreferences(Context.MODE_PRIVATE);
//新建一个editor对象，通过SharedPreferences对象的edit()方法。
SharedPreferences.Editor editor = sharedPref.edit();
//调用editor的putInt()方法，参数就是键值对。
editor.putInt(getString(R.string.saved_high_score), newHighScore);
//调用editor的commit()方法，保存。
editor.commit();

Read from Shared Preferences
调用SharedPreferences对象的getInt()方法和getString()方法，读取SharedPreferences文件。参数可以写default，也可以写key。返回值都是value。
//创建一个SharedPreferences对象
SharedPreferences sharedPref = getActivity().getPreferences(Context.MODE_PRIVATE);
//参数我default情况
long default = getResources().getInteger(R.string.saved_high_score_default));
//参数为（key，default）情况
long highScore = sharedPref.getInt(getString(R.string.saved_high_score), default);

2.保存文件(saving files)
android系统里对文件进行读写，主要使用了File APIs。
File对象主要用来读写大的数据量。比如图像文件、通过网络交换的文件。
以下内容基于读者已经了解Linux文件系统以及java.io里的标准文件输入输出API。


内部存储Internal storage的特点:
1.一直可用
2.是默认程序的默认文件访问位置，其他app访问不了。
3.卸载app时，系统会删除这个app所有文件
Internal storage 可以确保用户和其他app无法访问你的文件。很好的私密性。

外部存储External storage的特点：
1.并非一直可用。可以插在卡槽，但是卸载掉，这时候系统就看不到了，或者用户把sd卡当U盘使。
2.文件存储不安全。sd卡拿出来，里面的信息就泄露了。
3.卸载app时，只有你在路径getExternalFilesDir()保存文件的时候，系统才可以删除这个app的文件。
如果不在这个路径的话，那SD卡上就会有残留文件了。
如果文件没有访问限制，或者你想让文件为其他app所用，或者希望通过电脑查看，外部存储不失为一种好方法。

TIPS：可以设置manifest文件里的android:installLocation属性来让app装在外部存储。

Obtain Permissions for External Storage
要向外部存储写文件，必须在manifest文件里声明WRITE_EXTERNAL_STORAGE权限。
<manifest ...>
<uses-permission
//写入外部存储文件的权限
android:name="android.permission.WRITE_EXTERNAL_STORAGE"
/>
...
</manifest>

注意：目前，所有的app都可以读取外部存储上的文件，不需要特殊的权限。但是以后这个肯定要改的，读取外部存储的文件也是需要权限的。所以也要在manifest文件里声明READ_EXTERNAL_STORAGE权限。
<manifest ...>
<uses-permission
//读取外部存储文件的权限
android:name="android.permission.READ_EXTERNAL_STORAGE"
/>
...
</manifest>

往内部存储写文件是不需要权限的，从内部存储读文件也是不需要权限的。
所以内外存储文件还有权限上的区别：外部的要权限，内部的不需要。

Save a File on Internal Storage
保存一个文件到内部存储的时候，需要获得一个存储路径，方法有二：
1.getFilesDir()--------返回文件File路径
2.getCacheDir()--------返回一个缓存文件路径
临时缓存文件里存放着temporary cache files，确保不用这些文件的时候删除，并有size上的控制，系统在低存储空间的时候，会直接删除这个临时文件夹内容。

在存储路径上创建文件时候，使用File()构造器，参数为路径，和文件名称。
//使用File()构造器，参数1：文件路径 参数2：文件名称
File file = new File(context.getFilesDir(), filename);

或者，可以调用openFileOutput()方法来获取FileOutputStream，来向内部存储路径写文件。
String filename = "myfile";
String string = "Hello world!";
FileOutputStream outputStream;
try {
//调用方法创建流，参数1：文件名参数2：文件类型为私有
putStream = openFileOutput(filename, Context.MODE_PRIVATE);
//调用流的write方法
outputStream.write(string.getBytes());
//关闭流
outputStream.close();
}
catch (Exception e) {
e.printStackTrace();
}

如果要创建一个缓存文件，就要用createTempFile()方法。
以下代码从url提取文件name，然后用那个name在缓存文件夹创建一个文件。
public File getTempFile(Context context, String url) {
File file;
try {
String fileName = Uri.parse(url).getLastPathSegment();
file = File.createTempFile(fileName, null, context.getCacheDir());
catch (IOException e) {
// Error while creating file
}
return file;
}

注意：app的内部存储路径是由你的app的包的名称指定的，在android文件系统的特定位置。技术上看，如果你把文件mode设置为可读，其他app是可以读取你的app的数据的。但是其他app要想读取，必须要知道你的包的名称和文件的名称。除非你明确设定file mode为readable或者writable，否则其他app肯定没法读和写你的internal file。 所以，只要你把文件mode设置为Context.MODE_PRIVATE，其他app是无论如何也没法访问到这个文件的。

Save a File on External Storage
因为外部存储有可能不可用，所以用之前要查询一下外部存储的状态，使用之前肯定要查一下外部存储的可用空间。调用getExternalStorageState()方法，如果返回的状态是MEDIA_MOUNTED的话，外部存储就是可用的，包括读和写。
//检查外部存储是否可以读和写
public boolean isExternalStorageWritable() {
String state = Environment.getExternalStorageState();
if (Environment.MEDIA_MOUNTED.equals(state)) {
return true;
}
return false;
}
//查看外部存储是否至少可读
public boolean isExternalStorageReadable() {
String state = Environment.getExternalStorageState();
if (Environment.MEDIA_MOUNTED.equals(state) ||
Environment.MEDIA_MOUNTED_READ_ONLY.equals(state)) {
return true;
}
return false;
}

有两个文件夹来存放文件：
1.公共文件夹（Public files）
其他用户和app都可以访问，app卸载以后，文件仍然存在，其他app和用户可以继续使用。
比如：app拍的照片
2.私有文件夹（Private files）
文件私有，其他用户和app无权访问。app卸载以后，文件即被删除。尽管文件存储在外部存储上，其他用户
和app是可以访问的，但是实际上，这些文件是不会向app以外的其他用户提供数据的。、
比如：app下载的内容和临时文件

存储public文件到外部存储：调用()方法。这个方法有个参数，来指定你要存储文件的类型，这样，其他公共文件夹就可以将其包括进去。比如 DIRECTORY_MUSIC和 DIRECTORY_PICTURES。
public File getAlbumStorageDir(String albumName) {
// 获取用户公共图片文件夹路径
File file = new File(Environment.(
Environment.DIRECTORY_PICTURES), albumName);
if (!file.mkdirs()) {
Log.e(LOG_TAG, "Directory not created");
}
return file;
}

存储public文件到外部存储：调用()方法。这个方法有个参数，来指定你要存储文件的类型，这样，其他公共文件夹就可以将其包括进去。比如 DIRECTORY_MUSIC和 DIRECTORY_PICTURES。
public File getAlbumStorageDir(String albumName) {
// 获取用户公共图片文件夹路径
// 参数1：Environment.(Environment.DIRECTORY_PICTURES)
// 参数2：albumName
File file = new File(Environment.(
Environment.DIRECTORY_PICTURES), albumName);
if (!file.mkdirs()) {
Log.e(LOG_TAG, "Directory not created");
}
return file;
}

存储private文件到外部存储：调用getExternalFilesDir()方法，也要传入一个指定文件类型的参数。以下是创建一个私人相册的文件的代码：
public File getAlbumStorageDir(Context context, String albumName) {
// 获取应用的私人相册文件路径
//参数1：context.getExternalFilesDir(Environment.DIRECTORY_PICTURES)
//参数2：albumName
File file = new File(context.getExternalFilesDir(Environment.DIRECTORY_PICTURES), albumName);

if (!file.mkdirs()) {
Log.e(LOG_TAG, "Directory not created");
}
return file;
}
也可以调用 getExternalFilesDir()方法，传如null参数，这样就会返回外部存储的根目录。
记住：
1. getExternalFilesDir()方法创建的文件路径，会在用户卸载这个app的时候被删除。
2. 如果想让你的文件路径在app被卸载以后仍然存在，那么() 是一个更好的选择。
3.无论是建立可以共享的文件路径，还是私有文件路径，使用API 常量来指定文件目录类型是很重要的。比如，DIRECTORY_PICTURES，这可以确保系统正确的识别目录里的数据。

Query Free Space
如果你事先知道要存储的数据量的大小，你就可以先查询一下可用空间有多少， 这样就可以避免IOException，可用的方法是：getFreeSpace()和getTotalSpace()。
getFreeSpace()---返回剩余空间
getTotalSpace()---返回总空间。

但是返回的可用空间大小，并不说明，你就可以存入这么多的数据。如果空间比你要存入的数据大几M，或者空间被占用率小于90%，都还可以，反之，就未必能存入。

并不需要每次存文件之前都来这么个判断，加个异常捕捉就OK。而且，你也未必知道你要存入的数据有多大，你想判断，也没法判断的，所以能catch这个IOException就行。

Delete a File
删除文件最简单的方法是调用文件本身的方法：delete()
myFile.delete();
如果文件存储在内部存储介质上，可以利用上下文的方法：deleteFile()
myContext.deleteFile(fileName);

注意：当用户卸载app时候，系统会删除以下文件：
1.所有存储在内部介质上的数据
2.使用getExternalFilesDir()创建路径的外部介质上的数据
但是，所有缓存文件夹是需要手动删除的

6. 如何管理android手机中app的权限

1、（以魅族手机为例）打开手机设置选项。

7. Android权限机制

我们知道 Android 应用程序是沙箱隔离的，每个应用都有一个只有自己具有读写权限的专用数据目录。但是如果应用要访问别人的组件或者一些设备上全局可访问的资源，这时候权限机制就能系统化地规范并强制各类应用程序的行为准则。

Android 安全性概览

在 Android 中，一个权限，本质上是一个字符串，一个可以表示执行特定操作的能力的字符串。比如说：访问 SD 卡的能力，访问通讯录的能力，启动或访问一个第三方应用中的组件的能力。 权限被授予了之后，首先会在内存和本地中有记录，这在调用系统binder服务和其他应用组件时做鉴权依据,比如调用系统binder服务时会通过Binder.getCallingUid()拿到调用者的Uid，而Uid一般都是与应用包名一一对应的，再拿这个Uid到PMS里去查这个应用对应的权限。 其次会按被授予的权限将应用分到某个组。 可以参考 https://www.jianshu.com/p/a17c8bed79d9

自定义权限的应用场景在于限制其它应用对本应用四大组件的访问。具体用法可以参考 https://www.cnblogs.com/aimqqroad-13/p/8927179.html

pm list permissions -f 命令可以详细查看 Android 所有预定义的权限。

更详细的权限信息参考 https://developer.android.com/reference/android/Manifest.permission?hl=zh-cn#WRITE_EXTERNAL_STORAGE

可以看到一个权限的信息包括：定义的包名、标签、描述、 权限组 和 保护级别 。

权限根据设备的功能或特性分为多个组。如果应用已在相同权限组中被授予另一危险权限，系统将立即授予该权限，如READ_CONTACTS和WRITE_CONTACTS。

SYSTEM_ALERT_WINDOW 和 WRITE_SETTINGS 由于其特殊性，其申请方式与其它权限都不同。

其授予流程如下：

（关于 AppOpsManager 是什么可以参考: https://segmentfault.com/a/1190000009214983 ）

这里简要分析下ActivityCompat#requestPermissions的流程：

更详细的权限授予流程源码分析可以参考: https://segmentfault.com/a/1190000009214983

普通权限： 清单文件中声明即可。

危险权限： 方式一： pm grant application_package android.permission.CHANGE_CONFIGURATION 方式二：appops set application_package permission_num 0/1

appops可以授予的权限参考 android.app.AppOpsManager 中的声明

系统签名权限： 方式一：将app迁移到system/priv-app目录中。 方式二：看不懂，参考 https://blog.csdn.net/abcd_3344_abcd/article/details/50698759

android 4.4 访问sd卡需要申请权限。 您的应用在 Android 4.4 上运行时无法读取外部存储空间上的共享文件，除非您的应用具有 READ_EXTERNAL_STORAGE 权限。也就是说，没有此权限，您无法再访问 () 返回的目录中的文件。但是，如果您仅需要访问 getExternalFilesDir() 提供的您的应用特有目录，那么，您不需要 READ_EXTERNAL_STORAGE `权限。

android 6.0 运行时权限。 此版本引入了一种新的权限模式，如今，用户可直接在运行时管理应用权限。这种模式让用户能够更好地了解和控制权限，同时为应用开发者精简了安装和自动更新过程。用户可为所安装的各个应用分别授予或撤销权限。 对于以 Android 6.0（API 级别 23）或更高版本为目标平台的应用，请务必在运行时检查和请求权限。要确定您的应用是否已被授予权限，请调用新增的 checkSelfPermission() 方法。要请求权限，请调用新增的 requestPermissions() 方法。即使您的应用并不以 Android 6.0（API 级别 23）为目标平台，您也应该在新权限模式下测试您的应用。 如需了解有关在您的应用中支持新权限模式的详情，请参阅 使用系统权限 。如需了解有关如何评估新模式对应用的影响的提示，请参阅 权限最佳做法 。

android 7.+ 应用间共享文件要使用FileProvider。 对于面向 Android 7.0 的应用，Android 框架执行的 StrictMode API 政策禁止在您的应用外部公开 file://URI。如果一项包含文件 URI 的 intent 离开您的应用，则应用出现故障，并出现 FileUriExposedException 异常。 要在应用间共享文件，您应发送一项 content:// URI，并授予 URI 临时访问权限。进行此授权的最简单方式是使用 FileProvider `类。如需了解有关权限和共享文件的详细信息，请参阅 共享文件 。

android 8.+
同一权限组的权限在被授予了之后也需要显式的再申请一次。
在 Android 8.0 之前，如果应用在运行时请求权限并且被授予该权限，系统会错误地将属于同一权限组并且在清单中注册的其他权限也一起授予应用。 对于针对 Android 8.0 的应用，此行为已被纠正。系统只会授予应用明确请求的权限。然而，一旦用户为应用授予某个权限，则所有后续对该权限组中权限的请求都将被自动批准。 例如，假设某个应用在其清单中列出 READ_EXTERNAL_STORAGE 和 WRITE_EXTERNAL_STORAGE 。应用请求 READ_EXTERNAL_STORAGE ，并且用户授予了该权限。如果该应用针对的是 API 级别 24 或更低级别，系统还会同时授予 WRITE_EXTERNAL_STORAGE ，因为该权限也属于同一 STORAGE 权限组并且也在清单中注册过。如果该应用针对的是 Android 8.0，则系统此时仅会授予 READ_EXTERNAL_STORAGE ；不过，如果该应用后来又请求 WRITE_EXTERNAL_STORAGE ，则系统会立即授予该权限，而不会提示用户。

android 9
隐私权限变更。
为了增强用户隐私，Android 9 引入了若干行为变更，如限制后台应用访问设备传感器、限制通过 Wi-Fi 扫描检索到的信息，以及与通话、手机状态和 Wi-Fi 扫描相关的新权限规则和权限组。

android 10
隐私权变更。
外部存储访问权限范围限定为应用文件和媒体，在后台运行时访问设备位置信息需要权限，针对从后台启动 Activity 的限制等。

android 11
隐私权限变更。
更详细的版本变更请参考 https://developer.android.com/preview/privacy?hl=zh-cn