소스 코드 없이 개발자는 맞춤형 ROM에서 작동하는 카메라와 같은 하드웨어 구성 요소를 어떻게 얻을 수 있습니까? 대답은 BLOB, shim 및 많은 디버깅입니다.
Android Oreo와 같은 다양한 기기가 출시되면서 샤오미 레드미 노트 3, 구글 넥서스 5 그리고 다른 사람들은 비공식적으로 그것을 받고, 개발자가 AOSP(Android 오픈 소스 프로젝트) 기반 ROM을 포팅할 때 동일한 기능(주로 카메라)이 손상되는 경향이 있는 이유가 궁금할 것입니다. 아마도 깨진 기능의 긴 목록이 포함된 ROM의 XDA 포럼 스레드를 본 적이 있을 것입니다. "무엇이 작동하는지" 뒤에 작동하는 기능 목록이 표시되고 그 아래에는 "무엇이 작동하지 않나요?"라는 아이콘이 표시됩니다. 나한테 말해봐!” Reddit 및 Twitter와 같은 곳에서 실질적으로 밈이 된 우리 포럼의 두 가지 인기 있는 후렴구입니다.
개발자가 AOSP ROM을 기기에 이식하려고 할 때마다 많은 기능이 손상되는 이유는 무엇입니까? 기본적인 대답은 기능이 다양한 Android 버전에 따라 변경되기 때문에 BLOB으로 패키징된 기존 장치 드라이버가 최신 버전의 Android 또는 기본 AOSP에서도 작동하지 않는다는 것입니다. 이를 극복하기 위해 개발자는 "심(shim)"이라는 것을 사용하지만 관련 프로세스는 까다롭고 시간 집약적이며 때로는 디버깅하기가 매우 어렵습니다.
이 기사에서는 특히 AOSP 기반 ROM에서 카메라가 제대로 작동하도록 하는 것과 관련하여 shim의 작동 방식을 간략하게 설명합니다. OnePlus 3T를 예로 사용하겠습니다. 이러한 기능을 작동시키는 것과 관련된 어려움은 장치에 따라 매우 다릅니다.
OxygenOS를 실행하는 OnePlus 3T. OnePlus 휴대폰은 맞춤형 개발 친화성으로 유명하지만 AOSP의 안정적인 포트를 만들기 위해 개발자가 뒤에서 수행하는 작업이 많습니다.
shim 또는 BLOB란 무엇입니까?
개발자가 수행하는 작업의 일부를 이해하려면 먼저 몇 가지 사항을 설명해야 합니다. Android OS는 오픈 소스(이유로 인해 Android 오픈 소스 프로젝트라고 함)이지만 수천 대의 Android 기기에 출시되는 소프트웨어(커널 제외)는 그렇지 않습니다. 개발자는 소스 코드에 접근할 수 없습니다.
이제 Google이 아닌 기기에 기본 AOSP를 포팅하는 개발자는 아마도 이러한 Android 스킨의 소스 코드에 신경 쓰지 않을 것입니다. 이러한 ROM을 수정하고 구축합니다. 한 가지 크고 큰 이유 때문은 아니지만 그것은 사실일 것입니다. 주로 카메라가 제대로 작동하는 데 필요한 부품입니다. 그만큼 카메라 HAL (하드웨어 추상화 계층)은 또한 비공개 소스.
카메라 HAL뿐만 아니라 ROM 비공개 소스도 갖는 문제는 AOSP를 자신의 기기에 포팅하는 개발자가 블라인드 작업. 폐쇄 소스 OEM ROM은 OEM이 카메라 HAL 소스에 액세스할 수 있으므로 카메라 HAL과 원활하게 인터페이스할 수 있습니다. 카메라 HAL은 ROM이 카메라 하드웨어와 "대화"할 수 있도록 해줍니다. HAL이 없으면 카메라가 작동하지 않습니다. 카메라 HAL을 자동차의 핸들과 페달로 생각하세요. 스티어링 휠/페달을 사용하면 운전자(ROM)가 내부 구성 요소를 사용할 수 있도록 외부 인터페이스를 제공하여 차량의 내부 구성 요소를 제어할 수 있습니다.
카메라 하드웨어가 점점 더 복잡해짐에 따라( 듀얼 카메라의 등장예를 들어) 카메라 HAL 소스에 액세스하면 기능적인 카메라가 포함된 AOSP ROM을 포팅하는 작업이 훨씬 쉬워집니다.
그러나 OEM은 다양한 이유로 카메라 HAL 소스에 대한 액세스를 제공하지 않습니다. 첫째, 카메라 HAL에 대한 모든 소유권을 보유하지 않은 경우(예: 다른 회사의 지적 재산을 통합한 경우) 소스를 배포할 수 없습니다. 둘째, 카메라 HAL 소스를 공개하면 자체 지적 재산이 위태로워질 수 있습니다. 마지막으로, 회사는 이 소스 코드를 제공할 법적 의무가 없습니다(커널 소스 코드와는 달리). GPL에 따라 공개할 의무가 있음) 따라서 출시할 동기가 없습니다. 그렇다면 카메라 HAL 소스에 액세스하지 않고 개발자는 정확히 어떻게 AOSP ROM에서 카메라가 작동하도록 할 수 있을까요? 대답은 BLOB, shim 및 수많은 디버깅입니다.
장치 얼룩 (Binary Large OBject)에는 소프트웨어의 컴파일된 형태인 사전 패키지된 바이너리가 포함되어 있습니다. 이 경우 카메라 HAL 소스는 OEM에서 컴파일되어 기기에 바이너리로 제공됩니다. 개발자가 BLOB에 대해 이야기할 때 추출할 수 있는 라이브 장치에 제공되는 바이너리를 참조합니다. 이제 "카메라 BLOB"이라는 주제가 생겼습니다. 오랫동안 괴로움을 겪은 OnePlus 그러나 문제의 진실은 개발자가 항상 카메라 BLOB에 액세스할 수 있다는 것입니다. 그만큼 카메라 HAL 소스 코드는 황금 티켓입니다 하지만 여기 개발자에게는 그럴 것입니다. 절대로, 절대로 석방되지 마세요 법적 위험으로 인해 OnePlus와 같은 회사가 들어갈 것입니다.
따라서 AOSP를 기기에 적용하려는 개발자에게는 소스 코드에 액세스할 수 없는 카메라 HAL의 BLOB만 남게 됩니다. 개발자가 AOSP ROM 코드를 카메라 HAL BLOB와 페어링하여 작동할 것이라고 기대할 수 있는 경우는 거의 없습니다. 따라서 둘 사이의 격차를 해소하기 위해 개발자는 '틈 메우는 나무.”
"shim"은 "(무언가를) 쐐기 모양으로 만들거나 공간을 채우는 것"을 의미합니다. 이는 개발자가 다음과 같은 경우에 효과적으로 수행하는 작업입니다. shim 작성 - BLOB가 작업 중인 AOSP 소스 코드와 인터페이스할 수 있도록 코드를 추가합니다. 와 함께. Shim은 다양한 종류의 BLOB가 AOSP에서 작동하도록 만드는 데 사용되지만 일반적으로 가장 시밍이 필요한 것은 카메라 BLOB입니다. 앞서 언급한 것처럼 시밍은 최신 버전의 Android를 기기에 포팅할 때뿐만 아니라(예: 모든 비공식 Android Oreo ROM)이지만 동일한 Android 버전의 AOSP를 해당 ROM으로 포팅할 때도 필요합니다. 장치.
추천 도서: 매장에서 선반까지: MSM8974 장치가 Nougat에서 제외되는 이유에 대한 심층 요약
예를 들어 OnePlus 2는 마지막 공식 주요 OS 업데이트 안드로이드 6.0 마시멜로 형태로. 그러나 이 장치는 실제로 완벽하게 작동하는 맞춤형 AOSP 기반 ROM Android Nougat를 기반으로 하며 이는 개발자와 심의 노고 덕분입니다. 우리는 shim의 몇 가지 예를 분석할 것이지만 먼저 shim이 정확히 어떻게 작동하는지에 대해 이야기해야 합니다.
시밍은 어떻게 작동하나요?
개발자는 카메라 HAL 또는 OEM ROM 소스(및 사전 컴파일된 바이너리에만)에 액세스할 수 없으므로 카메라 HAL이 기대하는 기능이 무엇인지 알 수 없습니다. 이로 인해 카메라 HAL이 찾고 있는 함수 이름과 개발자가 작업 중인 AOSP 코드에 있는 함수의 실제 이름이 일치하지 않는 경우가 종종 있습니다.
이 문제를 해결하기 위해 개발자는 동일한 이름을 사용하는 새 함수를 생성하면 됩니다. 카메라 HAL BLOB가 기대하는 기능이지만 이 새로운 기능은 단지 개발자가 원하는 것을 실행합니다. 그것을. BLOB와 AOSP 사이의 중개자 역할을 하는 이 새로운 기능이 심입니다. BLOB가 찾고 있는 기능을 찾지 못하는 이 특정 시나리오는 shim이 필요한 가장 일반적인 시나리오 중 하나입니다.
아마도 OnePlus 3T와 관련된 가상의 예를 통해 상황이 좀 더 이해가 될 것입니다. OxygenOS와 OnePlus 카메라를 사용하여 예제를 만들어 보겠습니다. OnePlus 3T용 OxygenOS Nougat에서 가져온 카메라 BLOB를 사용하여 AOSP 기반 Nougat ROM을 구축하는 경우 문제가 발생할 수 있습니다. 이는 원래 OEM이 컴파일한 카메라 BLOB가 OxygenOS 내에서 필요한 모든 기능을 참조할 수 있기 때문입니다. 컴파일된 AOSP ROM에는 해당 기능이 없거나 다른 이름으로 컴파일했을 수 있습니다(따라서 함수 기호 간의 불일치가 발생함). 오류. 이 문제는 BLOB에서 예상하는 이름인 shim을 사용하여 AOSP ROM 내에 새 함수를 생성하여 해결할 수 있습니다.
프로그래밍 컨텍스트의 기호는 코드의 특정 기능을 참조하는 데 사용됩니다. 코드를 편집하면 함수의 위치가 변경될 수 있으므로 하드코딩을 방지하려면 기호가 필요합니다. 함수에 대한 참조를 사용하면 컴파일러는 다른 함수가 항상 오른쪽을 참조하는 데 사용할 수 있는 기호 테이블을 만듭니다. 기능. 컴파일하기 전에 함수 이름을 변경하면 해당 기호도 변경되므로 기본적으로 모든 변경 사항은 컴파일하기 전에 OEM이 카메라 HAL 소스에 만드는 코드를 사용하려면 개발자가 새 소스를 생성해야 합니다. 틈 메우는 나무.
지금까지 우리가 제공한 설명을 보면 심을 만드는 것이 쉬운 것처럼 들립니다. 여기저기서 몇 가지 함수 이름을 바꾸는 것은 그리 어렵지 않을 것 같죠? 그렇게 쉬웠더라면. shim의 현실은 단순한 기능 이름 변경 이상의 것을 포함합니다. 우리는 그가 작업한 가장 어려운 심 중 하나의 예를 우리에게 제공할 수 있었던 XDA 공인 개발자 Sultanxda와 이야기를 나눴습니다.
시밍 - 말만큼 쉽지는 않다
OnePlus 3T에 익숙하지 않은 분들을 위해 설명하자면, 처음에는 전면 카메라가 다소 깨졌습니다. AOSP 기반 맞춤 ROM. 우선, 8MP 이상의 사진을 찍으려고 하면 충돌. 이 문제를 해결하기 위해 Sultanxda는 몇 가지를 만들었습니다. 심 OnePlus 3T 전면 카메라가 제대로 작동할 수 있도록 합니다.
심 #1 - 카메라 패키지 이름 변경하기
사용자가 8MP 이상의 사진을 찍을 때마다 전면 카메라가 충돌하는 것을 막기 위해 Sultanxda는 카메라 HAL이 모든 카메라를 OnePlus 카메라로 식별하도록 강제했습니다. 이는 OnePlus가 특정 애플리케이션(isOnePlusCamera, isFacebookCamera, 등) 어떤 이유에서인지. Sultanxda는 카메라 HAL을 시밍하여 사용자가 OnePlus 카메라를 사용하지 않는 경우에도 마치 사용자가 OnePlus 카메라를 사용하는 것처럼 항상 "true"를 반환하는 새로운 기능을 가리키도록 하여 이 문제를 해결했습니다.
심 #2 - QuadraCfa 비활성화
다음 심을 위해 그는 카메라와 관련된 Qualcomm 독점 기술인 QuadraCfa를 비활성화해야 했습니다. 아마도 나와 Sultanxda 모두 QuadraCfa가 무엇인지 정확히 알지 못하지만 Sultanxda는 그것이 활성화될 때마다 전면 카메라가 고장났다는 것을 알고 있기 때문일 것입니다.
그는 QuadraCfa가 어떻게든 스스로 활성화되는 것을 관찰했지만 왜 그렇게 하는지, 어떻게 그렇게 하는지 확신하지 못했습니다. 이 문제를 해결하려면 다소 색다른 수정이 필요했습니다. 기존 shim에서 shim 함수는 컴파일 시 BLOB가 찾고 있는 누락된 기호를 제공합니다. 이 경우 BLOB에는 필요한 기호(아마도 QuadraCfa를 시작하는 함수를 나타내는 기호)가 이미 포함되어 있습니다.
따라서 그는 카메라 HAL에서 사용되는 기호를 재정의하고 본질적으로 해당 기호를 '누락'하도록 만들어야 했습니다. 그의 심은 "누락된" 기호를 제공합니다. 그렇게 하는 유일한 방법은 다음을 통해서입니다. 카메라 HAL 자체를 16진수로 편집. 16진수 편집은 기본적으로 건초 더미에서 바늘(편집하려는 함수나 문자열)을 찾기 위해 이진 데이터 형태의 정리되지 않은 횡설수설을 살펴보는 것입니다.
함수를 16진수로 편집하는 것은 문자열을 16진수로 편집하는 것보다 훨씬 더 어렵지만 다행히도 Sultanxda는 대신 QuadraCfa 뒤에 있는 함수를 16진수로 편집해야 하는 것을 피할 수 있었습니다. 해당 기호를 무효화하기 위해 기호 이름을 16진수 편집.
심 #3 - 밝은 빛 충돌 수정
다음으로 Sultanxda는 밝은 조명 조건에서 전면 카메라로 사진을 찍으면 카메라가 충돌할 수 있다는 사실을 확인했습니다. 이 버그를 자신의 장치에서 재현하기 위해 Sultanxda는 실제로 OnePlus One의 손전등 기능을 켜고 OnePlus 3T의 전면 카메라 앞에 빛을 비췄습니다. 충돌을 일으키고 사용 가능한 로그를 생성하려면! 어떤 기능이 충돌을 일으키는지 알아낸 후 그는 장치가 전면 카메라에 대해 항상 저조도 모드를 사용하도록 강제하는 심을 만들었습니다.
심 #4 - 저해상도 전면 카메라 사진
이전 심의 밝은 빛 충돌을 수정한 후 Sultanxda는 실제로 해당 심의 직접적인 결과로 발생한 또 다른 버그, 즉 저해상도 전면 카메라 사진을 발견했습니다. 사용자가 요청한 해상도로 사진을 찍는 것보다(예: 16MP) 결과 사진은 4MP로 촬영됩니다.
이 문제를 해결하려면 기능을 심해야 했습니다. handleSuperResolution 그리고 isSuperResolution 항상 true를 반환하지만 전면 카메라가 활성화된 경우에만 해당됩니다(그렇지 않으면 후면 센서에서 사진을 찍을 때 카메라가 충돌할 수 있기 때문입니다).
교훈 - 시밍은 어려울 수 있습니다.
Sultanxda는 OnePlus 3T 전면 카메라가 작동하도록 하기 위해 만들어야 했던 심이 전형적인 심의 예가 아니라는 점을 인정합니다. 그는 심의 복잡성과 BLOB 자체를 16진수 편집해야 할 필요성이 거의 없다는 점을 감안할 때 자신의 심을 오히려 자랑스럽게 생각합니다. 하지만 이 예는 특정 장치에서 카메라 하드웨어를 작동시키는 것이 얼마나 어려운지 보여줍니다.
당신의 카메라 심 모험이 나보다 덜 고통스럽기를 바랍니다. -술탄스다
로그, 로그 및 기타 로그. 충돌을 재현하는 일관된 방법과 로그가 없으면 개발자는 문제의 원인을 찾을 가능성이 거의 없습니다. 문제의 원인을 찾았다고 해도 항상 간단한 해결 방법은 아닙니다. 이러한 버그를 찾아 없애는 전체 과정은 며칠 또는 몇 주가 걸릴 수 있으며 AOSP ROM에서 카메라를 수정하는 것이 더 어려운 작업 중 하나인 이유입니다.
장치에 완벽하게 작동하는 하드웨어와 함께 AOSP ROM이 포팅되어 있는 경우 다음 작업을 시작할 수 있습니다. 이러한 개발자들이 여러분에게 이러한 기능을 제공하기 위해 겪었을 수 있는 어려움에 감사드립니다. 특징. 쉽지 않기 때문에 그들의 작업에 감사드립니다. 우리 포럼의 재능 있는 개발자들이 Android의 보이지 않는 많은 부분을 관리하고 있기 때문에 대다수의 사용자가 눈치 채지 못할 많은 작업입니다.
이 기사를 작성하는 데 많은 기여를 해준 Sultanxda에게 특별한 감사를 전하고 싶습니다.