androidsystem权限
㈠ 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 系统后，系统都会为其分配一个用户 ID，如 app_4、app_11 等。以下是 Calendar 和 Terminal 软件在 Android 系统中进程浏览的结果（其中，黑色字体标明的即为应用分配的用户 ID）： 在 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 root root 4096 2 月 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 系统申请访问权限。
㈡ 安卓手机存储目录/system/app/目录下的应用有root权限吗如果把别的应用放到里面就会获
Android系统的开放，使其用户可以自己查看系统和SD卡中的文件夹。就系统和SD卡中常见的目录代表什么意思，下面是一个较实用的总结: 一、SD卡中 1. /mnt/sdcard或者/sdcard这是Android手机中SD卡的文件夹路径，其中/mnt/sdcard/是android 2.2或更高版本所使用的，而/sdcard是android 2.1或早期版本的存储卡位置。 2. /mnt/sdcard/dcim或/sdcard/dcim这个DCIM文件夹是干什么用的，这里提示大家，一般数码相机都有DCIM文件夹，其中进入后Camera为手机摄像头拍摄的照片或视频存放位置。同时在DCIM文件夹中还有.thumbnails这个目录，在Linux中开头为“.”的文件夹就是开头为“点”的文件夹是隐藏目录，这里面记录着手机SD卡图片的缩略图。 3. /mnt/sdcard/LOST.DIR或/sdcard/LOST.DIR这个LOST.DIR为SD卡扫描时发现的丢失文件，里面的文件用处不大，可以不用理会。 二、手机或平板电脑中 1. /system/app 这里是android手机rom中的系统应用存放地，如果有Root权限可以将手机rom中自带的应用删除掉，这里面一般包含一个apk文件和odex文件，大家注意文件名一一对应。 2. /data/data 这里是每个安装过应用的用户文件存储位置，一般为设置文件、数据库或临时缓存文件，进入后以每个软件的package name包名来命名。 3. /dev 这里是Linux系统常规文件夹，里面的文件很多都是设备模拟的文件系统，一般用户无需理会。 4. /system/fonts 这里面保存着系统的字体，如果你有root权限，可以往里添加自己喜欢的字体，比如雅黑。 5. /system/framework 这里是android系统的框架，里面保存着系统核心程序或java类库，十分重要里面的任何文件几乎都不要做删除操作。 6. /media/audio 这里面保存着安卓系统默认的铃声，alarms是闹铃提醒的，notification是短信或提示音，ringtones是来电铃声，而ui是一些界面音效，比如键盘敲击声。 7./system/lib 里面保存的是系统底层类库，里面很多都是框架层的实现文件，一般以.so后缀结尾类似windows下的dll文件。
㈢ Android应用程序怎样获取读取系统文件的权限
1、必须是Android系统开发人员，否则你无法修改init.rc等文件。 2、你的应用程序必须要获得system权限。
在应用层 你要想用代码获得系统文件权限，除非你手机root了
要么你自己坐rom。。。。 自己修改 init，rc
具体可以参考这篇博文：http://blog.sina.com.cn/s/blog_5f35912f0100w4ld.html
㈣ Android系统中的ROOT和System权限的区别
没有什么区别
root是根的意识，是最高的权限了，也就是System权限。
root就是手机的神经中枢，它可以访问和修改你手机几乎所有的文件，这些东西可能是制作手机的公司不愿意你修改和触碰的东西，因为他们有可能影响到手机的稳定，还容易被一些黑客入侵（Root是Linux等类UNIX系统中的超级管理员用户帐户，该帐户拥有整个系统至高无上的权利，所有对象他都有可以操作的权利，所以很多黑客在入侵系统时，都要把权限提升到Root权限，就是将自己的非法帐户添加到Root用户组。类比于Administrator是Windows NT内核系统中的超级管理员用户帐户，也拥有最高的权限。但不同的是，在WINDOWS下Administrator的资源和别的用户资源是共享的，简单的说，别的用户可以访问Administrator的文件。而Linux中，别的用户是不能访问Root用户的家目录(/root)下文件的。因此，Linux比Windows更安全）
㈤ android 读写文件需要哪些权限
<!--往sdcard中写入数据的权限 --><uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"></uses-permission><!--在sdcard中创建/删除文件的权限 --><uses-permission android:name="android.permission.MOUNT_U
android中的apk必须签名
这种签名不是基于权威证书的，不会决定某个应用允不允许安装，而是一种自签名证书。
重要的是，android系统有的权限是基于签名的。比如：system等级的权限有专门对应的签名，签名不对，权限也就获取不到。默认生成的APK文件是debug签名的。
获取system权限时用到的签名，见：如何使Android应用程序获取系统权限。基于UserID的进程级别的安全机。这种签名不是基于权威证书的，不会决定某个应用允不允许安装，而是一种自签名证书。重要的是，android系统有的权限是基于签名的。
㈥ 如何使Android应用程序获得root权限
一般来说， Android 下的应用程序可以逗直接地得到的最大的权限为 system ，但是如果我们需要在程序中执行某些需要 root 权限的命令，如 ifconfig 等，就需要 root 权限了。按照 Simon 的文章中提到的，应用程序有以下两种办法临时获得 root 权限：
1) 实现一个 init 实现一个 Service ，来帮助 Android 应用程序执行 root 权限的命令。
2) 实现一个虚拟设备，这个设备帮助 Android 应用程序执行 root 权限的命令。
第二种办法我这里没有尝试，暂时也不会。这里讲讲我在实现第一种办法的过程和遇到的一些问题。
1. 将我们要执行的命令写成脚本，或者可执行程序。
下面是我的脚本 ifconfig_test.sh ：
# ！ /system/bin/sh
ifconfig
注意： 脚本的第一行必须为 # ！ /system/bin/sh ，否则无法执行，通过 dmesg 可以查看到信息内容为 cannot execve ./ifconfig_test.sh: Exec format error
也可以采用 C/C++ 编写需要执行的命令或者程序，并在编译 image 的时候编译成可执行程序。
2. 在 init.rc 中注册 service
Android 中的 service 需要在 init.rc 中注册， Init.rc 中定义的 Service 将会被 init 进程创建，这样将可以获得 root 权限。当得到相应的通知（通过属性设置）后， init 进程会启动该 service 。
本文中注册的内容如下：
service ifconfig_test /system/etc/ifconfig_test.sh
oneshot
disabled
其中， oneshot 表示程序退出后不再重新启动， disabled 表示不在系统启动时启动。
注意： 这里 service name 不能超过 16 个字符。我之前的 service name 由于定义的比较长， 18 个字符，设置属性通知 service 启动后查看 dmesg 可以看到提示： init: no such service 。查看 /system/core/init/parser.c 的源代码，在 parse_service->valid_name 函数中可以看到如下内容： if (strlen(name) > 16) { return 0; } ，证明 service 的名字的确不能超过 16 个字符。
3. 将 Android 应用程序提升为 system 权限
既然应用程序可以通过启动 service 获得 root 权限，那么岂不是很不安全。 Android 考虑到了这点，规定只有 system 权限的应用程序才能设置属性，通知 service 启动。关于提升 system 权限的文章网上已有很多，这里就不再细说，
4. 在应用程序中添加属性设置代码
前面已经提到，对于 Android 来说，应用程序通知 init 启动 service 是通过设置系统属性来完成的，具体为设置 System 系统属性 逗ctl.start地 为 逗ifconfig_test地 ，这样 Android 系统将会帮我们运行 ifconfig_test 这个 service 了。
对该系统属性的设置有三种方法，分别对应三种不同的应用程序：
1) Java 代码
Android 在 Java 库中提供 System.getProperty 和 System.setProperty 方法， Java 程序可以通过他们来设置和获得属性。代码如下：
SystemProperties.set("ctl.start", "ifconfig_test");
上面的代码是通知 Android 执行 ifconfig_test service ，如果需要查询当前 service 执行的状态，如是否执行完毕，可以通过如下代码查询：
ret = SystemProperties.get("init.svc. ifconfig_test ", "");
if(ret != null && ret.equals("stopped"))
{
return true;
}
2） JNI 代码
当编写 NDK 的程序时，可以使用 property_get 和 property_set 这两个 API 来获得和设置属性。使用这两个 API 必须要包含头文件 cutils/properties.h 和链接 libcutil 库。
3） Shell 脚本
Android 提供了命令行 setprop 和 getprop 来设置和获取属性，他们可以在脚本中被使用。
由于我的程序是在 JNI 中调用脚本，脚本中又执行 ifconfig ，因此我将设置属性的部分放在了脚本中完成，代码如下：
setprop ctl.start ifconfig_test
#wait for the service until it stops
ret=1
while [ $ret -ne 0 ]
do
getprop | grep "$ENABLE_MAPPER_SRV" | grep stopped
ret=$?
done
通过上面 4 个步骤， Android 应用程序就获得了 root 权限，更具体的说，是在执行我们需要执行的命令时临时获得了 root 权限。
转载仅供参考，版权属于原作者。祝你愉快，满意请~~哦
㈦ 如何用adb获得android system的权限
Android应用程序只在有限的范围内有读取权限，如/data/data/*.*.*/，而如果想让app访问其它地方的资源时，就必须要获取更高的权限，像system或者root，root的获取方法也是基于system的，因此本文先完成system权限的获取，实际上一般的应用有system的权限基本上也够了。
1、修改apk内的AndroidManifest.xml
在manifest节点中加入android:sharedUserId="android.uid.system"
2、编译工程产生apk文件
eclipse自动就帮你产生
3、解压缩工具打开*.apk
删除META-INF文件夹中的CERT.RSA和CERT.SF两个文件
4、给*.apk文件签名
这步需要在android源码中进行
1)cd build/tools/signapk
2)javac signapk.java(这里产生*.class)
3)mkdir test/com/android/signapk
4)cp *.class test/com/android/signapk
5)jar cvfm signapk.jar SignApk.mf -C test/ .(这里产生signapk.jar)
5、制作签名后的apk文件
1)mkdir SignApk
2)步骤4中产生的signapk.jar拷贝到SignApk文件夹中
3)cp build/target/proct/security/{platform.x509.pem,platform.pk8} SignApk
4)将apk也拷贝到SignApk中
5)java -jar signapk.jar platform.x509.pem platform.pk8 *.apk new.apk
6、制作新的image文件
将new.apk导入到android源码目录中(一般是out/target/proct/平台/system/app/下)，编译生成新的system.img，再download到开发板
7、测试
如果app涉及到文件读写，可以待系统启动后adb shell到板子上,ls -l查看app安装目录(/data/data/*/*/*/)的权限，看看是不是变成system:system了。
㈧ Android如何获得系统（system）权限
Android中如何修改系统时间(应用程序获得系统权限)在android的API中有提供 SystemClock.setCurrentTimeMillis()函数来修改系统时间，可惜无论你怎么调用这个函数都是没用的，无论模拟器还是真机，在logcat中总会得到"Unable to open alarm driver: Permission denied ".这个函数需要root权限或者运行与系统进程中才可以用。 本来以为就没有办法在应用程序这一层改系统时间了，后来在网上搜了好久，知道这个目的还是可以达到的。 第一个方法简单点，不过需要在Android系统源码的环境下用make来编译： 1. 在应用程序的AndroidManifest.xml中的manifest节点中加入 android:sharedUserId="android.uid.system"这个属性。 2. 修改Android.mk文件，加入LOCAL_CERTIFICATE := platform这一行 3. 使用mm命令来编译，生成的apk就有修改系统时间的权限了。 第二个办法麻烦点，不过不用开虚拟机跑到源码环境下用make来编译： 1. 同上，加入android:sharedUserId="android.uid.system"这个属性。 2. 使用eclipse编译出apk文件，但是这个apk文件是不能用的。 3. 用压缩软件打开apk文件，删掉META-INF目录下的CERT.SF和CERT.RSA两个文件。 4. 使用目标系统的platform密钥来重新给apk文件签名。这步比较麻烦， 首先找到密钥文件，在我的Android源码目录中的位置 是"build argetproctsecurity"，下面的platform.pk8和platform.x509.pem 两个文件。 然后用Android提供的Signapk工具来签名，signapk的源代码是 在"build oolssignapk"下， 用法为"signapk platform.x509.pem platform.pk8 input.apk output.apk"， 文件名最好使用绝对路径防止找不到，也可以修改源代码直接使用。 这样最后得到的apk和第一个方法是一样的。 最后解释一下原理，首先加入android:sharedUserId="android.uid.system"这个属性。通过Shared User id,拥有同一个User id的多个APK可以配置成运行在同一个进程中。那么把程序的UID配成android.uid.system，也就是要让程序运行在系统进程中，这样就有权限来修改系统时间了。 只是加入UID还不够，如果这时候安装APK的话发现无法安装，提示签名不符，原因是程序想要运行在系统进程中还要有目标系统的platform key，就是上面第二个方法提到的platform.pk8和platform.x509.pem两个文件。用这两个key签名后apk才真正可以放入系统进程中。第一个方法中加入LOCAL_CERTIFICATE := platform其实就是用这两个key来签名。这也有一个问题，就是这样生成的程序只有在原始的Android系统或者是自己编译的系统中才可以用，因为这样的系统才可以拿到 platform.pk8和platform.x509.pem两个文件。要是别家公司做的Android上连安装都安装不了。试试原始的Android 中的key来签名，程序在模拟器上运行OK，不过放到G3上安装直接提示"Package ... has no signatures that match those in shared user android.uid.system"，这样也是保护了系统的安全。最最后还说下，这个android:sharedUserId属性不只可以把apk放到系统进程中，也可以配置多个APK运行在一个进程中，这样可以共享数据，应该会很有用的。
㈨ Android的权限都有哪些
（一）linux文件系统上的权限
-rwxr-x--x system system 4156 2010-04-30 16:13 test.apk
代表的是相应的用户/用户组及其他人对此文件的访问权限，与此文件运行起来具有的权限完全不相关。
比如上面的例子只能说明system用户拥有对此文件的读写执行权限；system组的用户对此文件拥有读、执行权限；其他人对此文件只具有执行权限。
而test.apk运行起来后可以干哪些事情，跟这个就不相关了。
千万不要看apk文件系统上属于system/system用户及用户组，或者root/root用户及用户组，就认为apk具有system或root权限
（二）Android的权限规则
（1)Android中的apk必须签名
这种签名不是基于权威证书的，不会决定某个应用允不允许安装，而是一种自签名证书。
重要的是，android系统有的权限是基于签名的。比如：system等级的权限有专门对应的签名，签名不对，权限也就获取不到。
默认生成的APK文件是debug签名的。
获取system权限时用到的签名，见：如何使Android应用程序获取系统权限
（2）基于UserID的进程级别的安全机制
大家都知道，进程有独立的地址空间，进程与进程间默认是不能互相访问的，是一种很可靠的保护机制。
Android通过为每一个安装在设备上的包（apk）分配唯一的linux userID来实现，名称为"app_"加一个数字，比如app_43
不同的UserID，运行在不同的进程，所以apk之间默认便不能相互访问。
Android提供了如下的一种机制，可以使两个apk打破前面讲的这种壁垒。
在AndroidManifest.xml中利用sharedUserId属性给不同的package分配相同的userID，通过这样做，两个package可以被当做同一个程序，
系统会分配给两个程序相同的UserID。当然，基于安全考虑，两个package需要有相同的签名，否则没有验证也就没有意义了。
（这里补充一点:并不是说分配了同样的UserID，两程序就运行在同一进程, 下面为PS指令摘取的，
显然，system、app_2分别对应的两个进程的PID都不同，不知Android到底是怎样实现它的机制的）
User PID PPID
system 953 883 187340 55052 ffffffff afe0cbcc S system_server
app_2 1072 883 100264 19564 ffffffff afe0dcc4 S com.android.inputmethod.
system 1083 883 111808 23192 ffffffff afe0dcc4 S android.process.omsservi
app_2 1088 883 156464 45720 ffffffff afe0dcc4 S android.process.acore
（3）默认apk生成的数据对外是不可见的
实现方法是：Android会为程序存储的数据分配该程序的UserID。
借助于Linux严格的文件系统访问权限，便实现了apk之间不能相互访问似有数据的机制。
例：我的应用创建的一个文件，默认权限如下，可以看到只有UserID为app_21的程序才能读写该文件。
-rw------- app_21 app_21 87650 2000-01-01 09:48 test.txt
如何对外开放？
<1> 使用MODE_WORLD_READABLE and/or MODE_WORLD_WRITEABLE 标记。
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.
（4）AndroidManifest.xml中的显式权限声明
Android默认应用是没有任何权限去操作其他应用或系统相关特性的，应用在进行某些操作时都需要显式地去申请相应的权限。
一般以下动作时都需要申请相应的权限：
A particular permission may be enforced at a number of places ring 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 or starting a service.
在应用安装的时候，package installer会检测该应用请求的权限，根据该应用的签名或者提示用户来分配相应的权限。
在程序运行期间是不检测权限的。如果安装时权限获取失败，那执行就会出错，不会提示用户权限不够。
大多数情况下，权限不足导致的失败会引发一个 SecurityException， 会在系统log（system log）中有相关记录。
（5）权限继承/UserID继承
当我们遇到apk权限不足时，我们有时会考虑写一个linux程序，然后由apk调用它去完成某个它没有权限完成的事情，很遗憾，这种方法是行不通的。
前面讲过，android权限是经营在进程层面的，也就是说一个apk应用启动的子进程的权限不可能超越其父进程的权限（即apk的权限），
即使单独运行某个应用有权限做某事，但如果它是由一个apk调用的，那权限就会被限制。
实际上，android是通过给子进程分配父进程的UserID实现这一机制的。
（三）常见权限不足问题分析
首先要知道，普通apk程序是运行在非root、非system层级的，也就是说看要访问的文件的权限时，看的是最后三位。
另外，通过system/app安装的apk的权限一般比直接安装或adb install安装的apk的权限要高一些。
言归正传，运行一个android应用程序过程中遇到权限不足，一般分为两种情况:
（1）Log中可明显看到权限不足的提示。
此种情况一般是AndroidManifest.xml中缺少相应的权限设置，好好查找一番权限列表，应该就可解决，是最易处理的情况。
有时权限都加上了，但还是报权限不足，是什么情况呢？
Android系统有一些API及权限是需要apk具有一定的等级才能运行的。
比如 SystemClock.setCurrentTimeMillis()修改系统时间，WRITE_SECURE_SETTINGS权限好像都是需要有system级的权限才行。
也就是说UserID是system.
（2）Log里没有报权限不足，而是一些其他Exception的提示,这也有可能是权限不足造成的。
比如：我们常会想读/写一个配置文件或其他一些不是自己创建的文件，常会报java.io.FileNotFoundException错误。
系统认为比较重要的文件一般权限设置的也会比较严格，特别是一些很重要的(配置)文件或目录。
如
-r--r----- bluetooth bluetooth 935 2010-07-09 20:21 dbus.conf
drwxrwx--x system system 2010-07-07 02:05 data
dbus.conf好像是蓝牙的配置文件，从权限上来看，根本就不可能改动，非bluetooth用户连读的权利都没有。
/data目录下存的是所有程序的私有数据，默认情况下android是不允许普通apk访问/data目录下内容的，通过data目录的权限设置可知，其他用户没有读的权限。
所以adb普通权限下在data目录下敲ls命令，会得到opendir failed, Permission denied的错误，通过代码file.listfiles()也无法获得data目录下的内容。
㈩ 如何使android应用程序获取system权限
不论何种系统版本，均需要root权限。
安卓4.4以下版本的方法：
使用re管理器移动想要获取system权限的软件的apk安装包到/system/app文件夹，更改权限为rw-r-r确定后重启手机。
安卓4.4和以上版本的方法：
使用re管理器移动想要获取system权限的软件的apk安装包到/system/priv-app文件夹，更改权限为rw-r-r确定后重启手机。
备注：安卓系统并不像windows，system权限（uid1000）并不是最高权限，仅仅比普通用户拥有少量的特殊权限，比如安装软件无需弹窗。而系统中最高权限是root权限（uid0）。