android coreApp=true属性以及android4.2及以下多用户进程启动的说明
2018-03-01 17:09
691 查看
1. 关于coreApp=true的说明,在manifest中增加该属性,其实并不是代表该APP具有系统权限,而是把该类app归类为核心APP,核心app其实也是最小android framework系统。那么核心APP的作用是什么呢?在Android3.0之后,Android就增加了加密机制(可以加密机制是可选的,目前R70并没有打开),当系统开机时检测到系统加密,他就把核心APP全部启动,并显示UI提供用户输入密码,密码正确后才会启动完整系统。
android加密部分的说明可以参考下面文章;
http://blog.csdn.net/love_xsq/article/details/50156077
2. 在多用户系统下,我们会看到一些进程始终只有一个,比如system_process, android系统有两种方式其他system server。
1.在init.rc启动system server,从init.rc启动的system server是永远只会有一个进程的。
2.通过 framework中的api启动,这个会调用的dalvik中的native code。在dalivk的native code中会在去判断请求属于system server还是普通app进程。
普通的app,即没有增加sharedUserId=”android.uid.system”属性这些,
在系统默认启动后,我们看到可能就是u0_a10,新增用户下,启动后看到的就是u10_a10。
而通过api启动的system server进程有两情况,一种就是类似init.rc的方式,只有一个进程;另外一种也会两个进程。
只有一个进程的是由什么决定的呢?有两个方面的因素:
1.必须有系统权限,即有sharedUserId=”android.uid.system”属性
2.必须有android:persistent=”true”属性,也就该进程常驻系统,永远不会被杀掉。
当具备上面两个属性时,即使在多用户下,启动带该属性的app,也只会有一个进程,该进程的用户为system。
Android系统可能认为,但是app常驻,同时又是系统进程,该app可能行为就和system server相同。
对这样的app,如果我们kill掉其进程,也会导致android重启,如同去杀掉了system server进程一样。
而在多用户下,带有system权限的app,如何启动在不同的进程呢?
其实只要app不具备android:persistent=”true”,就可达到该目的。
这样的app在启动后,在默认用户下,我们看到的进程用户为 system,但是在其他用户下,可能看到的用户就为u10_system。
android加密部分的说明可以参考下面文章;
http://blog.csdn.net/love_xsq/article/details/50156077
2. 在多用户系统下,我们会看到一些进程始终只有一个,比如system_process, android系统有两种方式其他system server。
1.在init.rc启动system server,从init.rc启动的system server是永远只会有一个进程的。
2.通过 framework中的api启动,这个会调用的dalvik中的native code。在dalivk的native code中会在去判断请求属于system server还是普通app进程。
普通的app,即没有增加sharedUserId=”android.uid.system”属性这些,
在系统默认启动后,我们看到可能就是u0_a10,新增用户下,启动后看到的就是u10_a10。
而通过api启动的system server进程有两情况,一种就是类似init.rc的方式,只有一个进程;另外一种也会两个进程。
只有一个进程的是由什么决定的呢?有两个方面的因素:
1.必须有系统权限,即有sharedUserId=”android.uid.system”属性
2.必须有android:persistent=”true”属性,也就该进程常驻系统,永远不会被杀掉。
当具备上面两个属性时,即使在多用户下,启动带该属性的app,也只会有一个进程,该进程的用户为system。
Android系统可能认为,但是app常驻,同时又是系统进程,该app可能行为就和system server相同。
对这样的app,如果我们kill掉其进程,也会导致android重启,如同去杀掉了system server进程一样。
而在多用户下,带有system权限的app,如何启动在不同的进程呢?
其实只要app不具备android:persistent=”true”,就可达到该目的。
这样的app在启动后,在默认用户下,我们看到的进程用户为 system,但是在其他用户下,可能看到的用户就为u10_system。
相关文章推荐
- android coreApp=true属性以及android4.2及以下多用户进程启动的说明
- coreApp=true属性及android4.2下多用户进程启动说明
- android chrome iframe设置src属性无法启动app
- android:theme和app:popupTheme的作用,以及在android 3.0以下不起作用问题的解决
- 关于Android的查询CPU、流量、内存以及获取一个app的启动activity
- Android应用程序(app)进程启动过程的源代码分析
- 启动app闪屏问题以及Android自带主题
- android:theme和app:popupTheme的作用,以及在android 3.0以下不起作用问题的解决
- Android Application Launch [ 创建进程--〉绑定App-->启动Activity/Start Service/...]
- Android 进程常驻(3)----native保活5.0以下方案推演过程以及代码详述
- Android通过包名或类名启动APP或者一个Activity 以及 判断APP的运行状态
- 读取用户 的属性时,发现了以下错误:没有启动服务器服务
- Android 进程常驻(3)----native保活5.0以下方案推演过程以及代码
- android:theme和app:popupTheme的作用,以及在android 3.0以下不起作用问题的解决
- Android 的 ramdisk.img、system.img、userdata.img 作用说明,以及UBoot 系统启动过程
- Linux下tomcat作为守护进程运行(开机启动、以指定的用户运行、解决非root身份不能绑定1024以下端口的问题)的配置方法
- Android 6.0 AMS分析的第二条线:以Launcher启动一个Activity为例,分析应用进程的创建、Activity的启动,以及他们和AMS之间的交互等知识;
- Android 的 ramdisk.img、system.img、userdata.img 作用说明,以及UBoot 系统启动过程
- android:theme和app:popupTheme的作用,以及在android 3.0以下不起作用问题的解决
- Android 的 ramdisk.img、system.img、userdata.img 作用说明,以及UBoot 系统启动过程