多用户问题出现背景
记录一下多用户的适配问题：
背景是system/app下面新push了两个apk，一个是我们的业务场景apk一个是虚拟车CarService服务的apk，我们的apk需要链接CarService服务通过AIDL通信。
下面这两张图是未roo的情况（当前车机用户是user14，虚拟车的userid是0）： 找不到虚拟车，日志中虚拟车一直在crash：ServiceManager.addService校验未通过
接下来开启root后的日志是：
很神奇吧，这篇文章就是来讲为什么开启Root后可以正常通信的：
我们以往使用的车技都是单用户，因此不存在不同用户不共享数据的问题；但是最近新来了一个项目使用的车机是多用户系统，有关多用户我总结了一些信息，大家可以看下下面的陈述：
多用户的有关系统知识
1.多用户状态下用户新建过程是system/app目录共享只是进行了修改参数（其userid默认为0），data/app目录进行重新安装（其userid是安装时候决定的，多用户下安装也是如此）
2.四大组件启动需要指定对应接受到的用户（默认系统当前用户）
3.systemServer的Binder通信中会携带UserId，如果当前UserId中没有该项服务则找不到对应Binder（因为当前用户为10，但是systemapp下的用户是0需root后才可通信）
4.多开采用的就是这种多用户的方式，uid只要不同就行（userid*10000+appid）。appid是一样的，但是userid不一样所以uid不一样，就可以进行多开。但是不同用户是怎么通信的呢？
5.app读取存储sd卡路径和app私有目录时其实都会软连接到对应的user目录的分区下。
因此多用户切换本质上来说就是将data/app的存储读取信息换了一个目录；对于系统app来说只是修改了些参数，改变了系统的某些属性；对于servicemanager来说是切换到了另外一个用户使用的binder线程池（这也是为什么root后虚拟车就可以添加到servicemanager中的原因）
6.因此我们使用多用户的时候需要考虑的一个点就是怎么能让我们的app和系统app通信，这是两个不同的用户。 车机启动默认是userid10，但是system下面的app是user0.通信的前提是当前车机用户下app的binder线程池中得有系统服务的binder. 这就导致冲突了 车机用户是10系统用户确实0后面讲解如何解决
7.系统是可以限制的，可以限制对应APP必须所属的userid。(这也是这篇文章重点要讲的知识因为这个知识点就是我们的解决方案)
多用户导致的问题是什么和为什么
第一个问题是我们的进程再绑定Service的时候一直在重连
车机启动系统默认的用户是user10，而我们需要链接的服务却是在user0下，即使我们的APK和虚拟车都是user0也连接不上，根据上面罗列出来的第三点可知：
我们需要链接的Binder中是绑定的当前系统用户也就是user10，所以在进行使用服务的时候报了一个找不到Service的异常。因为这个服务压根就不在user10下，他是在user0下的，自然链接失败。
第二个问题是虚拟车一直在报ServiceManager.addService的验证不通过异常
这个也很好理解，在进行添加系统服务时ServiceManager会验证当前系统用户和对应需要添加的Service所属用户是否一致，如果不一致（也就找不到）则不让添加。
问题该如何解决？
这里对上面第六个知识点中提出的问题进行解答：
最简单的方式就是切换ROOT用户，使用adb root切换到系统用户user0下就可以正常链接服务，而且虚拟车也可以正常添加到ServiceManager中了
原因就是user0下的 servicemanager可以检索到这个虚拟车服务了。
切换用户后记得要杀一下进程，切换用户的过程AMS虽说杀死进程但是数据依然会保留，使用的还是user10的数据
但是问题绝不可能这么简单的就带过了，测试同学需要测试的时候必须手动root这个还好，如果是用户呢?用户可不能root，所以还得找其他解决方案，庆幸的是在今天下午我发现了一个特别怪异的现象：
一个特别怪的突破点
我们部门的另外一位同事，他的APP同样也是在system/app下面的，userid却始终是user10。我就有疑问了：system/app下面的不应该都是user0吗？怎么可能他的是10，后来和他们的leader聊了下发现他们的APP是提前和ROM那边沟通好的，可以限制他们的userid，所以他们的userid一直是10
问题解决~
因此我们和虚拟车的沟通也就有了解决方案，没错：就是告知ROM厂商限制虚拟车的userid为10，这样我们的app就可以在系统默认启动的user10用户下正常连接服务，虚拟车服务也可以在user10下添加到SystemServer中。
解决之后带来的后遗症
问题是解决了，但是有一个很严重的后遗症困扰着我：
先把结论放出来：上面被ROM限制userid10后的APP1他拉起的也只能是userid10的进程
同样是system/app没有限制userid为什么他是userid10
疑问点出来了：另外一个也是system下面的进程APP2他虽然没有被ROM限制userid，但是他的userid却也是10，这是为什么呢？？？唯一的不同是这个APP2会被APP1再次拉起
知道这个唯一的不同后，排除所有的常量，唯一的变量就是这个APP1的userid。或者更宽泛一点说你的app是哪个userid那么你拉起的进程也就是哪个userid
因为不同用户是隔离的，如果他是user10的APP的话那么他也就只能拉起user10的APP了。这个后遗症是之后我一直琢磨不明白的地方，到这里我才豁然开朗，接下来给一总结知识点结束这篇文章：
上面的知识点中忘记提到了一个重要的点：
APP1拉起另外一个APP2时，这个拉起的APP2的userid是多少呢？
答案是和系统当前用户无关，不同用户之间是隔离的,APP2的userid和APP1的userid是一样的。
也就是说不同用户下的同一个APP1如果要和另外一个APP2通信的话那么他是否拉起另外一个APP2的依据是判断APP1的userid下是否有APP2的进程如果有就不需要拉起，如果没有就需要重新创建进程。
举个具体的例子：
系统默认用户还是user10，我们的进程userid是0（system/app下）。一个userid为10的APP需要拉起我们的进程，他会判断这个APP的usreid发现是10，然后检索userid10下面发现并没有我们的进程，所以他会再次拉起一个userid为10的我们的进程。
此时我们的进程是有两个的，一个是系统默认启动的user0，一个是被userid10进程拉起来的。
参考链接
基础知识：
（主要是介绍了userid，uid和appid的区别）
多用户下进程的保留与重建：
（这两篇文章还是主要看多用户的切换创建删除流程比较好，基础点讲的没有第一个链接好）
1. 深入理解Android系统多用户_多用户下environment.get_ulangch的博客-CSDN博客
2. Android--多用户模式_disallow_cross_profile_copy_paste_我是普通人的博客-CSDN博客