Android 10 스토리지 정책 대처하기

개발/안드로이드 2021. 5. 18. 20:40 Posted by 아는 개발자

targetSdkVersion 을 30으로 올리면 파일 절대 경로를 사용해서 접근 할 수 없기 때문에 개발자들은 지금부터 슬슬 절대 경로를 사용해서 접근하는 코드를 변경해야한다. 이번 포스트에서는 안드로이드 새로운 스토리지 정책을 적용한 과정을 다뤄본다.

 

1. 절대 경로 대신 Uri 를 사용하도록 변경

 

기존에는 ContentResolver 클래스를 이용해 파일을 읽어올 때 DATA 칼럼을 이용해서 파일의 절대 경로를 읽어올 수 있었다. 그런데 DATA 컬럼은 Android 10부터 Deprecated가 됐고, targetSdkVersion 30으로 올리면 DATA 칼럼으로 얻을 수 있는 절대 경로로 파일이 접근이 되지 않는다. 

 

private suspend fun loadVideoContent(): Cursor? = coroutineScope {
    val where = MediaStore.Video.VideoColumns.SIZE + " > " + 0
    val sortOrder = MediaStore.Files.FileColumns.DATE_ADDED + " DESC"
    val projections = listOf(
        MediaStore.Video.Media._ID,
        MediaStore.Video.Media.DATA, // Deprecated됨
        MediaStore.Video.Media.DISPLAY_NAME
    ).toTypedArray()

    return@coroutineScope requireActivity().contentResolver.query(MediaStore.Video.Media.EXTERNAL_CONTENT_URI, projections, where, null, sortOrder)
}

 

 

이제는 우리에게 익숙한 절대 경로 대신 Uri를 이용한 상대 경로를 사용해야한다. Uri는 content:// 로 시작하는 문자열인데, _ID 칼럼에서 얻어온 값과 ContentUri 클래스를 이용해서 얻어올 수 있다. 이 값도 파일을 찾는 경로로 사용되며 현재 Glide, MediaMetadataRetriever, Exoplayer처럼 유명한 안드로이드 라이브러리들은 Uri를 통해서도 파일을 불러올 수 있게끔 업데이트가 된 상태라 호환성은 크게 걱정하지 않아도 된다. 절대경로와 다른점은 실제 파일의 경로를 보여주지 않아 플랫폼 보안적인 요소가 강화된다. 반대로 개발자의 피로도는 악화되고.

 

val uriCol = cursor.getColumnIndex(MediaStore.Video.Media._ID)

do {
    mediaItems.add(
        MediaItem(
            ContentUris.withAppendedId(
                MediaStore.Video.Media.EXTERNAL_CONTENT_URI,
                cursor.getLong(uriCol)
            ),

 

2. File 클래스를 선언해야하는 경우 

 

문제는 File 클래스를 선언해야하는 경우다. 오래된 오픈소스거나 Uri를 고려하지 않은 모듈인 경우엔 절대 경로가 필요한 File 클래스를 사용해야하는 경우가 종종 있다. 그런데 앞서 언급했듯이 Uri는 상대 경로다. Uri를 통해 File 클래스로 바꿀수 있긴 한데 이건 file 스키마를 가진 Uri인 경우에만 그렇다. Uri 클래스에 Kotlin에 확장 코드로 toFile() 함수가 있긴 한데 ContentUris로 얻어온 Uri 클래스에 쓰면 요런 에러가 뜬다.

 

 

이럴 때는 절대 경로를 읽을 수 있는 형태로 꼼수가 필요하다. Android 10부터 스토리지를 절대 경로로 접근하는 것은 안되지만 앱 전용 캐시 영역은 여전히 절대 경로로 접근 할 수 있다. 스토리지에 있는 파일을 캐시로 복사하면 복사한 파일의 절대 경로로 파일 클래스를 선언해줄 수 있다. copy 작업이 딜레이도 있고 불필요하게 캐시영역 써야해 완벽한 방법은 아니다. 하지만 라이브러리에서 Uri를 지원하기 전까지는 써먹을 수 있을 것 같다. 더 좋은 방법이 있다면 공유해주시면 좋겠다. 나는 이것 말고는 딱히 방법을 못찾겠다...

 

val dir = File(context.cacheDir.path + File.separator + effectFolderName)
val filePath = context.cacheDir.path + File.separator + effectFolderName + File.separator + filename
val file = File(filePath)
val inputStream = getApplication<App>().contentResolver.openInputStream(uri)

try {
    FileUtils.copyToFile(inputStream, it) // org.apache.commons.io 를 사용
} catch (e: IOException ) {
    e.printStackTrace()
}

 

3. 미디어 파일을 추가하는 경우

 

앱에서 이미지나 동영상을 다운받는 경우 예전에는 Environment.getExternalStorageDirectory().path 코드를 이용해서 직접 원하는 경로에 파일을 생성해서 추가할 수 있었으나 Android 10 부터는 ContentResolver를 이용해 Uri로 파일을 추가해야한다. 아래 코드는 이미지 파일을 저장소에 추가하는 코드다. ContentValues 값을 설정해 임의의 이미지 파일을 만든 후 insert 함수에서 생성된 Uri 변수로 FileOutputStream을 만들고 I/O 라이브러리를 이용해 기존 파일과 복사하는 작업이다. 관계형 데이터베이스에 새로운 행을 추가하고 값을 업데이트한다고 보면 쉬울 것 같다. 실제로 ContentResolver는 관계형 데이터베이스 쿼리랑 상당부분 흡사하다.

 

val collection = MediaStore.Video.Media.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY)

val contentvalues = ContentValues().also {
    it.put(MediaStore.MediaColumns.RELATIVE_PATH, "Images")
    it.put(MediaStore.MediaColumns.DISPLAY_NAME, name)
    it.put(MediaStore.MediaColumns.IS_PENDING, true)
}

val uri = context.contentResolver.insert(collection, contentvalues)
val fos = context.contentResolver.openOutputStream(uri!!, "w")

try {
    FileUtils.copyFile(sourceFile, fos)
} catch (e: IOException) {
    return false
}
values.put(MediaStore.MediaColumns.IS_PENDING, false)
context.contentResolver.update(uri, values, null, null)

 

728x90

저장공간으로부터 파일을 읽어오는 앱을 출시한 개발자의 경우 올해 4월 15일부터 플레이스토어에서 아래 알림을 보게 될 확률이 높다..!

 

평소 같으면 이런 알림은 그냥 넘겨버렸는데 이번 공지에는 "허용된 용도 외에 모든 파일 액세스 권한에 액세스를 요청하는 앱은 Google Play에서 삭제되고, 업데이트를 게시할 수 없게 됩니다" 라는 무시무시한 경고문이 들어 있어 개발자들을 당황스럽고 잔뜩 쫄아버리게 만든다. 아니 갑자기 스토어에서 내려버리겠다고 으름장을 내다니. 그것도 5/5일부터 적용할 예정인 정책을 4/15일에 알려주는건 어처구니가 없다. 한 달 전도 아니고 3주 남짓한 시간 정도에 이걸 어떻게 모두 정리하냐는 말이다. 그래서 평소 같으면 그냥 지나쳐버린 자세히 알아보기 버튼을 클릭했다.

 

다행히 정책이 적용되는 버전은 Android 11 수준을 타겟팅하는 앱 대상이다. 만약 현재 안드로이드 앱의 타겟 SDK가 29이하라면 아직까진 안심해도 좋다. 그런데 일찍 Android 11로 업그레이드 완료했다면 모든 권한을 요청하고 있다면

 

1. 지금부터 불필요하게 권한을 요청하는 코드를 없애던지, 

 

2. 모든 권한을 요청해야하는 이유를 양식으로 제출하던지,

 

3. SDK 버전을 29로 다시 내리던지 

 

하는 선택을 해야한다. 대부분 앱이 아직 SDK 29버전을 따르고 있을 것 같아서 큰 문제는 없을 것 같은데 부지런히 SDK 30으로 업그레이드한 개발자들은 일찍 일어난 새가 모이를 먼저 먹지 못하고 구글의 깡패 같은 정책을 먼저 얻어 맞는 꼴이니 억울함이 상당할 것 같다. 공지에 따르면 코로나 19 관련 고려사항이라고 하는데 코로나랑 저장공간 권한이 무슨 관련이 있는건지.. 그러면 SDK 30 이하 버전들도 공통적으로 적용돼야하는거 아닌가. 코로나가 SDK 30을 타겟팅한 앱만 좋아하는 것도 아닌데.

 

코로나를 핑계로 둔건지 모르겠지만 아무튼 구글은 앞으로 저장 공간에 관한 권한 관리를 빡세게 할 것을 암시하고 있다. Android 10 때 야심차게 범위 저장 공간(Scoped Storage)를 내놨다가 쓰기 어렵다는 베타 개발자들의 아우성을 듣고 requestLegacyExternalStorage 옵션을 열어 줬는데 이제는 개발자 너희들도 슬슬 준비해야 할 때라고 눈치를 주는 느낌(?) 이다. 당시엔 개발자 커뮤니티의 반대가 워낙 심각해서 구글이 이 정책을 포기할 것 같았으나 포기는 커녕 플레이스토어에서 내려버릴 거라고 엄포를 내놓고 있으니 어쩔수가 없다. 그러면 처음부터 정책을 잘 좀 만들던가!

 

나도 Android 10으로 올리면서 MediaStore를 이용해 파일의 경로를 재설정 할 수 있는 연동작업을 진행했는데 너무 빡세서 연동중에 포기하고 requestLegacyExternalStorage 옵션을 키고 기억속에 묻어 뒀었다. 그때 기존 코드를 바꾸는 과정이 고통스러웠던 기억이 아직도 생생한데. 이제는 슬슬 작업을 진행해야 할 것 같다. 나중에는 연동작업에 대해서 다뤄보려고 한다.

728x90