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 앱이라 부르다 현재는 특별한 권한을 가진 앱을 가리킨다는 점에서 혼용하는 것 같다.

참조

 

startActivity가 안돼요

startActivity 메소드(startActivityForResult 메소드 포함)는 파라미터로 전달된 인텐트(Intent) 정보로 액티비티를 실행한다. 안드로이드 책 처음마다 이 메소드 소개는 빠지지 않는다. 그렇게 많이 사용하는데, 왜 안될까?

확인이 쉬운 것부터 살펴보자. 액티비티 호출을 위해 만드는 인텐트 유형은 명시적 인텐트와 암시적 인텐트로 나뉜다. 인텐트를 잘 만들었는지 살펴보자.

  • 명시적 인텐트는 호출할 대상 패키지와 패키지 속 액티비티 정보를 넣어야 한다. 명시적 인텐트를 통해 호출을 시도했으나 에러가 난다면 패키지나 액티비티 이름이 틀린 것은 아닌지 확인해보자.
  • 암시적 인텐트는 액션(action)을 이용하므로, 액션이 틀렸는지 확인하자.

intent에 넣은 정보가 맞는데도 안되는 경우도 있다. 그럼, 다음 경우도 생각해 보자.

  • 암시적 인텐트를 사용할 때 액션과 함께 전달하는 추가정보가 잘못 되었는지 확인하자.  예를 들면, AndroidManifest.xml에 액티비티가 처리할 수 있는 URL 스키마를 선언할 수 있다. 이 설정과 전달하는 url 데이터가 맞지 않다면 실행되지 않는다.
  • 퍼미션이 필요한지 확인하자. 안드로이드의 컴포넌트는 자신을 호출하는 앱이 퍼미션을 갖고(granted)있어야 실행하도록 강제할 수 있다. 퍼미션이 없다면 Exception이 발생한다.
  • 액티비티가 앱 외부에서 공개되지 않게 설정되었을 수도 있다. AndroidManifest.xml 내의 액티비티 컴포넌트 선언부의 android:exported 어트리뷰트가 true인지 확인하자. 참고로, 기본값이 true다.
  • intent에 넣은 정보가 맞는데도 실행이 안된다면 앱이 설치되었는지 확인하자. 앱 슬롯이나 셋팅 내 어플이케이션 목록을 통해 확인할 수 있다.
  • 설치가 되었는데도 실행되지 않는다면 앱이 비활성화 됐을 수 있다. 셋팅 내 어플이케이션 목록에서 앱을 찾아, 사용하지 않기(비활성화)로 둔 것은 아닌지 확인해보자.
  • 혹시, MAIN 액션과 LAUNCHER 카테고리를 가지는 일명 메인 액티비티가 실행되지 않는다면 이 글을 읽어보자.

그 밖에

액티비티를 실행할 때는 가능하다면 암시적 인텐트를 이용하자.

  • 같은 액션을 활용하는 모든 앱이 사용자에게 표시되므로 사용자에게 선호하는 앱을 이용할 수 있게 선택권을 줄 수 있다.
  • 호출할 액티비티의 패키지 이름이 바뀌더라도 명시적으로 컴포넌트를 선언하지 않기 때문에, ActivityNotFoundException과 같은 문제가 발생하지 않는다.
  • 액티비티 정보는 쉽게 알 수 없으니 명시적 인텐트가 안전하다고 생각하는 경우가 있다. dumpstate의 설치된 앱 정보 등을 통해 액티비티를 알아낼 방법은 다양하므로, 호출은 모두 가능하다. 잘못된 값이 전달될 위험은 값을 validation하여 대응하고, 사용 자체를 막고자 한다면 퍼미션을 활용하자.

참고

메인 액티비티 실행이 안돼요

일반적으로 앱은 아이콘이 있다. 아이콘을 누르면 진입점 역할의 액티비티가 실행된다. 이 액티비티를 편의상 메인 액티비티라고 부르자.

메인 액티비티를 만드는 법은 간단하다. AndroidManifest.xml에 선언된 액티비티 중 메인으로 만들고 싶은 것을 골라 아래와 같이 MAIN 액션과 LAUNCHER 카테고리가 포함된 인텐트 필터를 추가하면 된다.

<intent-filter>
     <action android:name="android.intent.action.MAIN" /> 
     <category android:name="android.intent.category.LAUNCHER" />
</intent-filter>

위와 같이 인텐트 필터를 선언하면, 런쳐는 메인 액티비티로 판단하여 앱 슬롯에 아이콘을 표시한다.

그럼, 코드로 메인 액티비티를 실행해보자. 내 앱이라면 패키지 이름과 컴포넌트 이름으로 명시적 호출도 가능하다. 여기서는 암시적 인텐트를 이용해 보자.

adb shell am start <패키지이름>

패키지 이름만 건네면 앱의 메인 액티비티를 찾아 실행하는 명령어다. 위 명령어로 앱들을 실행해보면 어떤 앱은 실행되고 어떤 앱은 실행되지 않는다. 왜 그럴까?

실행여부는 <intent-filter>에 android.intent.category.DEFAULT가 있어야 있느냐에 따라 달라진다. DEFAULT 카테고리가 있어야 패키지 이름만으로 실행할 수 있는 것이다.

숨겨진 액티비티도 아니고 아이콘이 노출된 앱인데 코드로 실행할 수는 없다니 이상하다. 게다가, 메인 액티비티는 공개된 액티비티이므로 android:exported=”true”도 강제라고 한다. 그럼 외부에서 실행하는 것을 보장하겠다는 뜻이 아닌가?

이런 앞뒤가 맞지 않는 상황 때문인지 안드로이드의 PackageManager 클래스는  API3부터 getLaunchIntentForPackage()라는 설명이 재미있는 API를 제공한다.

Returns a "good" intent to launch a front-door activity in a package. 
...(이하 생략)

메인 액티비티를 실행하는 “좋은” 인텐트를 만들어 반환한다고 API 설명이 되어 있다. 하지만, 이 API도 MAIN 액션, LAUNCHER 카테고리를 가진 액티비티를 찾아 반환하는 것이므로 여전히 인텐트 필터는 필요하다.

메인 액티지티를 만들 때 DEFAULT 카테고리도 잊지 말고 추가하도록 하자. 다른 앱이 내 앱을 한 번이라도 더 실행하도록 말이다.

그 밖에

  • 한 앱에서 MAIN, LAUNCHER 속성을 2개 이상의 액티비티에 동시에 선언할 수 있으며, 이 때 아이콘이 각각 생긴다.
  • 아이콘의 레이블은 액티비티의 레이블을 따라간다. 그러므로, 아이콘을 다르게 여러 개 만들 수도 있다.

참조

디자인 패턴에서 말하는 투명성

디자인 패턴 공부를 하면 투명성(transparency)이란 단어를 만난다. 이 단어에 대한 설명은 아무리 읽어도 쉽게 와닿지 않는데, 아마도 번역이 부적절하기 때문이라 생각한다.

transparency는 컴포지트 패턴에서 같은 부모를 상속받은 객체 컬렉션과 개별 객체 두 클래스 중 한 쪽에는 불필요한 메소드가 있을 때 이를 구현할 필요가 있는지 설명하는 과정에서 언급된다. 구현하는 경우 부모 클래스만 이해하면 자식 클래스를 일일이 살펴보지 않고도 사용할 수 있어 transparent하다고 한다.

사전에서 transparent(cy)를 찾아보면 ‘투명한’이란 뜻 외에 ‘명료한, 명쾌한, 솔직한’이란 뜻도 있다. 위 장점에 대한 설명으로는 이해가 쉽다, 명료하다는 말이 적절해 보인다. 부모 클래스를 이해한 것으로 하위 클래스도 쉽게 이해할 수 있다는 점을 가리키는 단어기 때문이다.

최근에 일부 책이나 글은 투명성이 아닌 명료성으로 번역하고 있고, 나도 명료성이 더 적절하다고 생각한다. 처음부터 그랬다면 더 좋았겠지만, tranparency란 단어의 개념이 명확치 않았을 때 잘못 번역된 것 같아 아쉽다.

카페24 호스팅 복원하기

워드프레스의 젯팩을 업데이트하다, 아래와 같은 메시지와 함께 이 블로그가  먹통이 되었다.

The site is experiencing technical difficulties.

직접 젯팩 플러그인을 제거하나 고쳐볼 생각을 하다가 카페24의 호스팅 복원 기능을 활용하는 아이디어가 생각났다. 카페24는 매일 정기적으로 자동 백업을 하여, 최대 일주일까지 보관해준다. 이제 복원을 해보자.

  • 카페24 메인 > 우측 상단의 ‘나의 서비스 관리‘ 페이지로 이동하자.
  • 좌측 가운데 있는 계정관리 > Data&DB복원/백업 메뉴를 통하면 아래와 같은 화면을 볼 수 있다.

  • 여기서 대상, 구분, 기간을 순서대로 선택 후 하단의 ‘실행’하면 빠르게 진행된다.

다시 접속해보니, 아무 일 없던 것처럼 살아났다. 젯팩을 제거한 후 다시 설치하는 수고로움도 덜어 만족 스럽다.