Android 12의 Fabricated Overlay API는 뿌리 없는 테마를 다시 제공합니다.

완전한 안정 안드로이드 12 출시가 코앞으로 다가왔고 Google에서는 심지어 소스 코드를 게시했습니다 AOSP 저장소에. 거기에 Android 12의 새로운 기능, Fabricated Overlays라는 리소스 오버레이에 대한 추가 기능을 포함합니다. 시스템에서 사용되는 동적 변경 사항을 관리하는 데 도움이 되는 API의 의미는 무엇입니까? 재료 당신 그리고 모네는 적어도 안드로이드 13이 출시될 때까지는 훨씬 더 큰 무언가로 변할 수 있습니다.

배경

Mishaal Rahman은 이 새로운 API를 발견하고 이를 주목하게 되었습니다. 그는 Android 12에서 다양한 리소스 값을 테스트하기 위해 셸 명령을 사용하고 있었습니다. 오버레이 APK를 수동으로 컴파일하기 위해 그는 이것이 루팅된 기기를 위한 흥미로운 앱 아이디어가 될 수 있다고 생각했습니다. 그가 내 관심을 끌었을 때 나는 Android 12의 소스 코드를 많이 살펴보았고 꽤 흥미롭다고 생각되는 것을 발견했습니다. 제가 찾은 것을 테스트했고 이제 여기까지 왔습니다. 알고 보니 Fabricated Overlay API를 사용하면 뿌리 없는 테마를 다시 가져올 수 있습니다. 여기서 무슨 일이 일어나고 있는지 자세히 알아보기 전에 제작된 오버레이가 실제로 무엇인지 설명하겠습니다.

조작된 오버레이란 무엇입니까?

조작된 오버레이는 Android 12에 도입된 새로운 기능입니다. 이는 Android가 몇 년 동안 사용해 온 클래식 RRO(런타임 리소스 오버레이)와 유사합니다. RRO와 Fabricated Overlay는 모두 다양한 애플리케이션에 대해 다양한 리소스를 재정의할 수 있습니다. 부울 값을 false에서 true로(또는 그 반대로) 변경하고 상태 표시줄의 크기 등을 설정할 수 있습니다.

하지만 제작된 오버레이는 RRO와 몇 가지 눈에 띄는 차이점이 있습니다. 우선, 오버레이 APK를 생성한 다음 설치할 필요가 없습니다. 대신, 어떤 애플리케이션에 대해 어떤 값을 변경하고 싶은지 Android에 알려주기만 하면 Android에서 변경 사항을 오버레이로 등록한 다음 활성화할 수 있습니다.

또한 RRO보다 약간 더 제한적입니다. Android 11 이전에는 RRO가 부울, 정수, 크기, 속성, 레이아웃, 심지어 원시 데이터 파일까지 거의 모든 리소스를 재정의할 수 있었습니다. Android 11에서는 RRO 작동 방식을 일부 변경하여 레이아웃 재정의가 더 이상 실제로 불가능해졌습니다. 하지만 RRO가 전반적으로 더 안정적이게 되었습니다.

반면에 조작된 오버레이는 정수로 표시될 수 있는 값만 재정의할 수 있습니다. 여기에는 정수(duh), 차원, 부울 및 색상이 포함됩니다. 이를 사용하여 원시 데이터 리소스, 레이아웃, 문자열 또는 배열을 재정의할 수는 없습니다. 적어도 쉽지는 않습니다. 이는 API의 다소 임의적인 제한 사항입니다. TypedValue 클래스에서 정의한 대로 정수 값과 리소스 범주만 허용합니다. TypedValue는 지원하다 문자열 및 기타 리소스 유형은 해당 리소스를 참조하기 위한 용도일 뿐 실제 데이터를 보유하지는 않습니다.

그러나 이러한 제한은 Fabricated Overlays: Material You 및 모네 효과의 의도된 목적에 비해 그리 큰 문제는 아닙니다. 제작된 오버레이를 사용하면 시스템을 재부팅하거나 APK가 컴파일될 때까지 기다리지 않고도 즉시 색상 및 치수 오버레이를 쉽게 생성하고 적용할 수 있습니다.

일반적으로 이는 루팅된 장치를 사용하는 사람들이 활용할 수 있는 또 다른 깔끔한 API일 뿐입니다. 제조업체가 만든 허점이 없는 한(Synergy가 삼성 장치에서 활용하는 것과 같은) 오버레이는 루트 액세스 권한이 있는 제3자에 의해서만 설치될 수 있습니다. 하지만 이것이 가장 좋은 부분입니다. Google은 Android 12의 결함을 패치하는 것을 잊어버렸습니다.

루트 없이 제작된 오버레이

Android 8에는 새로운 Overlay Manager Service(또는 OMS) API가 도입되었으며 사람들은 오버레이 APK를 일반 앱으로 설치한 다음 ADB를 사용하여 활성화할 수 있다는 사실을 꽤 빨리 발견했습니다. 안타깝게도 Google은 이를 Android 9에서 패치했으며 그 이후로는 시스템과 동일한 키로 서명된 오버레이만 동적으로 설치할 수 있습니다.

알고 보니 Android 12의 조작된 오버레이에는 Android 8에 있는 것과 유사한 허점이 있습니다. 즉, 루트 액세스나 서명 수준 권한이 필요하지 않습니다. 등록하려면 셸 사용자(즉, ADB)로 실행되는 것이 필요합니다.

Google이 조작된 오버레이가 루트 및 시스템 사용자만 액세스할 수 있도록 의도했다는 것은 매우 분명합니다. 이를 생성하기 위한 ADB 명령 구현이 있으며 실행 사용자가 루트가 아닌 경우 실행되지 않습니다. 허점은 검사가 실제 API가 아닌 명령에서만 수행된다는 점입니다. 즉, 약간의 작업을 통해 이를 활용할 수 있습니다.

ADB 온디바이스

오랫동안 Android에는 무선 ADB 기능이 있었습니다. 이를 통해 컴퓨터(또는 ADB 바이너리 및 네트워크 액세스가 가능한 모든 장치)를 장치에 무선으로 연결할 수 있습니다. 이는 주로 사용자가 액세스할 수 있는 USB 연결이 없는 Android 장치(예: 스마트워치와 TV. 또한 Android 11 이전에는 유선 ADB 연결이 필요했습니다. 무선 모드.

Android 11은 공식적으로 무선 ADB를 휴대폰과 태블릿에 도입한 것입니다. 페어링 및 인증 코드가 있어 기존 무선 ADB보다 조금 더 복잡하지만 사용자가 완전히 기기 내에서 활성화할 수 있습니다. 장치가 Wi-Fi에 연결되어 있는 한. 즉, 장치에서 ADB를 통해 장치에 연결할 수 있으며 WiFi만 있으면 됩니다. 연결.

앱에서 상승된 API 사용

앱에서 제한된 API를 사용하려는 데는 여러 가지 이유가 있습니다. 일반적으로 필요한 특별한 기능을 제공하기 때문입니다. 필요한 API에 셸 명령 구현이 있으면 앱에서 사용하기가 매우 쉽습니다. 당신이 해야 할 일은 루트(또는 ADB)로 쉘 프로세스를 생성하고, 올바른 명령을 실행하고, 결과가 있으면 구문 분석하는 것뿐입니다.

API에 셸 구현이 없거나 셸 구현에 필요한 것이 없으면 어떻게 되나요? 루팅된 기기를 사용하고 있다면 다음과 같은 것을 사용할 수 있습니다. libRootJava. libRootJava를 사용하면 앱이 루트 사용자로 실행되는 것처럼 Android 프레임워크 API와 상호작용할 수 있습니다. 이는 모두 동일한 언어로 되어 있고 문자열을 수동으로 구문 분석하는 것에 대해 걱정할 필요가 없기 때문에 셸 명령을 실행하는 것보다 더 편리하고 훨씬 빠릅니다. 몇 가지 제한 사항이 있지만 대부분의 경우 훌륭하게 작동합니다.

libRootJava API는 매우 유연합니다. 루트 대신 쉘 사용자로 실행되도록 조정할 수 있습니다. 다행히도 누군가가 이미 만들었기 때문에 그럴 필요가 없습니다. 시즈쿠. Shizuku는 Magisk Manager와 libRootJava의 조합과 거의 같습니다.

Shizuku Manager 앱은 Shizuku가 액세스할 수 있는 셸 사용자로 실행되는 프로세스를 설정하는 과정을 안내합니다. Shizuku API 라이브러리를 앱에 구현하면 마치 셸 사용자인 것처럼 시스템 API에 액세스할 수 있습니다. Shizuku API 라이브러리를 구현하는 모든 앱에서 Shizuku를 사용할 수 있으려면 Shizuku를 한 번만 설정하면 되기 때문에 이는 libRootJava보다 훨씬 더 중앙 집중화된 프로세스입니다. Shizuku의 작동 방식과 이를 앱에 통합하는 방법에 관심이 있다면, 여기에 대한 가이드가 있습니다.

Shizuku 및 조작된 오버레이

지금쯤이면 이것이 어디로 가는지 알 수 있을 것입니다. Shizuku와 같은 서비스를 사용하여 셸 사용자로 Fabricated Overlays API에 액세스할 수 있으며 Android 11의 무선 ADB 기능을 사용하여 모든 기기에서 셸 수준 액세스를 얻을 수 있습니다. 루트 사용자 제한은 실제 API가 아닌 Fabricated Overlays 셸 명령에만 있으므로 셸 사용자로 실행하면 직접 사용할 수 있습니다.

구현: 라이브러리 및 샘플 앱

구현 세부 사항은 어떻습니까? 글쎄, 나는 당신에게도 그것을 보장해 주었습니다.

이를 대비하여 두 가지를 모두 만들었습니다. 라이브러리 및 모든 기능을 갖춘 샘플 앱 그 라이브러리를 사용하는 것입니다.

도서관 자체는 대부분 편의를 위한 것입니다. 이는 숨겨진 시스템 API 중 일부를 래핑하고 Shizuku 권한을 처리하기 위한 몇 가지 편리한 방법을 제공합니다. 또한 유연하므로 검색할 수 있는 다른 방법이 있는 경우 IOverlayManager API의 자체 인스턴스를 제공할 수 있습니다.

샘플 앱은 Shizuku를 사용하여 라이브러리를 구현하는 방법을 보여줍니다. 또한 모든 기능을 갖춘 유용한 앱입니다. 메인 페이지에는 현재 등록된 제작된 오버레이가 대상 앱별로 그룹화되어 표시됩니다. 여기에서도 활성화, 비활성화 및 삭제할 수 있습니다.

하단의 '오버레이 추가' 버튼을 탭하면 오버레이 가능한 모든 앱 목록이 표시됩니다. 검색하거나 스크롤하여 필요한 항목을 찾아 탭하세요. 그런 다음 화면 하단의 '추가' 버튼을 누르면 해당 앱에서 재정의할 수 있는 리소스 목록을 볼 수 있습니다. 리소스를 선택하고 해당 값을 설정한 후 변경하려는 값만큼 반복합니다. "저장" 버튼을 누르고 이름을 입력하고 확인하면 메인 화면으로 돌아가서 이제 활성화할 준비가 된 새 오버레이가 표시됩니다.

다음은 Mishaal Rahman이 제공한 앱의 스크린샷입니다.

참고로 다음과 같은 일반 오버레이 관리자 앱도 있습니다. 오버레이 관리자. 미리 컴파일된 앱 자체는 다음과 같습니다. 내 Patreon에서만 이용 가능, 하지만 소스코드는 무료로 사용 가능 그것을 컴파일하거나 수정하려는 모든 사람에게.

결론

Android 12의 새로운 Fabricated Overlays API는 루트가 필요하지 않기 때문에 매우 훌륭합니다. 완전한 RRO APK만큼 정교하지는 않지만 루트 액세스 없이 훨씬 더 많은 유연성을 제공합니다.

GitHub에서 Fabricate Overlay 앱을 확인해 보세요.

Android 12를 실행하는 기기가 있고 이를 사용해 보고 싶다면 위에 링크된 GitHub 저장소를 확인하세요. 릴리스 섹션에는 다운로드하여 사용할 수 있는 APK가 있습니다. 라이브러리는 JitPack을 사용하여 자신의 애플리케이션에 쉽게 포함할 수 있어야 합니다.

물론 이 기능이 오랫동안 유지될 것이라고 기대해서는 안 됩니다. Google은 타사 오버레이를 정말 좋아하지 않으므로 Android 13이 출시되면 이 문제가 거의 확실히 해결될 것입니다. 하지만 그 동안에는 즐기세요!