이 기사에서는 Snapdragon 801 장치가 Android Nougat를 얻지 못하는 이유에 대한 진실을 탐구합니다. 칩셋 제조사부터 공급업체까지, 문제는 많습니다!
Android 7.0에 대한 Vulkan 또는 OpenGL ES 3.1 요구 사항을 반영하도록 업데이트되었습니다.
최근에는 버전 업데이트, 공급업체와 칩셋 제조업체 간의 상호 작용, 이것이 향후 장치에 미치는 영향에 대해 많은 기사가 작성되었습니다. 이번 주에 왜 이렇게 상승했나요?
음, 이번 주에 Nexus 5가 Android 7.0(Nougat) 업데이트를 받지 못할 것이라는 점을 고려하면 이 사실이 드러났고, Qualcomm은 업데이트를 받지 않을 것이라고 발표했습니다. 7.0에서 MSM8974(더 일반적으로 Snapdragon 801로 알려짐)에 대한 지원을 제공합니다. 이 글은 XDA Recognized와의 협업으로 작성되었습니다. 개발자 호박벌.
이 주제는 다양한 뉴스 사이트에서 상당한 관심을 끌었지만 많은 사람들이 무대 뒤에서 실제로 무슨 일이 일어나고 있는지 미묘한 차이를 놓치고 있습니다.에스. 이 문서에서는 공식 펌웨어 업데이트에 대해 OEM과 협력한 경험을 바탕으로 소프트웨어 업데이트 작동 방식에 대해 좀 더 설명합니다. 우리는 뒤에서 무슨 일이 일어나고 있는지(그리고 그 이유), 그리고 휴대폰에 최신 소프트웨어가 설치되지 않는 이유를 단계별로 안내해 드립니다.
Android 펌웨어 업데이트의 첫 번째 단계는 업스트림 업데이트입니다. 이것이 Google이 내부적으로 수행하는 작업입니다. "개방형 워크플로"와 달리 Android는 폐쇄형 워크플로를 사용하여 개발되며 매년 새 릴리스가 출시되면 소스 코드가 벽에 던져집니다. 원래 Google은 최첨단 버전을 실행하는 사람들의 단편화를 방지하기 위한 것이라고 밝혔습니다. 초기에는 상황이 급격하게 발전했지만 이 정책을 계속 유지한 것 같습니다. 장소.
특정 시점, 일반적으로 업데이트를 공개적으로 발표하기 전(최근 공개 베타가 도입되면서 이러한 기간이 바뀌고 있습니다)
업스트림 AOSP 저장소에는 제한된 수의 기기에 대한 기기 지원만 포함됩니다. 이는 일반적으로 Nexus 기기입니다. 그러나 곧 밝혀지는 이유 때문에 Google은 이러한 기기에 대한 하드웨어를 완벽하게 제어할 수 없다는 점을 기억하는 것이 중요합니다. 장치는 OEM에 의해 제조되며 해당 OEM은 칩셋 제조업체로부터 SoC(시스템 온 칩)를 구매합니다.
소스 코드가 공개되면 OEM의 펌웨어 팀은 (비유적으로) 가만히 앉아서 일어설 것입니다. 기본 Android 소스 트리에는 배송 장치에 사용되는 수많은 칩셋에 대한 하드웨어 지원이 없습니다. 예를 들어 Qualcomm 칩셋은 AOSP 내에서 지원되지 않을 가능성이 높습니다. 귀하의 Exynos 제품은 확실히 그렇지 않습니다. Mediatek 또는 HiSilicon? 잊어 버려!
BSP에는 Android를 실행하는 데 필요한 드라이버와 하드웨어 추상화 계층(HAL)이 포함되어 있습니다.
지금 필요한 것은 보드 지원 패키지(BSP). 이는 칩셋 제조업체가 OEM에게 제공하는 독점 구성 요소로 구성된 극비 패키지입니다. BSP에는 OEM이 Android 및 장치에 필요한 드라이버를 구축하는 데 필요한 소스 코드가 포함되어 있습니다.
여기서 Qualcomm과 같은 OEM이 반드시 OEM 파트너를 완전히 신뢰하는 것은 아니라는 점에 주목할 가치가 있습니다. BSP는 "알아야 할 사항"에 따라 제공됩니다. OEM은 일반적으로 장치의 일부 극비 부분(예: 베이스밴드에서 실행되는 소프트웨어)에 대한 소스 코드에 액세스할 수 없습니다. 이 부분을 닫으면 가까운 부분에서 알 수 있듯이 확실히 잠재적인 문제가 있습니다. 풍부한 그리고 반복되는 ASN.1 취약점 분석.
BSP에는 기기에서 Android를 실행하는 데 필요한 드라이버와 하드웨어 추상화 계층(HAL)이 포함되어 있습니다. AOSP에는 운영 체제에서 드라이버가 구현하기를 기대하는 항목에 대한 정의 역할을 하는 일련의 HAL이 포함되어 있습니다. 터무니없이 지나치게 단순화된(그리고 시연을 위해 구성한) 예를 사용하기 위해 휴대폰의 손전등을 상상해 봅시다.
HAL 예 - 손전등
기기 뒷면에 손전등이 있다고 가정해 보겠습니다(Nexus 7 2013을 사용하는 경우 다른 사람보다 좀 더 상상력을 발휘해야 합니다. 죄송합니다!). 이는 운전자가 제어합니다. 엄청나게 간단한 예를 들어, v1 HAL이 단일 매개변수, 즉 조명 상태를 취하는 'setLED'라는 함수가 있어야 한다고 가정해 보겠습니다. 이는 부울(참 또는 거짓)입니다. C에서는 다음과 같이 보일 것입니다:
void setLED(bool ledState) {
// here is the actual code to turn on or off the LED, based on ledState
}
이 함수는 BSP 소스 코드 내에 정의되어 있습니다. BSP는 ROM을 빌드하는 동안 OEM에 의해 컴파일되며 이는 장치의 공급업체 파티션이나 영역에 있는 독점 ".so" 라이브러리 중 하나가 됩니다. 이를 통해 OEM은 장치 작동 중 특정 부분을 비밀로 유지할 수 있습니다. 지금은 LED를 켜고 끄는 방법을 모든 사람이 보지 못하도록 하고 싶다고 가정해 보겠습니다.
이제 Google이 향후 Android 버전에서 HAL의 업데이트된 버전을 출시한다고 상상해 보세요. 이제 그들은 단순히 LED를 켜거나 끄는 것보다 LED의 밝기를 업데이트할 수 있도록 허용하는 것이 좋을 것이라고 결정했습니다. 어쩌면 이것은 적응형 플래시를 위한 것일 수도 있고, 아니면 단지 HAL 업데이트를 강제하고 칩셋 제조업체를 계속 운영하기 위한 것일 수도 있습니다. 독자 여러분이 이에 대해 자신의 의견을 가지도록 하겠습니다. 일부 HAL 업데이트에는 명확한 이점(예: 원시 촬영 등을 노출하는 새로운 카메라 HAL)이 있는 반면, 일부 HAL 업데이트는 목적이 다소 덜 명확합니다.
밝기를 위한 이 새로운(가상) HAL을 사용하여 Google에서 setLED라는 함수를 다시 노출해야 하지만 이번에는 밝기를 위해 정수가 전달되어야 한다고 가정해 보겠습니다. 이제 0은 끄고 255는 최대로 설정합니다.
OEM인 경우 극비 코드를 사용하여 해당 LED를 켜고 이 새로운 기능에 넣을 수 있습니다. 펄스 폭 변조를 사용하여 숫자에 따라 LED의 밝기를 조정할 수도 있습니다. 이제 다음과 같이 표시되도록 함수를 변경합니다.
void setLED(uint8_t ledBrightness) {
// some super-secret and ultra-confidential proprietary way to set LED brightness
}
그래서 뭐? 이제 이 새 버전의 Android는 기존 "blob"과 호환되지 않습니다. OEM은 이러한 새로운 blob을 사용해야 합니다. 왜냐하면 Android OS는 새로운 기능 정의를 기대하고 LED를 설정하는 방법을 찾을 때 이전 기능 정의를 "발견"하지 않기 때문입니다.
이 시점에서는 사용자 정의 ROM(소스에서 구축)이 여기에서 어떻게 관리되는지 살펴보기 위해 잠시 휴식을 취하겠습니다. 바로 지금 여러분 중 기민한 사람들이 여러분의 화면에서 이렇게 외칠 것입니다. 결국 우리는 XDA, XDA입니다. HTC HD2, 세상에서 가장 오래가는 휴대폰… (참고로 저쪽 미친 천재들은 달려가고 있어요) 요즘 HD2의 Android 6.0! 원래 2009년에 Windows Mobile 6.5가 탑재된 휴대폰치고는 나쁘지 않습니다)
여기에는 다양한 접근 방식이 있습니다. 때때로 개발자는 ROM 내에서 해킹하여 OS에 이전 기능 정의를 사용하도록 지시합니다. 약간 지저분하고 유지 관리를 위해 많은 변경이 필요합니다. 다른 접근 방식은 OEM 바이너리를 "심"하는 것입니다.
"shim" 접근 방식은 예상되는 함수 정의가 포함된 작은 새 라이브러리를 직접 작성하고 구축하는 것입니다. 이 예에서는 밝기에 대해 정수를 지원합니다. 그런 다음 심 내에서 이는 이전 HAL의 요구 사항을 충족하도록 변환됩니다. 따라서 우리의 예에서는 128보다 높은 밝기를 요청하면 LED가 켜지고 그보다 낮은 밝기는 꺼질 것이라고 말할 수 있습니다. 또는 0이 아닌 어떤 것이든 켜질 것이라고 말할 수 있습니다. 그것은 개발자에게 달려 있습니다. 그들은 심을 컴파일하고 Android가 기본 심 대신 이를 사용하도록 합니다. 그런 다음 shim은 OEM blob을 호출합니다.
빠른 'adb 푸시' 및 재부팅을 통해 심이 작동하고 이전 HAL만 있어도 가상의 LED를 제어할 수 있습니다.
문제는 이것이 분명히 불완전한 프로세스라는 것입니다. 이제 이상한 점을 알게 될 것입니다. 이 장치에는 완전히 켜져 있거나 완전히 꺼져 있는 다소 형편없는 플래시가 있습니다. 그것은 이상적이지 않습니다. OS는 매우 부드러운 빛을 내고 있다고 생각하지만 실제 LED는 인공 태양 콘테스트에서 경쟁하고 있다고 말하고 있으며 사용자의 눈을 멀게 하려고 합니다. 하지만 인생은 완벽하지 않습니다. 이제 기존 전화기에 LED가 작동하고 있습니다!
(예, 이것이 XDA 사용자와 개발자가 엄청난 포팅 능력을 관리할 때 별난 점과 버그가 발생하는 이유 중 하나입니다. 내 말은, 도대체, 갤럭시 S II 겉으로는 쓸만해 보이는 물건을 들고 다니고 있다 이제 안드로이드 6.0 ROM. 작년에 출시된 많은 휴대폰에는 아직 6.0이 없습니다!)
OEM의 관점으로 돌아가 보겠습니다. 안타깝게도 대부분의 OEM은 이미 우리가 현재 있는 위치보다 먼저 최소 1대의 휴대폰을 작업하고 있습니다. 그들의 초점은 곧 판매할 다음 휴대폰에 있습니다. 그들은 판매하는 기기로만 돈을 벌기 때문에 실제로 그들을 비난할 수는 없습니다. 1~2년 전에 판매한 기기로는 돈을 벌지 못하기 때문에 계속해서 새로운 기기를 출시해야 존재하게 됩니다. 이것이 HTC와 Blackberry가 곤경에 처한 이유 중 하나입니다. 얼마나 많은 경영진이 기존 Blackberry Curve에 대한 죽음의 손아귀를 유지하고 있는지는 중요하지 않습니다. 그곳에서 새로운 장치를 판매하지 않기 때문입니다.
OEM이 BSP를 얻지 못하면 빌드를 함께 해킹하는 XDA 접근 방식을 따르지 않을 것입니다. 왜? 잘, 고객을 위해 이 펌웨어를 지원해야 합니다.. 제대로 작동하지 않는 펌웨어를 출시하면 사용자는 이를 싫어하고 호언장담하며 지원 라인을 며칠 동안 울릴 것입니다.
OEM도 통신사와 경쟁해야, 적어도 비유럽 시장에서는요. 이동통신사는 고객이 소프트웨어 업데이트에 문제를 겪는 것을 원하지 않습니다. 실제로 통신업체에서는 소프트웨어 업데이트를 출시하지 않는 경우가 많습니다.
이것을 이해하려면 여러분의 고모 앨리스를 상상해 보십시오. 그녀는 하루 중 불편한 시간에 당신에게 전화를 걸어 "그 컴퓨터 문제"에 대한 도움을 요청하는 사람입니다. 그런 다음 "시작 메뉴"를 클릭하는 방법을 설명하고 이를 "왼쪽 하단 모서리에 있는 큰 플래그"로 식별해야 하며 혼란에 빠지게 됩니다. 약 45분(그리고 많은 좌절감) 후에 Alice 이모가 시작 메뉴를 화면 오른쪽 가장자리로 끌어서 다시 끌어오기만 하면 된다는 사실이 드러납니다. 네, 마우스 왼쪽 버튼으로요!
이제 앨리스 이모가 천 명 있다고 상상해 보세요. 그들은 모두 해커가 자신의 휴대폰에서 Candy Crush를 삭제한 것을 걱정하여 휴대폰에서 Candy Crush를 찾을 수 없어 고객 지원에 전화하고 있습니다. 아, 그리고 이제 아이콘이 조금 달라 보입니다. 어쩌면 해커가 아직 휴대폰에 있는 것일까요?
예, 이것은 약간의 가벼운 유머를 의미합니다. 그러나 사람들이 통신사에 지원을 요청하는 이유를 경험하기 전까지는 그들이 겪고 있는 문제를 믿지 못할 것입니다. 전화기 작동 방식이나 사물의 위치를 변경하는 소프트웨어 업데이트로 인해 상당한 지원 오버헤드가 발생합니다. 최소한 지원 직원의 재교육이 필요합니다(슬프게도 대부분의 직원은 열렬한 XDA 독자가 아니기 때문입니다).
OEM이 BSP를 받으면 ROM을 포팅하고 모든 변경 사항을 ROM에 적용합니다. 그들은 블로트웨어를 잔뜩 쌓고 십대 애니메이션에 더 잘 어울리는 끔찍한 만화 같은 스킨을 추가할 것입니다. 그런 다음 테스트할 것입니다.
많이.
휴대전화가 준수해야 하는 모든 요구 사항이 있습니다. 모바일 네트워크는 사용자 장비(우리가 전화라고 부르는 것)가 올바르게 작동할 것을 신뢰하도록 설계되었습니다. 이는 장치를 승인받기 위해 많은 테스트가 필요하다는 것을 의미합니다. 소프트웨어 업데이트로 인해 행동이 바뀔 위험이 있으므로 다시 테스트해야 합니다. 이것이 바로 펌웨어가 테스트 요구 사항을 준수하는지 확인하는 향후 Sony 소프트웨어 업데이트에 대한 정보를 외부 테스트 서비스에서 흔히 볼 수 있는 이유입니다.
지금... 업데이트 한두 번(또는 어떤 경우에는 없음) 후에는 어떻게 되나요? SoC 제조업체는 OEM에게 업데이트된 BSP를 제공하지 않습니다.. 결국, SoC 제조업체는 이것으로부터 많은 것을 얻지 못할 것입니다. OEM은 휴대폰이 판매된 이후로 휴대폰으로 더 이상 돈을 벌지 않습니다. 그리고 이 시점에서 귀하의 휴대폰은 더 이상 주요 버전 업데이트를 받을 수 없습니다.
OEM이 제공하기를 원하는 BSP 수를 줄이는 것은 비용을 절약하는 좋은 방법입니다. 현재 버전만 필요하고 주요 버전을 제공할 계획이 없는 경우 증가하면 초기 SoC 구매 및 라이센스 비용이 절약되지만 XDA에서 왜 SoC를 얻지 못했는지 궁금해하는 화난 괴상한 사람들이 희생됩니다. 업데이트.
업데이트가 복잡합니다. 체인에는 다양한 사람들이 참여하고 있습니다. 이 중 어느 것도 현재 Android 업데이트의 부족하고 한심한 상태에서 OEM을 변명할 수 없습니다. 그럼에도 불구하고 여기에는 몇 가지 실질적인 과제가 있습니다.
많은 OEM이 과도한 약속을 하고 있다는 비난을 받고 있습니다. 우리가 지금 연관하고 있는 불가피한 미달 전달. 슬픈 현실은 대부분의 OEM에게 소프트웨어 업데이트가 없이는 성가신 일에 불과하다는 것입니다.
모바일 부문은 대부분 피처폰 사고방식에 갇혀 있다. 즉, 장치가 업데이트를 전혀 받지 못하는 경우입니다. 한 번 테스트하고 배송한 후 뒤돌아보지 마세요. 최신 스마트폰의 보안 문제와 수백 개의 외부 라이브러리가 포함된 완전한 범용 운영 체제를 실행하는 데 따르는 복잡성으로 인해 이는 더 이상 선택 사항이 아닙니다. 아니면 적어도 그것 해서는 안 된다 BE. Google은 최소한 기존 릴리스에 대한 보안 게시판과 패치를 게시하여 이 문제를 해결하기 위한 몇 가지 조치를 취했습니다. Android(아주 최근까지 보안 업데이트를 받을 수 있는 유일한 방법은 새로운 주요 Android OS 버전을 통해서였다는 점을 기억하세요!)
그러나 아쉽게도 이것만으로는 충분하지 않습니다. Google이 계속 업데이트를 출시하더라도 기기의 보안은 여전히 SoC 제조업체에 달려 있습니다. LED 몇 개를 켜거나 스피커를 통해 소리를 내는 방법을 발견한 누군가는 엄청난 양의 바이너리 덩어리를 자신의 컴퓨터에 전송합니다. 장치. 이러한 얼룩에는 매우 끔찍할 정도로 안전하지 않은 코드가 포함되어 있으며(과장이라고 생각하시면 과거 Google 보안 게시판을 살펴보세요!) 업데이트가 필요합니다. 이는 업데이트된 BSP가 필요함을 의미합니다.
데스크톱 컴퓨터(더 나아가 노트북)는 모바일 장치와 아키텍처가 완전히 다릅니다. 귀하의 휴대폰이나 태블릿은 사실상 독점적인 실리콘 덩어리이며, 선의는 있지만 좋은 것을 만들 시간이 부족한 일부 사람들에 의해 급하게 설계되었습니다. 시장은 너무 빠르게 움직이기 때문에 마케팅에서 신제품 출시를 요구하는 속도를 간신히 따라갈 수 있습니다.
이는 바로 가기가 사용됨을 의미합니다. 메인라인 Linux 커널에서 지원되는 휴대폰을 찾을 수 없으며 모든 휴대폰에는 부팅 방법이 다릅니다. 그러나 노트북이나 데스크탑의 경우 공급업체는 몇 가지 표준 부팅 방법을 선택했습니다. 이전에는 BIOS가 포함된 MBR(마스터 부트 레코드)이었으며 이제는 UEFI입니다. 이러한 표준화를 통해 각 장치에서 동일한 소프트웨어를 실행할 수 있습니다.
최근 이를 향한 몇 가지 조치가 취해졌지만 특히 Sony의 지원 프로그램과 그들의 통합 커널, 각 장치에 도입된 새로운 공급업체별 해킹이 너무 많기 때문에 대부분의 전화기에서 메인라인 커널을 실행하는 것은 실용적이지 않습니다.
헤드폰 잭을 잘못된 방향으로 연결했나요? 그냥 드라이버에서 해킹하세요! 제작설계에서 고칠 시간이 없습니다.
제조팀이 생산 배치 1에서 카메라 모듈을 거꾸로 장착했다고요? 해킹을 해서 내부 버전 코드를 확인하고, 버전 1이면 영상을 뒤집어 보세요!
이와 같은 해킹은 즉각적인 문제를 해결하지만 진행 중인 이상하고 제품별 변경 사항의 겉모습만을 긁어냅니다. 도대체 때로는 상업적 결정으로 인해 동일한 전화기의 여러 개정판에 완전히 다른 칩이 있는 경우도 있습니다. 이로 인해 드라이버 해킹이 발생하고 그 당시에만 의미가 있었던 이상한 결정으로 이어져 다음 주에 배송될 수 있도록 전화기를 작동시키게 됩니다.
UEFI를 사용하여 부팅하기 위한 64비트 ARM 칩에 대한 메인라인 지원 작업이 진행 중이지만 지금까지는 ARM 장치를 부팅하는 보다 표준화된 방법을 향한 명확한 움직임이 없습니다.. 그리고 그것은 슬픈 일입니다. 왜냐하면 그것은 수명이 다하기 훨씬 전에 휴대폰이 계속 버려질 것이라는 것을 의미하기 때문입니다. 기술적 부채와 부담을 유지하기에는 비용이 너무 많이 들기 때문입니다. 소프트웨어.
반면에 OEM이 기기 판매로만 수익을 창출한다면 사람들이 계속 새 휴대전화를 구매하도록 보장할 필요가 있지 않나요? 개방형 PC 플랫폼과 표준을 사용하는 30년 간의 추진력과 레거시 소프트웨어가 이미 존재하지 않았다면 PC 시장이 이 모델로 이동할까요?
이는 Qualcomm의 내부 지식이 없으면 어려운 질문입니다. 안타깝게도 현재로서는 내부 지식이 없습니다. 그러나 7.0 Android 드라이버 API 및 CTS 요구 사항에서 일부 정보를 얻을 수 있습니다. CTS 요구사항은 특정 펌웨어를 실행하는 기기에 대해 Google이 기대하는 사항을 지정합니다. 이러한 요구 사항을 시행하는 데 사용되는 "큰 망치"는 독점 Google Play 서비스 번들을 사용하기 위한 Google의 라이선스입니다. 이를 준수하지 않으면 기기에 Google Apps를 출시할 수 없습니다.. 반면, 일부에게는 이것이 장점으로 볼 수도 있겠네요, 이는 분명히 사용자가 장치에서 원하고 기대하는 것이 아닙니다.
Android 7.0은 위에서 설명한 대로 HAL 또는 드라이버 변경을 통해 많은 것을 추가하지 않았으므로 특별히 거기에서 비호환성이 발생할 가능성은 거의 없습니다. 그러나 문제가 될 가능성이 더 높은 것은 Vulkan 그래픽 API 또는 GLES 3.1에 대한 새로운 요구 사항 CTS를 통과하기 위해 사용할 수 있습니다.
현재 MSM8974를 포함하여 많은 SoC(Systems-on-Chip)가 그래픽 프로세서에서 Vulkan을 지원하지 않습니다. 이는 Android 7.0과의 호환성 문제가 발생할 가능성이 가장 높은 곳이기도 합니다. 하지만 Qualcomm의 내부 지식과 향후 계획이 없으면 자격을 갖추지 않고 확실한 진술을 제공하기가 어렵습니다. 그러나 현재로서는 이것이 Qualcomm이 지원을 중단하는 "간단한" 사례일 가능성이 높다고 생각합니다. (그들의 눈에는) MSM8974 칩셋이 노후화되어 있고 해당 플랫폼에서 7.0용 BSP(보드 지원 패키지)를 제공하지 않는 것으로 보입니다. 그렇다면 OEM이 장치에 7.0을 출시하지 않을 것이 거의 확실하다는 의미입니다. GPU 및 GPU 소스에 대한 Vulkan 또는 GLE 3.1 지원을 찾아야 합니다. 코드는 모바일 스택에서 터무니없이 엄격하게 보호되는 부분 중 하나입니다(실제 이유 없이 추가하겠습니다. 리눅스). 그러나 안타깝게도 Vulkan 및 가속(GLES) 그래픽은 일반적으로 단순한 LED보다 약간 더 복잡하므로 호환성을 도입하기 위해 shim을 볼 수는 없습니다.
7.0이 나온 지 오래되지 않았기 때문에 다른 칩셋(AOSP 자체 내의 소수를 제외하고)이 사라질 가능성이 있습니다. 6.0에서는 하드웨어 및 드라이버 문제(예: 업데이트된 BSP 없음) 또는 Vulkan 또는 GLES 3.1과 관련된 SoC 공급업체 지원 부족으로 인해 뒤쳐졌습니다. API. 현재 Snapdragon 800이나 801은 둘 중 하나를 지원하지 않습니다.
가장 좋은 건 이 공간을 지켜보는 것 - XDA 개발자는 이미 Google로부터 공식 7.0 지원을 받지 못하는 많은 장치에 대해 비공식 7.0 포트를 통해 좋은 진전을 이루고 있습니다. 그러나 Vulkan이나 GLES 3.1은 지원하지 않습니다. 아마도 Android 게임 개발자는 충분한 수의 사용자가 Vulkan 또는 GLES 3.1 없이 맞춤형 ROM을 실행하기 시작하면 조각화로 인한 좌절감을 경험하게 됩니다. 지원하다?
Apple은 약 5년 동안 최신 iOS 버전에서 iPhone 제품군을 지원하는 경향이 있습니다. iPhone 4s는 2011년 10월에 출시되었으며 iOS 9까지 최신 상태로 유지되었습니다. 그러나 곧 출시될 iOS 10 업데이트는 받을 수 없으며, iOS 10이 10월경에 출시된다고 가정하면 휴대폰의 유효 수명은 5년이 됩니다. Apple이 항상 백포트 그래픽 API 지원을 지원하는 것은 아니라는 점은 주목할 가치가 있습니다. iPhone 4s와 iPhone 5는 지원하지 않습니다. Apple의 Metal 그래픽 API를 특징으로 하며 이는 Android에서 볼 수 있는 것과 다소 유사합니다. 불칸. 유일한 차이점은 Apple이 새로운 그래픽 API 없이 이전 장치를 계속 지원한다는 것입니다.
어떻게 생각하나요? 수명을 연장하기 위해 휴대폰에서 맞춤형 ROM을 플래시하시겠습니까? 아래 댓글에서 말씀하셨나요?