질문의 역사는 여기에서 찾을 수 있습니다:
1)스마트폰(ARM 또는 x86)에 lxc용 우분투 서버를 설치하는 방법은 무엇입니까?
2)LXC/LXD 컨테이너(Ubuntu 실행용)에 대한 Ubuntu Touch(UBports) 및 Android 지원: 현재 상태
하위 질문:
1) 어떤 SDK 구성 요소를 사용해야 합니까?
2) 로딩을 위해 부팅 가능한 이미지를 준비/변환하는 방법은 무엇입니까?
3) 다른 커널을 부팅하기 위해 원래의 부트로더를 교체하는 방법(새 경로를 가리키는 방법)은 무엇입니까?
4) 어떤 다른 단계를 수행해야 합니까?
나는 이 질문에 스스로 대답하려고 노력할 것이지만 일반적으로 이미 이 길을 따랐던 사람들의 조언이나 정보를 선호합니다. 이전 시도에 대한 링크를 찾았지만 다소 오래되었습니다. Linux 서버 설치 프로세스는 매우 잘 문서화되어 있습니다(Debian 및 Ubuntu 문서에 의존하고 있습니다). Asus와 같은 스마트폰 공급업체에는 사이트에서 부트로더 잠금을 해제하는 도구가 있지만 작업을 완료하는 데는 충분하지 않습니다. 이 도구는 부트로더의 잠금을 해제할 뿐 부팅 메뉴를 변경하지 않습니다. 즉, 외부 SDK 도구를 사용해야 합니다(메뉴에는 SD 카드나 네트워크에서 부팅할 수 있는 옵션이 없습니다). 즉, 부트로더 자체는 SDK에 의해 변경되어야 합니다. 어떤 링크나 정보라도 감사하겠습니다.
답변1
솔루션을 연구하는 데 약간의 진전이 있었습니다.
1) 실험에 사용할 기기에서 모든 사용자 데이터를 삭제했습니다. (복구 모드로 부팅 > 캐시 삭제 / 데이터 삭제 / 공장 초기화)
2) 비공식 소스를 통해 살펴봤습니다.
인터넷에는 수많은 기사와 포럼 게시물이 있습니다. 그 중 일부는 유용합니다. 대부분은 다소 오래되었으며 오래 전에 마지막으로 업데이트되었습니다. 나쁜 점은 대부분 장치 루팅에 대한 정보(예: 권한을 높이기 위해 알려진 취약점을 악용하는 루트킷을 의도적으로 설치하여 OS 보안을 깨는 것)와 그러한 루트킷을 포함하는 신뢰할 수 없거나 평판이 낮은 스크립트에 대한 링크를 포함하고 있다는 것입니다. 이러한 잠재적으로 유해한 정보는 사용 가능한 옵션에 대한 일반적인 개요를 제공하는 유용한 부분과 혼합되어 있습니다.
xda-developers.com 사이트에 많은 기사가 게시되어 있습니다.법정섹션과위키.
유용한 위키 기사:
해당 위키 기사는 일반적으로 관리 상태가 좋지 않습니다(마지막 편집은 2015년에 이루어졌습니다).
3) 플랫폼 선택(x86, ASUS Zenfone2)
제 경우에는 중고 Android 기기 중에서 선택했습니다. 대부분 ARM 기반 CPU를 사용하고 있습니다. 최신이자 가장 강력한 것은 x86 Intel CPU(64비트 명령어 세트)를 탑재한 ASUS였습니다. x86을 선택한 또 다른 이유는 더 나은 Linux 지원과 x86/AMD64 기반 lxc 컨테이너를 실행해야 한다는 요구 사항이었습니다. ARM을 선택하려면 별도의 컨테이너 분기를 개발하거나 일종의 에뮬레이션/변환 도구를 활용해야 합니다(이러한 도구가 효율적이거나 잘 유지 관리되거나 지원되는지 확실하지 않음).
4) 공식(공급업체 지원) 도구로는 목표에 도달하지 못할 수도 있음을 깨달았습니다.
부트로더 잠금 해제 도구 사용과 관련하여 ASUS 기술 지원팀에 메일을 보냈습니다. 그러나 대답은 간단했습니다. "이 도구는 부트로더의 잠금을 해제할 뿐이며 추가 단계를 도와줄 수 없으며 도구를 사용하면 어떤 일이 발생하는지 알려줄 수도 없습니다." 즉, 도구가 쓸모가 없습니다(내 경우에는 어떻게든 작동했는지, 와 어떻게 다른지조차 모르겠습니다 fastboot oem unlock). 이 도구를 활성화하려면 최신 버전의 ROM에서 지원되지 않는 Android 5.0으로 먼저 다운그레이드해야 했습니다. 부트로더 변경 및 다른 이미지 부팅과 관련된 모든 사항은 비공식적, 지원되지 않음, 권장되지 않음, 보증 위반 등입니다.
5) [선택사항: 참고1] 복구 선택 및 설치(전화 또는 OS 공급업체에서 공식적으로 지원하지 않음)
'회복'- 부트로더/BIOS에 대한 안드로이드 전문 용어입니다(먼저 부팅하고 '백업', '캐시 삭제', '공장 초기화', '공장 초기화'와 같은 사용 가능한 도구가 포함된 부트로더 메뉴를 제공하는 경량 Linux 기반 시스템을 유지하는 장치 메모리의 별도 파티션). 사용자 정의 ROM을 로드하세요' 등). 원래 OEM 복구에서는 사용자 정의 ROM을 플래시하거나 사용자 정의 OS를 부팅할 수 없습니다.
이 프로젝트는 성숙하고 체계적으로 잘 구성되어 있으며 적극적으로 유지 관리되고 있으며 일반적으로 가치 있는 글로벌 오픈 소스 프로젝트라는 인상을 줍니다. 지원되는 장치 및 공급업체의 수가 매우 많습니다.놀랄 만한. 물론 저는 휴대폰 공급업체가 유지 관리하고 승인하며 공식 사이트(제 경우에는 ASUS)에서 다운로드한 복구 버전을 사용하는 것을 선호합니다.
참고 1:TWRP를 설치하고 SDK 도구에 대한 자세한 정보를 얻은 후 사용자 지정 복구를 설치하지 않고도 사용자 지정 ROM을 플래시하는 것이 가능하다는 것을 깨달았습니다(SDK 플랫폼 도구 패키지의 adb 및 fastboot 도구를 활용).
노트 2:각 모델별로 설치 과정이 잘 문서화되어 있습니다. 저는 'Fastboot 설치 방법'을 사용했습니다. 방법에 대한 간략한 설명(기기와 관련된 TWRP 사이트의 페이지를 참조하세요): 1) Android SDK 도구를 설치합니다(플랫폼 도구 패키지의 adb 및 fastboot 구성 요소만 필요합니다). 2) '개발자 모드'를 활성화합니다. 설정 > 정보 메뉴에서 '빌드 번호' 줄을 7번 탭하여 기기를 사용하세요. 3) 설정 > 개발자 옵션에서 'USB 디버깅'을 활성화하고, 4) USB를 통해 PC와 연결하고, 5) PC에서 다음을 확인할 수 있습니다. adb devices6) fastboot 모드 진입을 위해 실행 , adb reboot bootloader7) TWRP 사이트에서 다운로드하고 이름을 'twrp.img'로 변경한 올바른 이미지 파일을 adb 및 fastboot 바이너리가 포함된 폴더(일반적으로 'platform-tools' 폴더)에 넣습니다. ), 8) 실행합니다 fastboot flash recovery twrp.img.제 경우에는 adb에서 오류를 보고했지만 이미지가 성공적으로 플래시되었습니다.FAILED (remote: Permission denied), 9) 실행합니다 fastboot reboot. TWRP 메뉴에서도 장치를 재부팅할 수 있습니다. 중요한 것은 TWRP가 재고 ROM(안드로이드 OS가 있는 파티션)을 패치하여 TWRP를 지우고 부팅 후 재고 복구로 교체하는 것을 방지하는 것입니다. 그렇지 않으면 프로세스를 반복해야 합니다. 네, 무서웠어요. 따라서 1단계입니다.
6) 공식 AOSP 문서를 살펴보았습니다.
목표 달성을 위해 Android OS에 대한 블랙박스 접근 방식을 사용할 희망을 잃은 후 Android OS 아키텍처 및 지원되는 장치에 대한 요구 사항에 대한 일반 섹션을 검토하기 시작했습니다.
좋은 그림(아키텍처):
부트로더 및 보안 정보:
주요 결론:Android는 느슨한 하드웨어 표준을 사용하는 다양한 독점(FMCG 세계) 장치에서 축소된 Linux 커널을 실행하는 데 유용한 OS 기능을 확실히 도입했습니다. 주류 Linux에서 채택할 수 있고 채택해야 하는 가장 유용한 기능 중 하나는 다양한 화해 드라이버를 합리적인 방식으로 처리할 수 있는 HAL 추상화 계층입니다. 커널을 SoC 종속 부분과 보드 종속 부분으로 분할한 모듈식 커널, 절전 기능, 보안 기능도 주목할 만합니다.
좋은 소식:Linux 커널 개발자 및일부distro 벤더들은 이러한 좋은 부분들을 모두 잘 알고 있으며, 그에 상응하는 변경 사항을 도입하기 위해 최선을 다하고 있습니다. 공식 통계(그림 2 참조)해당 AOSP 문서 섹션) AOSP 코드와 주류 Linux 간의 융합에 대한 좋은 증거를 보여줍니다. 양측(AOSP 및 Linux 커뮤니티)의 융합으로 인해 확실히 긍정적인 경제적 효과가 있습니다. 자신의 투자를 보호하는 Google 및 하드웨어 생산업체와 같은 이해관계자의 경우에는 반대 방향으로 나아가는 것 같습니다. Google은 생태계와 사용자 기반에 대한 투자를 보호하고, 하드웨어 생산업체는 고급 하드웨어 개발 및 생산에 대한 투자를 보호합니다. 이 두 힘 사이의 마찰은 일종의 양의 벡터를 생성합니다. 내 생각에는 Google과 하드웨어 생산업체 사이에 이러한 마찰을 현명한 방식으로 규제하는 일종의 합의가 있어야 한다고 생각합니다. 예를 들어, 하드웨어 생산자는 보드별 드라이버 Blob을 Linux 커널에 커밋하는 것을 2~3년 정도 지연할 수 있습니다(SoC별 드라이버 Blob의 경우 이 기간은 더 짧아야 합니다). 이는 Google 및 AOSP 개발자에게 Android 생태계가 시장에서 모든 중요한 요소(모든 새로운 최신 고급 하드웨어 장치 구매, 광고 수익, 고급 사용자의 유료 소프트웨어 및 서비스)를 제거한다는 것을 보장합니다. 2-3년이 지나면 장치(더 이상 하이엔드로 간주되지 않음)는 드라이버 blob을 Linux에 커밋하여 무료로 출시됩니다(최고 등급 하드웨어 공급업체는 물론 소스 코드 커밋을 선호합니다). 기간은 하드웨어 공급업체가 대부분의 기기에 설정한 일반적인 보증 기간 및 해당 공급업체가 배포하는 공식 Android 업데이트(보안 업데이트 포함) 기간과 매우 가깝습니다. 그럴 수 있지.
나쁜 소식:그런 거래를 협상하는 것은 정말 어려운 것 같습니다(이하 - 거래)현명하고 명시적인 방식으로. 주요 문제는 글로벌 성격에 있습니다. 가능한 법적 고려 사항(다양한 관할권의 독점금지법, 국경 간 세금 문제 등), 하드웨어 공급업체 수(OEM, ODM, SoC 생산업체 등) 및 기타 관련 이해관계자(Google, AOSP, Android)를 생각해 보세요. 개발자, Linux, Linux 배포판 공급업체 - 서버, 데스크톱 및 모바일, 기타 Linux 기반 프로젝트, GNU, FSF 등 최종 사용자까지). 거래 부족으로 인해 Linux와 AOSP 간의 수렴 속도가 확실히 느려지고 있으며 이는 우리(사용자)의 공통된 후회입니다. 하드웨어 관점에서 보면 몇 년 전 주류 [멀티 코어 x86 CPU / > 2Gb RAM / > 16Gb 플래시 드라이브] 장치가 시장에 출시되었을 때 완전한 융합이 가능했습니다. 이 하드웨어를 표준 Linux 커널(데스크톱이 아닌 서버 배포판)을 실행하는 데 사용할 수 없는 경우 문제가 분명해집니다. 설치 프로그램이 없고 플래싱 도구는 공급업체에서 공식적으로 지원하지 않으며 문서가 부족하고 분산되어 있습니다. 2019년 6월에는 상황이 훨씬 나아질 수도 있습니다.
7) 다음 단계는 주요 전환 중심 커뮤니티와 지원 공급업체가 수행한 노력뿐만 아니라 하드웨어 공급업체와 AOSP/Google이 거래 협상을 위해 수행한 단계를 모니터링하는 것입니다.