반응형

요약 Android.bp 파일이란?

- Blueprint 파일의 줄임말 -> bp

 

Android Platform

 Android Platform은 Android Operating system에서 유저 공간 파트인데요.
Android Platform은 Android Open Source Project (AOSP) 안에서 구현되어졌습니다.


AOSP는 수백 개의 레포지토리들어 만들어져 있습니다. (780개 in Android 11).
https://android.googlesource.com/

소스코드는 흔한 툴(repo와 git)으로 관리됩니다.
아래의 예시를 보시죠.

// 레포지토리를 해당 링크로 초기화하기.
$ repo init -u https://android.googlesource.com/platform/manifest

// 레포지토리를 동기화 (다운로드) 하기
$ repo sync


소스코드가 매우 큽니다.. Android 11은 소스코드가 무려 100GB나 됩니다. (위의 명령대로 실행했을 시)
그리고 빌드 이후에 115GB가 증가될겁니다.

커뮤니티와 콜라보레이션

몇몇의 토론하는 그룹들이 활성화 되어있습니다. 이 그룹들은 커뮤니티와 개발자 사이에 서로 소통하기 위해서 만들어졌습니다.
https://groups.google.com/d/forum/android-platform

어느 누구던지 Gerrit code review tool을 이용해,
프로젝트에 컨트리뷰트(contribute, 기여하다)할 수 있습니다.

프로젝트의 진화 그리고 안드로이드의 미래 버전으로 가능하게 될 features들은,
Google에 의해 독점적으로 통제됩니다.

라이센싱

대부분의 소프트웨어 구성요소는 Apache 및 BSD 라이센스를 통해 허용됩니다.
몇몇 소프트웨어 컴포넌트들은 GPL/LGPL 라이센스 하에 있습니다.
몇몇 Google 애플리케이션 소스코드는 닫혀있습니다. (Google Play, Gmail, Google Maps, YouTube, etc).
 -> 이 애플레케이션들은 Google Mobile Services (GMS)라 불리우는 패키지 안에서 사용가능합니다.
  그리고, 그것을 얻으려면 디바이스 인증을 해야합니다, (ACP)

빌드 시스템

과거에 Android 빌드 시스템은 순수하게 makefiles 기반이었습니다.
makefile 많이 들어보셨죠? 맞습니다. Linux C언어에서 빌드할 떄 쓰는 그 명령어 입니다.
 각각의 소프트웨어 컴포넌트를 컴파일하기 위한 명령어들은 Android.mk 파일들 안에 정의됩니다.

이 빌드 시스템은 몇가지 단점들이 존재했었는데요. 바로 증분(증가하는) 빌드에 대해서 낮은 퍼포먼스를 가지고 있다는 점이었습니다.

그것은 Android 최신 버전에서, Soong Build 시스템으로 교체되었습니다.
https://android.googlesource.com/platform/build/soong

 

Soong

소프트웨어 컴포넌트들을 컴파일하기 위한 Rule들은 Blueprint files(Android.bp) 안에 정의되어있습니다.
그것은 JSON과 비슷한 문법을 가지고 있죠.

Blueprint 파일들은 Blueprint tool에 의해 처리되는데요,
그것은 Android software 컴포넌트들을 처리하기위한, 모든 룰들이 포함된 .ninja 파일을 생성합니다.
https://opensource.google.com/projects/blueprint

그 .ninja 파일들은 Ninja tool에 의해서 처리됩니다. 
그 Ninja tool은 모든 소프트웨어 컴포넌트들을 컴파일합니다, 최종적으로 Android images를 생성하기 위해 말이죠.
https://ninja-build.org/

모든 make file(Android.mk) 들은 Blueprint files(Android.bp)로 이 새로운 빌드 시스템으로
migration 되는 동안 변환되지 않습니다.
이 이유 때문에, kati라는 툴이 있습니다. 이것은 Android.mk 파일들은 .ninja 파일들로 변환시켜주죠.
https://github.com/google/kati

 

 

 하지만 요새는, Android.bp로 넘어가는 추세입니다. 모든 Android.mk 파일들은 Android build system에서 kati 툴을 사용하려는 필요를 제거하면서, 다음 Android 릴리즈 안에서 서서히 Android.bp 파일로 변환해야만 합니다.

 

 

기존의 Android.mk 파일

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES = helloworld.c
LOCAL_MODULE = helloworld
LOCAL_MODULE_TAGS = optional
include $(BUILD_EXECUTABLE)

 

새로운 Android.bp 파일

cc_binary {
 name: "helloworld",
 srcs: ["helloworld.c"],
 tags: ["optional"],
}

 

관련 링크 : https://docs.bazel.build/versions/main/be/overview.html?hl=ko

 

 

원격 연결과 디버깅 (그리고 ADB)

보통 임베디드 리눅스 시스템에서 디버깅하는 작업은 JTAG interface 혹은 시리얼 포트를 통해 이루어지죠. (low level 디버깅을 위해)

 그러나, 모바일 그리고 Consumer devices (cell phone들 그리고 테블릿 같은)은 정상적으로 이 인터페이스들을 가지고 있지 않죠. 이게 차이점이죠, 기존의 디바이스들과 다른.

 이러한 이유로, Google은 ADB을 개발했습니다. (Android Debug Bridge).

https://developer.android.com/studio/command-line/adb

 

 

 아래는, 디바이스 안에 있는 /bin/cat폴더 가져오는 (pull) 예제입니다.

(권한 관련문제가 뜨면, add root를 먼저 입력하시고 진행해보길 바랍니다, adb root는 루트 권한을 얻은 채로 타겟 디바이스에 접근하겠다 라는 의미)

$ adb devices
List of devices attached
emulator-5554 device
$ adb pull /bin/cat
/bin/cat: 1 file pulled, 0 skipped. 8.2 MB/s (384688 bytes in 0.045s)
$ adb shell
generic_x86_64:/ #

 

 

C 라이브러리

Linux 커널의 기반한 OS의 주요 컴포넌트들 중 하나는 바로 C 라이브러리입니다.

 이 C 라이브러리는 OS의 API들을 구현합니다, 그 API들은 system call들을 통해 애플리케이션이 커널 서비스들을 접근할 수 있도록 인터페이스를 제공하죠.

 glibc, uclibcng 및 musl을 비롯한 여러 C 라이브러리를 Linux 시스템에 사용할 수 있습니다.

안드로이드는 그 자신만의 C 라이브러리를 가지고 있습니다. Bionic이라는 이름으로요! (중요합니다)

 

BIONIC

 적어도 세가지 이유로 구글은 자신만의 C 라이브러리를 구현했을 것입니다.

라이센스, 속도 그리고 사이즈

 

 이 Bionic의 구현은 간단합니다, 가볍고 그리고 BSD 라이센스 하에 릴리즈되죠 (source code in bionic/.)

 

 이것은 완전하게 POSIX 지원을 하진 않습니다. 그 사실은 Android를 위한 네이티브 Linux 앱들을 빌드하는게 어렵게 만들 수 있습니다.

 

 

 

 

 

개념 체크

Q. Android software 컴포넌트들을 처리하기위한 모든 룰들이 포함된 파일은?

A. .ninja파일

 

Q. Android images를 생성하기 위해 모든 소프트웨어 컴포넌트들을 컴파일 하기위한 툴은?

A. Ninja tool

 

참고자료


https://elin​ux.org/images/6/6e/Slides-embedded-android.pdf

반응형