Towards Understanding Android APIs: Official Lists, Vendor Customizations, and Real-World Usage

1. 문제 정의 (Problem)

안드로이드 애플리케이션은 안드로이드 시스템의 핵심 기능을 추상화한 API 에 기반하여 개발됩니다. 이러한 API 정보는 소스 코드나 SDK 에 배포되는 여러 공식 파일 (Android API Lists, AALs) 에 문서화되어 있습니다. 이전의 안드로이드 관련 연구들은 이러한 특정 AAL 들을 상호 교환 가능한 '진실 (ground truth)'로 간주하고 의존해 왔습니다.

그러나 최근 연구들은 서로 다른 AAL 들이 상이한 연구 결과를 초래할 수 있음을 시사하며, AAL 기반 분석의 유효성과 재현성에 대한 우려가 제기되었습니다. 구체적으로 다음과 같은 문제들이 존재합니다:

• 불일치: 동일한 안드로이드 버전에서도 서로 다른 AAL 파일들이 상이한 API 정보를 기록하고 있음.
• 부정확성: AAL 에 기록된 API 가 실제 실행 중인 안드로이드 기기에서 존재하지 않거나, 반대로 AAL 에 누락된 API 가 실제로 사용 가능할 수 있음.
• 연구 결과 왜곡: 불완전하거나 부정확한 AAL 을 사용할 경우, 호환성 문제 탐지 등 다양한 연구의 결과가 왜곡될 수 있음 (예: PSDroid 와 같은 최신 도구의 오탐/미탐).

2. 연구 방법론 (Methodology)

저자들은 4 가지 주요 공식 AAL 과 6 가지 안드로이드 릴리스 버전을 대상으로 포괄적인 실증 연구 (Empirical Study) 를 수행했습니다.

2.1 연구 대상 (4 가지 AAL)

1. JAR List (android.jar): Android SDK 에 포함된 컴파일된 클래스 파일.
2. XML List (api-versions.xml): API 의 수명 주기 (추가/삭제/비공식화 시기) 를 포함하는 XML 파일.
3. TXT List (current.txt): 안드로이드 소스 코드에 포함된 소스 레벨 API 시그니처.
4. CSV List (hiddenapi-flags.csv): Android 9 부터 도입된 비-SDK 인터페이스 (Non-SDK interfaces) 의 차단 정책을 포함한 파일.

2.2 데이터 수집 및 분석

• API 추출: 각 AAL 파일에서 클래스, 필드, 메서드를 체계적으로 추출하여 정량화했습니다.
• 실제 기기 검증 (RQ3): 9 대의 안드로이드 기기 (3 대의 스톡 안드로이드, 6 대의 벤더 커스터마이징 기기) 에서 직접 Java Reflection 을 사용하여 AAL 에 기록된 API 가 실제로 존재하는지 검증했습니다. 이를 위해 AAL-Reflector 도구를 개발했습니다.
• 실제 앱 사용 분석 (RQ4): 17,759 개의 실제 안드로이드 앱 (오픈소스, 상용 앱, 멀웨어) 을 분석하여 어떤 API 가 실제로 사용되는지 파악했습니다. APK-Analyzer 도구를 사용하여 직접 호출, 추가 호출 (비 AAL API), 리플렉션 호출을 구분하여 분석했습니다.

2.3 연구 질문 (Research Questions)

• RQ1: 4 가지 AAL 에 포함된 API 수와 그 변화 추이는 어떠한가?
• RQ2: 4 가지 AAL 간의 API 포함 정책과 불일치는 무엇인가?
• RQ3: AAL 에 기록된 API 가 실제 안드로이드 기기에 존재하는가?
• RQ4: 실제 안드로이드 앱들은 AAL 의 어떤 API 를 주로 사용하는가?

3. 주요 기여 및 발견 사항 (Key Contributions & Results)

3.1 AAL 의 불일치 및 불안정성 (RQ1, RQ2)

• 상호 불일치: 4 가지 AAL 간에 공유되는 API 는 전체의 약 10% 에 불과했습니다. 나머지 90% 는 특정 AAL 에만 존재하거나 누락되어 있었습니다.
• CSV List 의 독점성: CSV List 는 다른 3 가지 목록에 비해 압도적으로 많은 API 를 포함하고 있었으나, 이는 컴파일 과정에서 생성된 합성 API(람다, 익명 클래스 등) 나 다른 언어 (AIDL, Proto, C/C++) 로부터 변환된 API 들이 대량 포함되었기 때문입니다.
• 정책의 불안정성: 안드로이드 플랫폼 진화에 따라 AAL 의 API 포함 정책이 급격히 변했습니다. 예를 들어, API 레벨 31 에서 TXT 목록은 JDK 및 서드파티 패키지를 대량 제거하여 API 수가 급감했습니다.
• 삭제된 API 의 잔존: AAL 에서 '삭제'된 것으로 표시된 API 들 중 상당수가 실제 안드로이드 런타임 (Source Code 및 기기) 에 여전히 존재하며, 리플렉션을 통해 호출 가능했습니다.

3.2 실제 기기에서의 API 존재 여부 (RQ3)

• JAR/XML/TXT 의 부재: JAR, XML, TXT 목록에 포함된 일부 API(주로 테스트 관련 API 나 인라인된 멤버) 는 실제 기기에서 존재하지 않았습니다.
• CSV 의 높은 정확도: CSV 목록에 포함된 API 는 실제 기기에서 존재할 확률이 매우 높았으나 (약 99.7%), 커스터마이징된 기기 (MIUI, One UI 등) 에서는 스톡 안드로이드와 다른 비-SDK 인터페이스가 존재하거나 차단되는 등 시스템 간 차이가 있었습니다.
• 비-AAL API 의 존재: 4 가지 공식 AAL 에 기록되지 않았지만, 실제 기기 (특히 벤더 커스터마이징 시스템) 에 존재하는 공개된 Java API 들이 다수 발견되었습니다.

3.3 실제 앱에서의 API 사용 (RQ4)

• 공유 API 의존: 대부분의 앱은 4 가지 AAL 에 공통으로 포함된 핵심 API 를 주로 사용했습니다.
• 비공유 API 및 벤더 API 사용: 오픈소스 앱, 상용 앱, 멀웨어 모두 AAL 에만 존재하는 API 나 벤더 커스터마이징 API 를 사용했습니다. 특히, 멀웨어와 상용 앱은 오픈소스 앱보다 비-SDK 인터페이스 (Non-SDK interfaces) 를 리플렉션을 통해 호출하는 경향이 더 강했습니다.
• 추가 호출 (Extra Calls): 앱들은 AAL 에 없는 Android Support 또는 AndroidX 라이브러리 API 를 광범위하게 사용했습니다.

4. 연구의 의의 및 시사점 (Significance & Implications)

1. AAL 의 신뢰성 재고: 연구자들은 특정 AAL 을 '진실'로 간주하기보다, 연구 목적에 맞는 AAL 을 신중하게 선택하고 그 한계를 명시해야 합니다. 단일 AAL 은 모든 API 를 포괄하지 못합니다.
2. 연구 도구의 개선 필요: 호환성 문제 탐지 도구 (PSDroid 등) 는 AAL 의 불완전성으로 인해 오탐/미탐을 일으킬 수 있으므로, 실제 런타임 검증이나 다중 AAL 교차 검증이 필요합니다.
3. 비-SDK 및 벤더 API 연구의 필요성: 기존 연구들이 간과해 온 비-SDK 인터페이스와 벤더 커스터마이징 API 는 실제 앱에서 활발히 사용되며, 보안 취약점과 호환성 문제의 주요 원인이 될 수 있으므로 이에 대한 심층 연구가 요구됩니다.
4. 데이터 및 도구 공개: 연구진은 분석에 사용된 AAL 데이터셋, 도구 소스 코드, 실험 결과를 GitHub 에 공개하여 향후 연구의 재현성과 확장성을 지원했습니다.

5. 결론

이 논문은 안드로이드 API 연구의 기초가 되는 4 가지 공식 목록 (AAL) 이 서로 불일치하고 불안정하며, 실제 기기 환경과 괴리가 있을 수 있음을 실증적으로 증명했습니다. 이는 안드로이드 호환성, 보안, 그리고 앱 분석을 수행하는 연구자들과 실무자들에게 AAL 선택의 중요성과 주의점을 경고하며, 향후 연구 방향을 비-SDK 및 벤더 커스터마이징 API 로 확장할 것을 제안합니다.