안드로이드 버전 4... 그러니까 킷캣부터 SD 카드 액세스를 막겠다는 구글의 정책으로 인해 많은 앱들이 망테크를 탔(물론 제 모 앱도 ...)다는 이야기는 유명합니다. 이로 인해 너무 자유도가 줄어들었다는 판단이 선 구글은 결국 v4.4부터 다시 SD 카드로 접근할 수 있는 수단, 즉 SAF(Storage Access Framework)를 내놓게 됩니다.
원리는 다음과 같다고 공식 문서에 씌여 있네요. 여기서는 간단히 사진만 몇장 퍼오고 설명하는 걸로 끝낼테니 구체적인 건 직접 ...
- file picker intent를 띄워서 파일을 선택하게 함
- 내부적인 COLUMN_DOCUMENT_ID를 통해 각 파일이 식별되고(일종의 file descriptor인 셈) 이를 통해 파일 접근.
- Picker UI는 다양한 Provider을 통해 다양한 종류의 파일을 엑세스 할 수 있게 만듬 (usb건 sd카드이건 cloud 폴더이건)
오 좋네요, 사실 진작에 지원되었어야 하는 것이지만 자체 내장 파일 탐색기 좋아요 좋아. 게다가 내부 스토리지 말고 클라우드 폴더도 쉽게 지원하는 건 더 좋은 것.
그런데 이 방식의 특징이 있습니다.
- File 대신 사용될 ParcelFileDescriptor / AssetFileDescriptor 모두 표준 java 제공 API가 아닌 google 자체 API이다.
- low-level (stream / fd)에서의 I/O가 강요된다.
[1]과 [2] 모두 java의 강점을 약화시킬 뿐더러 호환성도 약화시키는 아주 큰 요인이라고 생각합니다. 그냥 제 라이브러리가 먹통이 된 것도 있지만 (...) java의 file descriptor의 강점은 쉽게 input/output stream을 관리하고 사용할 수 있게 추상화시켜놓은 것에 있는데 이를 C언어마냥 stream으로 관리하게 강요하고, 이로 인해 기존 File을 사용하는 라이브러리들은 크게 구조를 바꾸지 않으면 사용 불가능한 상황이 발생합니다. 사실상 android-dependent하지 않은 라이브러리들의 경우는 stream을 input/output으로 받아야 하니까 훨씬 불편한 건 덤.
이를 해결하기 위해서는 아마 File object를 대체하는 별개의 stream 관리 class를 만들어야 하지 않을까... 생각하는데, 그냥 File object를 던져주도록 만드는 API도 좀 ...
보안을 위해 샌드박스를 놓은 건 좋은데 이번 API 디자인은 이 부분이 마음에 들지 않아서 그냥 똥글 하나 싸재낍니다. 사실 i/o stream을 라이브러리가 지원하는 게 디자인적으로 3g 정도 더 맞긴 한 것 같지만. 그냥 뭐, 나중에 시간이 나면 제가 라이브러리를 뜯어 고치는 게 낫겠네요. 오래 전에 만들어진 File 객체보고 '너 왜 cloud storage 지원 안해서 이렇게 불편하게 만들어!' 라고 호통칠 수도 없고 =_=)...
PS. 아마 안 될 것 같긴 하지만(실험 안 해봄), IO 권한이 fd가 아닌 filepath단위로 주어진다면 제가 쓴 글은 완전 똥글이 되는 겁니다.
'개발 > Developing' 카테고리의 다른 글
| [C++] template에서 rvalue reference로 파라미터 받기? (0) | 2018.09.14 |
|---|---|
| 객체지향 프로그래밍 (0) | 2017.01.04 |
| aheui 그리고 sugar syntax (5) | 2014.04.08 |
| negative number들의 radix sort (2) | 2013.05.14 |
| 기존의 libtwitcurl이 토큰 및 인증 관련하여 제대로 작동하지 않던 문제에 대해서. (9) | 2013.03.08 |