SubingCoding

Android의 상위버전을 개발하는 과정에서 OTA Update에 대해 자세히 공부하고

직접 시나리오를 적용하여 앱을 개발할 수 있는 기회가 생겼다 😎😎 

처음에는 OTA Update의 process를 이해하는 것 부터도 어려웠는데, 

A/B Update방식을 사용한 Update App 개발을 마무리해가는 시점에 차근차근 정리해보려고한다 :)

(사실 아직 할거 짱많음 내일만 운동하고 모레부터 야근각임)

1. 비 A/B OTA Update 

기존 A/B Update방식은 복구모드로 부팅하여  Update를 진행하고 다시 재부팅하여 업데이트 하는데, A/B Update가 주제니까 간단히 process만 짚고 넘어가는걸로!!

기존 방식의 비 A/B OTA 업데이트에는 다음 단계로 이루어집니다.

1. 기기는 OTA 서버를 통해 정기적으로 체크인하고 업데이트 패키지의 URL 및 사용자에게 표시할 설명 문자열을 포함하여 업데이트 사용 가능 여부를 알립니다.
2. 다운로드를 캐시나 데이터 파티션으로 업데이트하고 암호화 서명을 /system/etc/security/otacerts.zip의 인증서와 비교하여 확인합니다. 사용자에게 업데이트를 설치하라는 메시지가 표시됩니다.
3. 부팅 파티션의 커널 대신 복구 파티션의 커널과 시스템이 부팅되는 복구 모드로 기기가 재부팅됩니다.
4. 복구 바이너리는 init로 시작됩니다. 다운로드한 패키지를 가리키는 명령줄 인수를 /cache/recovery/command에서 찾습니다.
5. 복구는 복구 파티션에 포함된 RAM 디스크의 일부인 /res/keys의 공개 키를 기준으로 패키지의 암호화 서명을 확인합니다.
6. 데이터는 패키지에서 가져와 필요에 따라 부팅, 시스템 및 공급업체 파티션을 업데이트하는 데 사용됩니다. 시스템 파티션에 남아 있는 새 파일 중 하나에는 새 복구 파티션의 콘텐츠가 포함되어 있습니다.
7. 기기를 정상적으로 재부팅합니다.
   1. 새로 업데이트된 부팅 파티션이 로드되어 마운트되고 새로 업데이트된 시스템 파티션의 바이너리 실행을 시작합니다.
   2. 정상적인 시작의 일부로 시스템은 복구 파티션의 콘텐츠를 원하는 콘텐츠(이전에 /system에 파일로 저장된 콘텐츠)와 비교하여 확인합니다. 콘텐츠가 다르므로 복구 파티션은 원하는 콘텐츠로 다시 플래시됩니다. 후속 부팅 시에는 복구 파티션에 이미 새 콘텐츠가 포함되어 있으므로 다시 플래시할 필요가 없습니다.

https://source.android.com/docs/core/ota/nonab?hl=ko

공식문서에 서술되어있듯 비 A/B OTA Update에서는 총 2번의 재부팅 과정을 거친다.

때문에 업데이트 시나리오를 개선하면서 시간적인면에서 단축이 가장 눈에 띄었다.

2. A/B OTA Update

A/B OTA Update는 복구모드로 부팅하지 않고 시스템이 실행되는동안 OTA가 진행될 수 있기 때문에, 한 번의 재부팅만으로 Update를 완료할 수 있고 아래와 같은 이점들이 있다.

• 시스템이 실행되는 동안 사용자를 방해하지 않고도 OTA 업데이트가 진행될 수 있습니다. 사용자는 OTA 도중 계속해서 기기를 사용할 수 있으며, 업데이트 도중의 유일한 다운타임은 기기가 업데이트된 디스크 파티션으로 재부팅되는 순간뿐입니다
• 업데이트 이후에는 재부팅 시간이 일반 재부팅 시간보다 오래 걸리지 않습니다.
• 플래시 불량 등으로 인해 OTA 적용에 실패하더라도 사용자에게 미치는 영향은 없습니다. 사용자는 계속해서 기존 OS를 실행하고, 클라이언트는 자유롭게 업데이트를 재시도할 수 있습니다.
• OTA 업데이트가 적용되었지만 부팅에는 실패한 경우에는 기기가 기존 파티션으로 재부팅되고 가용성을 유지합니다. 클라이언트는 자유롭게 업데이트를 재시도할 수 있습니다.
• I/O 오류를 비롯한 모든 오류는 설정된 미사용 파티션에만 영향을 미치며 재시도 가능합니다. I/O 로드가 사용자 환경 저하를 피할 수 있도록 의도적으로 낮게 설정되었기 때문에 이러한 오류가 발생할 확률도 감소합니다.
• 업데이트는 A/B 기기로 스트리밍할 수 있습니다. 따라서 설치 전에 패키지를 다운로드할 필요가 없습니다. 스트리밍 덕분에 사용자에게는 /data 또는 /cache에 업데이트 패키지를 저장할 여유 공간이 충분하지 않아도 됩니다.
• 캐시 파티션이 더 이상 OTA 업데이트 패키지를 저장하는 데 사용되지 않으므로 캐시 파티션이 향후 업데이트를 저장할 수 있을 정도로 큰지 확인할 필요도 없습니다.
• dm-verity는 기기가 손상되지 않은 이미지를 부팅하도록 보장합니다. OTA 불량 또는 dm-verity 문제로 인해 기기가 부팅되지 않는 경우에는 기기를 기존 이미지로 재부팅할 수 있습니다. Android 자체 검사 부팅에는 A/B 업데이트가 요구되지 않습니다.

https://source.android.com/docs/core/ota/ab?hl=ko 

그래서 왜 A/B Update냐면 기존에 사용하고 있는 슬롯과 업데이트를 한 슬롯 두개로 업데이트를 진행할 수 있기 때문에 (A slot과 B slot) 붙여진 이름(이라고 생각합니다만 맞을...껄?)인데, process를 보면 왜인지 이해가 자연스레 가능합니다!

실제 A/B OTA Update 방식은 참고자료와 함께 자세히 정리해보겠습니다! 

공식문서도 너무 잘 되어있어서 충분한데, 처음 접할때 이것저것 찾아보면서 만든 자료가 있어서 공유하고 기록하고자 합니다 :)

근데 그게 회사 컴퓨터에 있그든요 ㅎㅎㅎ... 내일 옮겨두고 시간되는대로 작성하기 !! 꼮꼮!!

1. 빌드 환경 세팅

$ rm -rf .idea

$ source ~~~ // 환경설정하기

$ lunch ~~~ // 환경설정하기

2. idegen 빌드 후 실행

$ mmm development/tools/idegen -j($nproc)

$ develop/tools/idegen/idegen.sh

3.  Android.ipr 실행

Root  Directory로 이동하면 Android.ipr 파일이 생김.

AndroidStudio를 열어 Android.ipr을 Open!

참고

https://stackoverflow.com/questions/16727607/can-we-use-android-studio-for-aosp-development

1. 터미널에서 빌드 셋업
    Move to the BSP root directory.
    Set up the development environment.
    $ source env.rc // export path
    $ source build/envsetup.sh
    $ lunch 

2. 수정한 파일의 상위 폴더로 이동
3. 수정한 파일의 상위 경로 Android.bp 참고하여 java library name 확인
    ex)
    cc_binary {
        name: "update_engine", 

4. mm 빌드 
    ex) mm update_engine

5. out 폴더로 이동
    cd $OUT

6. 확인한 library name을 find 명령어로 검색
    $ find -iname services*
    ->  ./system/framework/oat/arm/services.odex
        ./system/framework/oat/arm/services.vdex
        ./system/framework/oat/arm/services.art
        ./system/framework/services.jar

    $ find -iname update_engine
    ->  ./system/bin/update_engine

7. adb root && adb remount

8. 검색한 파일들을 adb push
    adb push system/framework/services.jar /system/framework/
    ...

10. adb shell sync && adb reboot