System 앱의 퍼미션 획득

설명하기 번거롭고 아무도 궁금해하지 않는 System 앱의 permission 획득(granted)에 대해 알아보자. 미리 이야기 할 것은, 안드로이드의 permission 중 protectionLevel이 system인 것은 없다. 대신 signatureOrSystem이 있는데, 이 permission의 획득 방법 두 가지이며 그 중 system 앱으로서 획득하는 방법에 대해 설명하고자 한다.

설명을 하기 위해서는 먼저 앱을 단말 내장 여부에 따라 구분해야 한다. 앱을 내장 여부에 따라 구분하는 일이 적어서 용어가 정착되지 않았는데, 여기서는 스토어/프리로드 앱으로 표현하겠다.

  • 스토어(store) 앱 : 단말에 내장되어 있지 않고, 단말 제조사나 구글의 앱 스토어에서 받아 설치(or 업데이트)할 수 있다. 일반 앱이나 서드파티 앱이라고도 부른다.
  • 프리로드(preload) 앱 : 단말에 내장되어 있고, 단말 제조사나 구글의 앱 스토어에서 업데이트 할 수도 있다.

프리로드 앱 중에서 특히 /system/priv-app/ 에 설치된 앱을 system 앱이라 한다. 혹은 프리빌리지드(privileged) 앱이라고도 부른다. 이 앱이 protectionLevel가 signatureOrSystem인 permission을 획득(granted)할 수 있다.

system 앱으로서 permission을 획득하는 방법을 설명했으니, permission에 영향을 줄 수 있는 system 앱의 특성을 살펴보자.

이를 위해서는 먼저 두 앱 간 설치/업데이트/삭제 시 차이점을 설명해야 한다. 스토어 앱은 최초 설치 시 /data/app/에 자리를 잡고, 업데이트 시에도 같은 위치에 덮어 씌운다. 삭제 시 업데이트 여부에 관계없이 /data/app/에 설치되었던 앱과 데이터가 사라진다.

프리로드 앱은 최초 설치 시 /system/priv-app/에 자리 잡고, 업데이트 시 /data/app/에 자리 잡는다. 삭제는 업데이트 여부에 따라 다르다. 최초 버전은 삭제할 수 없고, 업데이트 버전만 삭제할 수 있다. 삭제 시 /data/app/에 설치되었던 업데이트 버전의 앱이 사라진다.

이를 설명한 이유는 system 앱은 최초/업데이트 버전 여부에 따라 설치위치가 달라지고, 이에 따라 permission 획득도 달라질 수 있기 때문이다. 업데이트 버전에 <user-permission/> 선언을 신규추가한 경우 protectionLevel이 signatureOrSystem인 permission을 획득할 수 없다. 위에 설명한 것 처럼 업데이트 버전은 /system/priv-app/이 아닌 /data/app/에 설치되기 때문이다.

다만, 내장된 버전이 AndroidManifest의 <use-permission> 선언을 통해 이미 획득한 permission은 업데이트 버전도 선언만 하면 상속받는 것처럼 획득할 수 있다. 꼭 새 permission을 system 앱으로서 획득하고 싶다면 바이너리에 포함해야 한다.

그 밖에

  • 안드로이드의 permission에 4가지 protectionLevel에 대한 소개는 이 글을 확인하자.
  • 프리로드 앱은 system 앱 외에 다른 종류도 있다. 최초 부팅 시에 설치 되어있지만, 삭제 가능하며 단말 초기화(factory reset) 시 다시 설치된다. 이들은 /data/app/에 설치되므로 단말에 내장된 점을 제외하고 일반 앱과 같다.
  • 처음에 system앱은 /system/이하에 설치되는 앱을 말하며 system앱 모두가 권한을 가졌다. 그러나, /system/priv-app/에 설치되는 앱에만 권한을 주도록 정책이 축소&변경된다.  (아마도) 이 때 system앱과 구별하기 위해 previleged 앱이라 부르다 현재는 특별한 권한을 가진 앱을 가리킨다는 점에서 혼용하는 것 같다.

참조

 

안드로이드 플랫폼 퍼미션(permission)

L OS부터 안드로이드 어플리케이션은 퍼미션을 protectionLevel에 따라 4가지로 구분하고 있다. 앱 개발자 입장에서는 얼마나 쉽게 권한을 얻을 수 있느냐가 중요한데, 이를 순서대로 정리하면 아래와 같다.

  • normal : <use-permission/> 선언 후, 사용자 동의 없이 사용 가능
  • dangerous : <use-permission/> 선언 후, 사용자 동의 하에 사용 가능
  • signatureOrSystem : 아래 signature에 해당하거나, 단말 출시 시 미리 내장되어 출시된 앱인 경우 사용 가능
  • signature : <permission/> 선언한 앱(여기서는 플랫폼)과 <use-permission/> 선언한 앱이 동일한 인증서로 사인된 경우 사용 가능

위 4가지 중에서 일반 개발자(이하, 서드파티 개발자)는 normal이나 dangerous의 protectionLevel을 가진 권한은 얻을 수 있으나, signature나 signatureOrSystem의 protectionLevel을 가진 권한은 얻을 수 없다. 보통 단말 제조사에서 출시시 단말에 포함하는 앱(이하, 프리로드 앱)들이 이런 권한을 사용할 수 있다. 위에 언급된 것처럼, 단말 출시 시 특정 폴더에 앱을 포함하거나, 플랫폼을 사인하는데 사용한 인증서를 사용해 앱을 사인해야 하기 때문이다. 다만, 이 글을 보면 개발 단계에서 우회적인 방법을 통해 인증서를 확보하여 signature 레벨의 권한을 테스트 해볼 수 있다.

안드로이드 개발자사이트에는 안드로이드에서 지원하는 퍼미션 목록이 정리된 페이지가 없다. 대신, 안드로이드 프레임워크 내의 AndroidManifest.xml 소스코드를 통해 각 protectionLevel 별 권한(permission) 목록을 확인할 수 있다. 참고로, normal과 dangerous, signature는 그대로, System 앱은 privileged로 표시되어 있다. 예를 들면, signatureOrSystem 앱이라면 아래와 같이 protectionLevel이 표시된다.

<permission android:name="[퍼미션이름]" android:protectionLevel="signature|privileged" />

그 밖에

  • system의 protectionLevel은 특정 폴더(/data/priv-app/*)에 앱이 자리잡고 있어야 올바르게 동작한다. 이 위치는 보통 핸드폰의 바이너리를 만들 때 결정되므로, 서드파티가 임의로 넣을 수는 없다. (물론, 루팅은 예외)
  • protectionLevel이 system 인 퍼미션은 업데이트를 통해 신규 획득할 수 없다. 이에 대한 설명은 이 글을 참조하자.
  • 단말 제조 과정에서 앱이 들어가는 프로세스를 이해하는데 도움이 될만한 인포그라픽을  HTC에서 공개했다.
Android-update-process
Android OS 업데이트 프로세스 by HTC

참조