Antecedentes del problema multiusuario
Registre los problemas de adaptación multiusuario:
El trasfondo es que se han insertado dos nuevas apk en el sistema/aplicación, una es nuestra apk de escenario comercial y la otra es la apk del servicio CarService de automóvil virtual. Nuestra apk necesita vincularse al servicio CarService y comunicarse a través de AIDL.
Las dos imágenes siguientes no tienen roo (el usuario actual del automóvil es usuario14 y el ID de usuario del automóvil virtual es 0): No se puede encontrar el automóvil virtual y el automóvil virtual sigue fallando en el registro: Error en la verificación de ServiceManager.addService
A continuación, el registro después de activar la raíz es:
Es increíble. Este artículo trata sobre por qué la comunicación puede ser normal después de activar Root:
Los sistemas de vehículos que utilizamos en el pasado eran todos de un solo usuario, por lo que no había problema de que diferentes usuarios no compartieran datos; sin embargo, recientemente surgió un nuevo proyecto con un sistema de vehículos que utiliza un sistema multiusuario. Alguna información sobre multiusuarios. Puedes echarle un vistazo. La siguiente declaración:
Conocimiento del sistema multiusuario.
1. En el estado multiusuario, el proceso de creación de usuarios consiste en compartir el directorio del sistema/aplicación, pero los parámetros se modifican (su ID de usuario predeterminado es 0) y el directorio de datos/aplicación se reinstala (el ID de usuario se determina durante la instalación). , y lo mismo ocurre con la instalación bajo múltiples usuarios) )
2. Para iniciar los cuatro componentes principales, debe especificar el usuario aceptado correspondiente (usuario actual predeterminado del sistema)
3. La comunicación Binder del servidor del sistema llevará el ID de usuario. Si el servicio no existe en el ID de usuario actual, no se puede encontrar el Binder correspondiente (porque el usuario actual es 10, pero el usuario en systemapp es 0 y debe estar rooteado antes de la comunicación). puede ser llevado a cabo)
4. Duopen utiliza este método multiusuario, siempre que el uid sea diferente (userid*10000+appid). El appid es el mismo, pero el userid es diferente, por lo que el uid es diferente, por lo que puedes abrir varias aplicaciones. Pero, ¿cómo se comunican los diferentes usuarios?
5. Cuando la aplicación lee la ruta de la tarjeta SD de almacenamiento y el directorio privado de la aplicación, en realidad se conectará suavemente a la partición del directorio de usuario correspondiente.
Por lo tanto, el cambio multiusuario consiste esencialmente en cambiar la información de almacenamiento y lectura de datos/aplicaciones a un directorio; para la aplicación del sistema, solo modifica algunos parámetros y cambia algunos atributos del sistema; para el administrador de servicios, cambia a otro directorio. El grupo de subprocesos de carpeta utilizado por el usuario (es por eso que los autos virtuales se pueden agregar al administrador de servicios después de la raíz)
6. Por lo tanto, una cosa que debemos considerar al usar multiusuario es cómo permitir que nuestra aplicación se comunique con la aplicación del sistema, que son dos usuarios diferentes. El inicio predeterminado del automóvil y la máquina es el ID de usuario 10, pero la aplicación en el sistema es el usuario 0. La premisa de la comunicación es que el grupo de subprocesos de carpeta de la aplicación en el usuario actual del automóvil y la máquina debe tener la carpeta del servicio del sistema . conduce a un conflicto. El usuario del automóvil y la máquina es de hecho un usuario del sistema 10. 0. Explicaré cómo resolverlo más adelante.
7. El sistema puede ser restringido y puede restringir el ID de usuario al que debe pertenecer la APP correspondiente. (Este es también el enfoque de este artículo porque este punto de conocimiento es nuestra solución)
¿Cuáles son los problemas causados por múltiples usuarios y por qué?
El primer problema es que nuestro proceso sigue reconectándose al vincular el Servicio.
El usuario predeterminado para el sistema de inicio del automóvil es usuario10 , pero el servicio al que debemos vincularnos está en usuario0. Incluso si nuestro APK y nuestro automóvil virtual son usuario0, no podemos conectarnos. De acuerdo con el tercer punto mencionado anteriormente:
El Binder al que debemos vincularnos es el usuario actual del sistema vinculado, que es el usuario10, por lo que al usar el servicio, se informó una excepción que indica que no se puede encontrar el Servicio . Debido a que este servicio no está bajo el usuario10 en absoluto, está bajo el usuario0, por lo que el enlace natural falla.
El segundo problema es que el automóvil virtual sigue informando la excepción de falla de verificación de ServiceManager.addService.
Esto también es fácil de entender. Al agregar un servicio del sistema, el ServiceManager verificará si el usuario actual del sistema y el usuario correspondiente del Servicio que se agregará son consistentes. Si son inconsistentes (y no se pueden encontrar), la adición no ser permitido.
¿Como resolver el problema?
Aquí están las respuestas a las preguntas planteadas en el sexto punto de conocimiento anterior:
La forma más sencilla es cambiar el usuario ROOT, use adb root para cambiar al usuario del sistema user0 y podrá conectarse al servicio normalmente, y el automóvil virtual también se puede agregar al ServiceManager normalmente.
La razón es que el administrador de servicio del usuario0 puede recuperar este servicio de automóvil virtual.
Recuerde finalizar el proceso después de cambiar de usuario. Aunque AMS finaliza el proceso durante el cambio de usuario, los datos aún se conservarán y los datos del usuario 10 se seguirán utilizando.
Pero el problema nunca se puede resolver tan fácilmente. Los estudiantes de prueba deben rootear manualmente cuando necesitan realizar la prueba. Afortunadamente, ¿qué pasa si son usuarios? Los usuarios no pueden rootear, por lo que tienen que encontrar otras soluciones. Afortunadamente, esta tarde descubrí un problema particularmente extraño . fenómeno:
Un punto de ruptura particularmente extraño
Otro colega de nuestro departamento, su aplicación también está en sistema/aplicación, pero el ID de usuario siempre es usuario10. Tengo una pregunta: ¿No debería ser usuario0 todo lo que hay en el sistema/aplicación? ¿Cómo es posible que el suyo sea 10? Más tarde, después de charlar con su líder, descubrí que su aplicación se ha comunicado con la ROM con anticipación y puede limitar su ID de usuario, por lo que su ID de usuario siempre ha sido 10.
Problema resuelto~
Por lo tanto, tenemos una solución para comunicarnos con el automóvil virtual. Así es: decirle al fabricante de la ROM que limite el ID de usuario del automóvil virtual a 10, para que nuestra aplicación pueda conectarse normalmente al servicio bajo el usuario 10 que se inicia de forma predeterminada . en el sistema.El servicio de automóvil virtual también se puede agregar al SystemServer bajo usuario10 .
Resolver las secuelas provocadas por
El problema está solucionado, pero hay una secuela grave que me molesta:
Primero saquemos la conclusión: APP1 después de userid10 está restringida por ROM, solo puede iniciar el proceso de userid10.
Lo mismo es que el sistema/aplicación no tiene límite de ID de usuario, ¿por qué es ID de usuario10?
Surge una pregunta: el otro proceso APP2 también está en el sistema. Aunque su ID de usuario no está restringido por la ROM, su ID de usuario también es 10. ¿A qué se debe esto? ? ? La única diferencia es que APP1 volverá a abrir APP2.
Después de conocer esta única diferencia, excluyendo todas las constantes, la única variable es el ID de usuario de APP1. O, en términos más generales, qué ID de usuario es su aplicación, entonces el proceso que inicia también es el ID de usuario.
Debido a que diferentes usuarios están aislados, si él es la APLICACIÓN del usuario10, entonces solo puede iniciar la APLICACIÓN del usuario10. Esta secuela es algo que me he estado preguntando desde entonces, y de repente me quedó claro en este punto. Permítanme terminar este artículo con un resumen de los puntos de conocimiento:
Olvidé mencionar un punto importante en los puntos de conocimiento anteriores:
Cuando APP1 abre otra APP2, ¿cuál es el ID de usuario de APP2?
La respuesta es que no tiene nada que ver con el usuario actual del sistema, diferentes usuarios están aislados, el ID de usuario de APP2 y el ID de usuario de APP1 son los mismos.
Es decir, si la misma APP1 bajo diferentes usuarios quiere comunicarse con otra APP2, la base para determinar si puede abrir otra APP2 es juzgar si hay un proceso de APP2 bajo el ID de usuario de APP1. No es necesario levantarlo. Si no, no se iniciará. Es necesario volver a crear el proceso.
Para dar un ejemplo específico:
El usuario predeterminado del sistema sigue siendo usuario10 y nuestro ID de usuario de proceso es 0 (en sistema/aplicación). Una aplicación con un ID de usuario de 10 necesita iniciar nuestro proceso. Determinará que el ID de usuario de esta aplicación es 10, luego buscará bajo el ID de usuario 10 y encontrará que no existe nuestro proceso , por lo que iniciará un proceso nuestro. con un ID de usuario de 10 nuevamente .
En este momento, tenemos dos procesos, uno es usuario0, que el sistema inicia de forma predeterminada, y el otro lo inicia el proceso userid10.
Link de referencia
Este artículo habla sobre la adaptación multiusuario.
Este artículo trata sobre clones de aplicaciones.
Conocimiento básico:
(Presenta principalmente la diferencia entre userid, uid y appid)
Preservación y reconstrucción de procesos bajo multiusuario:
(Es mejor centrarse en el proceso de cambio, creación y eliminación de múltiples usuarios en estos dos artículos. Los puntos básicos no son tan buenos como el primer enlace)
Este artículo se reimprime en: Problemas de adaptación para sistemas multiusuario vehículo-máquina - Nuggets (juejin.cn)
Enlace a la página de inicio: página de inicio personal de Beiyang - Artículos - Nuggets (juejin.cn)