记一次user版本编译后，app不能启动的解决过程
为什么我们的app在userdebug模式下能正常启动
为什么我们的app在user模式下不能启动
user与userdebug有什么不同呢？
在我们编译系统时
source build 的一就选择lunch 31还是32 ，就直接执行系统编译
总体方案分阶段去处理
因为我们的设备是没有触摸屏的，
当烧录完user的版本时，系统一直出现灰屏
或者灰屏一会儿，就退出到Launcher
这个问题比较好查
我们的主launcher启动app的流程问题，不用管
2.修改系统源码 使能adb及shell
diff --git a/build/core/main.mk b/build/core/main.mk
index a612f835d5..83810091bd 100644
--- a/build/core/main.mk
+++ b/build/core/main.mk
@@ -390,11 +390,11 @@ enable_target_debugging := true
tags_to_install :=
ifneq (,$(user_variant))
# Target is secure in user builds.
- ADDITIONAL_DEFAULT_PROPERTIES += ro.secure=1
+ ADDITIONAL_DEFAULT_PROPERTIES += ro.secure=0
ADDITIONAL_DEFAULT_PROPERTIES += security.perf_harden=1
ifeq ($(user_variant),user)
- ADDITIONAL_DEFAULT_PROPERTIES += ro.adb.secure=1
+ ADDITIONAL_DEFAULT_PROPERTIES += ro.adb.secure=0
endif
ifeq ($(user_variant),userdebug)
@@ -402,7 +402,7 @@ ifneq (,$(user_variant))
tags_to_install += debug
else
# Disable debugging in plain user builds.
- enable_target_debugging :=
+ # enable_target_debugging :=
endif
diff --git a/frameworks/base/services/usb/java/com/android/server/usb/UsbDebuggingManager.java b/frameworks/base/services/usb/java/com/android/server/usb/UsbDebuggingManager.java
index f6d9e9a1a4..8b8bfb42a9 100644
--- a/frameworks/base/services/usb/java/com/android/server/usb/UsbDebuggingManager.java
+++ b/frameworks/base/services/usb/java/com/android/server/usb/UsbDebuggingManager.java
@@ -137,7 +137,10 @@ public class UsbDebuggingManager {
if (buffer[0] == 'P' && buffer[1] == 'K') {
String key = new String(Arrays.copyOfRange(buffer, 2, count));
Slog.d(TAG, "Received public key: " + key);
- Message msg = mHandler.obtainMessage(UsbDebuggingHandler.MESSAGE_ADB_CONFIRM);
+// Message msg = mHandler.obtainMessage(UsbDebuggingHandler.MESSAGE_ADB_CONFIRM);
+ Message msg = mHandler.obtainMessage(UsbDebuggingHandler.MESSAGE_ADB_ALLOW);
+ mFingerprints = getFingerprints(key);
+ msg.arg1 = 1;
msg.obj = key;
diff --git a/system/extras/su/Android.mk b/system/extras/su/Android.mk
index 297e0a31ec..972e2da28a 100644
--- a/system/extras/su/Android.mk
+++ b/system/extras/su/Android.mk
@@ -8,6 +8,6 @@ LOCAL_SRC_FILES:= su.c
LOCAL_MODULE:= su
LOCAL_MODULE_PATH := $(TARGET_OUT_OPTIONAL_EXECUTABLES)
-LOCAL_MODULE_TAGS := debug
+LOCAL_MODULE_TAGS := optional
include $(BUILD_EXECUTABLE)
diff --git a/system/extras/su/su.c b/system/extras/su/su.c
index ea61f93da5..3d6e73dbde 100644
--- a/system/extras/su/su.c
+++ b/system/extras/su/su.c
@@ -81,8 +81,8 @@ void extract_uidgids(const char* uidgids, uid_t* uid, gid_t* gid, gid_t* gids, i
}
int main(int argc, char** argv) {
- uid_t current_uid = getuid();
- if (current_uid != AID_ROOT && current_uid != AID_SHELL) error(1, 0, "not allowed");
+ //uid_t current_uid = getuid();
+ //if (current_uid != AID_ROOT && current_uid != AID_SHELL) error(1, 0, "not allowed");
// Handle -h and --help.
++argv;
2.配置seAndroid
为什么呢。因为user与userdebug可能有这些问题，不要问我确定不？我也不确定，只能保证
这一块没有问题，在查原因，排队呢，谁能一个人将android源码背下来，理解清楚，我服了
不是服了，是五体投地呀
init.rc 添加chmod操作
device_init在/system/core/init/device.c中，
staticstructperms_ devperms[] = {
{"/dev/null", 0666, AID_ROOT, AID_ROOT, 0 },
{"/dev/zero", 0666, AID_ROOT, AID_ROOT, 0 },
在devices.c中修改的方法隐藏的较深不容易被发现，但是如果init.rc内再次修改就可能把之前的修改覆盖掉。
SELinux的三种状态:
Disable: 关闭
Permissive: 宽松状态,违反策略,紧紧是提示而已,操作仍能进行
Enforcing: 执行状态,违反策略,操作会被拒绝执行.
# ls -Z
u:object_r:cgroup:s0 acct
ps -Z 查看进程的安全属性
内核中通过 dmesg | grep avc 来寻找权限失败的地方
解决原则是：缺什么补什么，一步一步补到没有avc denied为止
SEAndroid中的安全上下文
SEAndroid的安全上下文与SELinux基本一致（除了MLS检测在SEAndroid中被强制执行），共有4个部分组成分别为user、role、type、sensitivity，以u:object_r:system_data_file:s0为例：
user：安全上下文的第一列为user，在SEAndroid中的user只有一个就是u。
role：第二列表示role，在SEAndroid中的role有两个，分别为r和object_r。
type：第三列为type，SEAndroid中共定义了139种不同的type。
security level：第四列是专为MLS访问机制所添加的安全上下文的扩展部分，格式为sensitivity[:category list][- sensitivity[:category list]]，例如s0 - s15:c0.c1023，其中s0之后的内容可以不需要，冒号后面的内容是category，sensitivity和category组合一起声明了当前的安全级别(security level)，“-”号左右分别标识了安全级别的最低和最高，这一列的参数将在MLS约束检查时用到，“15”、“1023”表示了sensitivity和category的最大值，这一参数可在Android.mk中定义。
安全上下文中最重要的部分就是第三列的type了，对于进程type被称为domain，type是整个SEAndroid中最重要的一个参量，所有的policy都围绕这一参量展开，所以为系统中每个文件标记上合适的type就显得极为重要了。在SEAndroid中关于安全上下文配置的核心文件主要是file_contexts文件、seapp_contexts文件和ocontexts文件。
domain:
这一attribute包含了如下所列的所有关于进程的type，通常策略中的访问主体也就是进程所在的domain都包含在了这一attribute中。
adbd
trusted_app
browser_app
untrusted_app
bluetoothd
dbusd
debuggerd
drmserver
gpsd
init
installd
kernel
keystore
mediaserver
netd
nfc
qemud
radio
rild
servicemanage
shell
surfaceflinger
su
system_app
system
ueventd
vold
wpa
zygote
fs_type:
这一attribute包含了所有与文件系统相关的type。如下所列，大多是虚拟文件系统。
device
labeledfs
pipefs
sockfs
rootfs
proc
selinuxfs
cgroup
sysfs
sysfs_writable
inotify
devpts
tmpfs
shm
mqueue
sdcard
debugfs
file_type:
这一attribute包含了所有存在于非伪文件系统的相关文件的type，数量过多不再列举。
exec_type:
这一attribute包含了所有关于domian接入点的type，多被用在domain transition中，如下所列。
bluetoothd_exec
dbusd_exec
debuggerd_exec
drmserver_exec
gpsd_exec
installd_exec
keystore_exec
mediaserver_exec
netd_exec
qemud_exec
rild_exec
servicemanager_exec
surfaceflinger_exec
vold_exec
wpa_exec
zygote_exec
data_file_type:
这一attribute包含了所有在/data目录下的文件type，如下所列。
system_data_file
anr_data_file
tombstone_data_file
apk_data_file
dalvikcache_data_file
shell_data_file
gps_data_file
bluetoothd_data_file
bluetooth_data_file
keystore_data_file
vpn_data_file
systemkeys_data_file
wifi_data_file
radio_data_file
nfc_data_file
app_data_file
sysfs_type:
这一attribute包含了在sysfs文件系统下的所有文件的type，在SEAndroid中只有sysfs_writable包含在这个attribute中。
node_type:
这一attribute包含了所有与nodes/hosts有关的type，在SEAndroid中只有node包含在这个attribute中。
netif_type:
这一attribute包含了所有与网络接口相关的type，在SEAndroid中只有netif包含在这个attribute中。
port_type:
这一attribute包含了所有与网络端口相关的type，在SEAndroid中只有port包含在这个attribute中。
mlstrustedsubject:
这一attribute包含了所有能越过MLS检查的主体domain。
mlstrustedobject:
这一attribute包含了所有能越过MLS检查的客体type。
unconfineddomain:
domain.te
主要是为domain属性制定策略，为所有归在其中的访问主体制定一些公共的策略。
CTS.te
主要是为appdomain制定策略，这些策略一般是在对app进行CTS测试时用到。
bluetooth.te
主要是为bluetoothdomain制定策略。
net.te
主要是为netdomain制定策略，这些策略主要是关于对sockets、ports的访问以及与netd的通信。
file.te
这个文件主要定义了各文件系统的type，各文件的type，socket的type，以及制定了在不同文件系统中创建文件的规则。
针对daemon domain的策略制定:
adbd.te、gpsd.te、netd.te、bluetoothd.te、zygote.te、ueventd.te、installd.te、vold.te、dbusd.te、keystore.te、debuggerd.te、mediaserver.te、rild.te、drmserver.te、surfaceflinger.te、qemud.te、servicemanager.te、su.te、shell.te、wpa_supplicant.te
这些文件都是为系统中的daemon进程进行策略的制定，它们都有着相应的daemon domain。
针对系统其他模块的策略制定:
最后的7个文件分别对系统的其他模块进行策略制定。
app.te
在这一文件里将安装在系统上的第三方app分类为受信任的app和不受信任的app，分别用不同的type表示，
再分别为这两种app在访问网络，bluetooth，sdcard，数据，缓存，binder等等名感位置时设置相应权限。
system.te
这一文件主要针对的是系统app和system server进程。对系统app访问binder、system data files、dalvikcatch、keystone等进行权限控制，
对system server访问网络、bluetooth、netlink、app、binder、device、data files、socket、cache files等进行权限控制。
init.te
在这一文件中声明了init拥有无限权限。
nfc.te
在这一文件中制定了nfc domain对nfc设备和相关数据文件的访问权限。
kernel.te
在这一文件中声明了kernel拥有无限权限。
radio.te
在这一文件中制定了radio domain对init、rild和相关数据文件的访问权限。
device.te
在这一文件中定义了所有跟设备相关的type，并将这些type都归到了dev_type属性中。
最后确定与SEandroid没有关系，就是seAndroid通过 demsg | grep avc 从目录 进程 没有看到异常
4.必须打通 user版本的 adb root remount权限，才能查看
5.查看正常的 dev 目录
msm8953_64:/dev # ls -lZ ttyHSL3
crwxrwxrwx 1 shell shell u:object_r:ailving_uart_file:s0 242, 3 1970-01-02 16:11 ttyHSL3
msm8953_64:/dev #
msm8953_64:/dev # ps -Z | grep xxxx
u:r:system_app:s0 system 2775 609 2594008 415964 SyS_epoll_ 00ef3a7458 S com.xxxx.car.device
msm8953_64:/dev #
6.修改 ueventd.qcom.rc
7。查看驱动的目录，我的节点建立成功，user模式下，厂商的驱动没有建立成功
/dev/ttyGS0
/dev/tty
一定还有串口的节点
看看我的节点
8.修改驱动配置 --------任务完成