다중 사용자 문제의 배경
다중 사용자 적응 문제를 기록합니다.
배경은 두 개의 새로운 apk가 시스템/앱 아래에 푸시되었다는 것입니다. 하나는 비즈니스 시나리오 apk이고 다른 하나는 가상 자동차 CarService 서비스의 apk입니다. 우리의 apk는 CarService 서비스에 연결되고 AIDL을 통해 통신해야 합니다.
다음 두 사진에는 루가 없습니다(현재 자동차 사용자는 user14이고 가상 자동차의 사용자 ID는 0입니다): 가상 자동차를 찾을 수 없으며 가상 자동차가 로그에서 계속 충돌합니다: ServiceManager.addService 확인 실패
다음으로 루트를 켠 후의 로그는 다음과 같습니다.
놀랍습니다. 이 기사는 루트를 켠 후 통신이 정상적으로 될 수 있는 이유에 대해 설명합니다.
기존에 우리가 사용했던 차량 시스템은 모두 단일 사용자 시스템이라 서로 다른 사용자가 데이터를 공유하지 않는 문제가 없었지만, 최근 새로운 프로젝트에서는 다중 사용자 시스템인 차량 시스템을 사용했습니다. 다중 사용자를 살펴보세요. 다음 문장을 살펴보세요.
다중 사용자 시스템 지식
1. 다중 사용자 상태에서 사용자 생성 프로세스는 system/app 디렉토리를 공유하지만 매개변수가 수정되고(사용자 ID 기본값은 0임) data/app 디렉토리가 다시 설치됩니다(사용자 ID는 설치 중에 결정됩니다) , 다중 사용자 설치의 경우에도 마찬가지입니다.) )
2. 네 가지 주요 구성 요소를 시작하려면 해당 허용 사용자(기본 시스템 현재 사용자)를 지정해야 합니다.
3. systemServer의 바인더 통신은 UserId를 전달하며, 현재 UserId에 서비스가 없으면 해당 바인더를 찾을 수 없습니다. (현재 사용자는 10이지만 systemapp의 사용자는 0이고 통신하기 전에 루팅해야 하기 때문입니다.) 수행될 수 있음)
4. Duopen은 uid가 다른 경우(userid*10000+appid) 다중 사용자 방법을 사용합니다. appid는 같지만 userid가 다르기 때문에 uid가 다르기 때문에 여러 개의 앱을 열 수 있습니다. 하지만 서로 다른 사용자는 어떻게 의사소통을 할까요?
5. 앱이 저장소 SD 카드 경로와 앱 개인 디렉터리를 읽으면 실제로 해당 사용자 디렉터리의 파티션에 소프트 연결됩니다.
따라서 다중 사용자 전환은 본질적으로 데이터/앱의 저장 및 읽기 정보를 디렉터리로 변경하는 것이며, 시스템 앱의 경우 일부 매개변수만 수정하고 시스템의 일부 속성만 변경하고, 서비스 관리자의 경우 다른 디렉터리로 전환하는 것입니다. .사용자가 사용하는 바인더 스레드 풀 (이것이 가상 자동차가 루트 이후에 servicemanager에 추가될 수 있는 이유입니다)
6. 따라서 다중 사용자를 사용할 때 고려해야 할 한 가지 사항은 우리 앱이 두 명의 다른 사용자인 시스템 앱과 통신하도록 하는 방법입니다. 자동차와 기계의 기본 시작은 userid10이지만 시스템 아래의 앱은 user0입니다. 통신의 전제는 현재 자동차와 기계 사용자 아래의 앱의 바인더 스레드 풀에 시스템 서비스의 바인더가 있어야 한다는 것입니다 . 충돌이 발생합니다. 자동차와 기계 사용자는 실제로 10 시스템 사용자입니다. 0 나중에 해결 방법을 설명하겠습니다.
7. 시스템은 제한될 수 있으며, 해당 앱이 반드시 속해야 하는 사용자 ID를 제한할 수 있습니다. (이 지식 포인트가 우리의 솔루션이기 때문에 이 기사의 초점이기도 합니다.)
다수의 사용자로 인해 발생하는 문제는 무엇이며 그 이유는 무엇입니까?
첫 번째 문제는 서비스를 바인딩할 때 프로세스가 계속 다시 연결된다는 것입니다.
자동차 시동 시스템의 기본 사용자는 user10 이지만 연결해야 할 서비스는 user0 아래에 있습니다. APK와 가상 자동차가 모두 user0 이라도 연결할 수 없습니다. 위에 나열된 세 번째 사항에 따르면:
우리가 연결해야 할 바인더는 바인딩된 현재 시스템 사용자인 user10이므로, 서비스 이용 시 서비스를 찾을 수 없다는 예외가 보고되었습니다 . 이 서비스는 전혀 user10 아래에 있지 않기 때문에 user0 아래에 있으므로 자연 링크가 실패합니다.
두 번째 문제는 가상 자동차가 ServiceManager.addService 확인 실패 예외를 계속 보고한다는 것입니다.
이 역시 이해하기 쉽습니다. 시스템 서비스를 추가할 때 ServiceManager는 현재 시스템 사용자와 추가할 서비스의 해당 사용자가 일치하는지 확인합니다. 일치하지 않는 경우(찾을 수 없는 경우) 추가 작업이 수행되지 않습니다. 허용됩니다.
문제를 해결하는 방법?
위의 여섯 번째 지식 포인트에서 제기된 질문에 대한 답변은 다음과 같습니다.
가장 간단한 방법은 ROOT 사용자를 전환하는 방법인데, adb root를 이용해 시스템 사용자 user0으로 전환하면 정상적으로 서비스에 접속할 수 있고, 가상자동차도 ServiceManager에 정상적으로 추가할 수 있습니다.
그 이유는 user0 아래의 서비스 관리자가 이 가상 자동차 서비스를 검색할 수 있기 때문입니다.
사용자 전환 후 프로세스를 종료하는 것을 잊지 마십시오.AMS가 사용자 전환 중에 프로세스를 종료하더라도 데이터는 계속 유지되며 user10의 데이터는 계속 사용됩니다.
하지만 문제는 결코 그렇게 쉽게 해결될 수 없습니다. 피험자는 테스트가 필요할 때 수동으로 루팅해야 합니다. 다행스럽게도 사용자라면 어떻게 될까요? 사용자는 루팅이 불가능하므로 다른 해결 방법을 찾아야 합니다. 다행히 오늘 오후에 유난히 이상한 점을 발견했습니다 . 현상:
특히 이상한 한계점
우리 부서의 또 다른 동료인 그의 APP도 system/app 아래에 있지만 사용자 ID는 항상 user10입니다. 질문이 있습니다. 시스템/앱 아래의 모든 항목이 user0이어야 하지 않나요? 어떻게 그의 숫자가 10일 수 있습니까? 나중에 그들의 리더와 이야기를 나눈 후에 나는 그들의 APP가 사전에 ROM과 통신하고 그들의 사용자 ID를 제한할 수 있으므로 그들의 사용자 ID는 항상 10이라는 것을 발견했습니다.
문제 해결~
따라서 우리는 가상 자동차와 통신하기 위한 솔루션을 가지고 있습니다. 맞습니다: ROM 제조업체에 가상 자동차의 사용자 ID를 10으로 제한하도록 지시하여 우리 앱이 기본적으로 시작되는 user10 아래의 서비스에 정상적으로 연결할 수 있도록 합니다 . 시스템 가상 자동차 서비스 user10 아래의 SystemServer에 추가할 수도 있습니다 .
이로 인한 후유증을 해결하다
문제는 해결됐지만, 마음을 괴롭히는 심각한 후유증이 있습니다.
먼저 결론을 내리겠습니다. userid10이 ROM에 의해 제한되면 APP1은 userid10의 프로세스만 시작할 수 있습니다.
마찬가지로 시스템/앱에는 userid에 대한 제한이 없습니다. 왜 userid10인가요?
질문이 생깁니다: 다른 프로세스 APP2도 시스템 아래에 있습니다. 해당 사용자 ID는 ROM에 의해 제한되지 않지만 해당 사용자 ID도 10입니다. 이유는 무엇입니까? ? ? 유일한 차이점은 APP2가 APP1에 의해 다시 풀업된다는 것 입니다.
모든 상수를 제외하고 이 유일한 차이점을 알고 나면 유일한 변수는 APP1의 사용자 ID입니다. 또는 더 광범위하게 말하면 어떤 사용자 ID가 앱인지, 실행하는 프로세스도 사용자 ID입니다.
다른 사용자가 격리되어 있으므로 user10의 앱인 경우 user10의 앱만 시작할 수 있습니다. 이 후유증은 예전부터 궁금했던 내용인데, 이때 갑자기 명확해졌습니다. 지식 포인트를 요약하며 이 글을 마무리하겠습니다.
위의 지식 포인트에서 중요한 점을 언급하는 것을 잊었습니다.
APP1이 다른 APP2를 불러올 때 APP2의 사용자 ID는 무엇입니까?
대답은 시스템의 현재 사용자와는 아무런 관련이 없으며 다른 사용자는 격리되어 있으며 APP2의 사용자 ID와 APP1의 사용자 ID는 동일합니다.
즉, 서로 다른 사용자의 동일한 APP1이 다른 APP2와 통신하려는 경우 다른 APP2를 가져올 수 있는지 여부에 대한 기준은 APP1의 사용자 ID에 APP2의 프로세스가 있는지 여부를 판단하는 것입니다. 끌어올 필요가 없습니다. 그렇지 않으면 시작되지 않습니다. 프로세스를 다시 생성해야 합니다.
구체적인 예를 들면 다음과 같습니다.
시스템 기본 사용자는 여전히 user10이고 프로세스 사용자 ID는 0(system/app 아래)입니다. 사용자 ID가 10인 앱은 우리 프로세스를 가져와야 합니다. 이 앱의 usreid가 10이라고 판단한 다음 사용자 ID 10을 검색하여 우리 프로세스가 없음을 발견하면 우리 프로세스를 가져올 것입니다. 다시 사용자 ID가 10입니다 .
현재 우리에게는 두 개의 프로세스가 있습니다. 하나는 기본적으로 시스템에 의해 시작되는 user0이고 다른 하나는 userid10 프로세스에 의해 풀업됩니다.
참고링크
기본 지식:
(주로 userid, uid, appid의 차이점을 소개합니다)
다중 사용자 환경에서 프로세스 보존 및 재구성:
(이 두 글에서는 다중 사용자 전환, 생성, 삭제 과정에 집중하는 것이 좋습니다. 첫 번째 링크만큼 기본적인 내용은 좋지 않습니다.)
1. 다중 사용자 Android system_environment.get_ulangch의 블로그에 대한 심층적인 이해 - CSDN 블로그
2. Android--다중 사용자 모드_disallow_cross_profile_copy_paste_나는 평범한 사람의 블로그입니다-CSDN 블로그
이 기사는 다음 위치에 재인쇄되었습니다: 차량-기계 다중 사용자 시스템의 적응 문제 - Nuggets (juejin.cn)