Android/학습

[Android] Android 16 (target SDK 36) 대응

한때미 2026. 3. 14. 16:40

 

이전 버전인 Android 15 대응 날짜를 살펴보면, 아마 Google Play의 기존 앱 Android 16(API 36) 이상 target 대응은 2026년 11월쯤으로 예상된다.

 

Android 15(API 수준 35) 대응은 새 앱 기준 2025년 8월, 기존 앱 기준 2025년 11월로 안내되었다. (관련 출처 페이지)

Android 17(API 수준 37)도 나온 마당에 정말 얼마 남지는 않았을 것이다.

Android 17을 대상으로 하는 앱

대형 화면(sw>=600dp)에서 화면 방향, 크기 조절 가능성 및 화면 비율 제약 조건을 무시하도록 플랫폼 API가 변경되었습니다.
개발자는 SDK 36에서 이러한 변경 사항을 적용하지 않도록 선택할 수 있지만, Android 17 이상을 대상으로 하는 앱에서는 더 이상 이 옵션을 사용할 수 없습니다.

ㅋㅋ 이제 안 봐준다 시전. 어서 화면 재구성 대응 하라고~

 

 

 

우선 진정하고 Android 16 변경사항부터 찬찬히 살펴보자.

 

Android 16 동작 변경 사항

사용자 경험 및 시스텀 UI 변경 사항

보다 일관적이고 직관적인 사용자 경험을 제공하기 위한 변경사항

Edge to edge 대응 필수

Android 15에서 Egde-to-Edge 설정이 강제되었다. 이는 앱이 앱 화면의 가장자리까지 완전히 덮도록 하는 설정이며, Android 15까지는 아직까지 windowOptOutEdgeToEdgeEnforcement 설정으로 이를 적용되지 않게 설정할 수 있었으나, Android 

windowOptOutEdgeToEdgeEnforcement 옵션이 비활성화된다.

 

Android 16 부터는 Edge-to-Edge 설정을 거부할 수 없다.

 

이미지 출처 1)

 

Back 버튼 처리 방식 변경

 

Android 16부터는 Back 버튼 이벤트가 onBackPressed()나 KeyEvent.KEYCODE_BACK로 이벤트가 전달되지 않고, OnBackInvokedCallback 기반 Predictive Back 시스템으로 처리된다.

 

이는, 시스템에서 예측 기반 뒤로 가기 시스템 애니메이션(홈 화면으로 돌아가기, 작업 간 이동, 액티비티 간 이동)이 기본적으로 활성화 되기 때문인데, 이 때문에 개발자는 Back API를 마이그레이션 하는 작업이 필요하다.

 

예측 기반 뒤로가기 시스템 애니메이션

 

움직이는 영상(동영상)은 현재 tistory에서 동영상 첨부를 기능을 삭제했기 때문에 공식 관련 페이지를 첨부한다.. (서버비 때문이라고 한다.)

예측 기반 뒤로가기 시스템 애니메이션

 

 

마이그레이션을 위해서는 AndroidX도 1.6.0-alpaha05 이상으로 업데이트하기 때문에, 해당 라이브러리에 버전업 변경사항도 어서어서 찾아보도록 하자.

 

만약, compose를 사용하고 있다면 navigation-comse 2.8.0+를 사용할 수 있도록 버전업에 대응하도록 하자.

만약 뒤로가기 동작을 가로채서 뒤로 가기 진행률에 대한 커스텀 동작을 하고 있었다면,

Compose도 동일하게 PredictiveBackHandler로 마이그레이션 하는 작업이 필요하다.

 

AndroidX Activity 릴리즈 문서에 따르면 Activity Compose는 PredictiveBackHandler를 제공하고, BackEventCompat의 Flow를 받아 gesture 시작 / 진행 / 취소 / 완료를 다룰 수 있다.

예측 기반 뒤로가기 시스템 애니메이션, Predictive Back이 무엇인가?

Android 13부터 도입된 새로운 Back navigation 시스템으로, 사용자가 뒤로 가기를 할 때

  • gesture 애니메이션이 미리 보임
  • 사용자가 손을 떼면 navigation이 실행됨
뒤로 스와이프
↓
현재 화면 축소
↓
이전 화면 미리 보기
↓
손을 떼면 이동
 

이걸 Predictive Back Animation이라고 한다.

 

물론 이런 영향력이 큰 업데이트에서는 늘 약간의 유예 기간을 주는 설정이 존재하는데, 이번 업데이트도 동일하게 아직까지는 해당 방식으로 적용되지 않게 반영이 가능하다. 다만 이전까지와 행보와 동일하게 조만간 사라지질 않을까 생각한다. ^^

 

android:enableOnBackInvokedCallback attribute to false in the <application> or <activity> tag of your app's AndroidManifest.xml file.

 

Android 16에서는 AndroidManifest.xml에서 android:enableOnBackInvokedCallback 설정을 false로 설정해서 해당 변경 사항을 피할 수 있다.

 

 

(+ 생명주기 호출 변동)

Elegant Font API 사용 중단

 

elegantTextHeight라는 TextView 속성이 더 이상 의미 없어지고(Android 16부터 무시), 시스템이 새로운 UI 폰트 정책으로 통일된다.

Android의 특정 언어(주로 남아시아·동남아시아 문자)의 폰트 렌더링 방식이 바뀌는 것인데,

 

특정 언어들은 문자 구조가 복잡해서 기본 UI 폰트 metrics로는 줄 높이가 부족한 경우가 많았으며,

elegantTextHeight=true를 주면 Elegant font metrics를 사용 가능했다.

 

Compact font 줄 높이가 작은 기본 UI 폰트
Elegant font 줄 높이가 큰 읽기 쉬운 폰트

 

관련 공식 페이지

 

Android 15에서 기본적으로 elegantTextHeight = true 값이 사용되었으며, 현재 Androidj 16에서는 이 elegantTextHeight API 자체가 deprecated 된다는 것이다.

 

즉, android:elegantTextHeight="false" 설정이 이제 더 이상 동작하지 않는 것이다.

 

Android 14(API 레벨 34) 이하를 대상으로 하는 앱 또는 elegantTextHeight 속성을 false로 설정하여 기본값을 재정의한 Android 15(API 레벨 35)를 대상으로 하는 앱의 elegantTextHeight 동작

 

Android 16(API 레벨 36)을 대상으로 하는 앱 또는 elegantTextHeight 속성을 false로 설정하여 기본값을 재정의하지 않은 Android 15(API 레벨 35)를 대상으로 하는 앱의 elegantTextHeight 동작

 

 

핵심 기능

Android 시스템의 다양한 핵심 기능을 수정하거나 확장하는 변경사항

 

scheduleAtFixedRate 동작 변경 (밀린 작업 최대 1개만 실행)

Android 16 이전 동작 앱이 백그라운드 상태라서 task가 실행되지 못했다면 앱이 다시 활성화될 때 밀린 작업을 전부 실행했다.

원래 executor.scheduleAtFixedRate() 동작은 일정 주기를 바탕으로 작업을 실행했는데,

 

예시 실행 구조

executor.scheduleAtFixedRate(
    task,
    0,
    10,
    TimeUnit.SECONDS
)

 

예상 동작: 10s마다 작업을 반복

0s
10s
20s
30s
40s
...

 

 

만약, 앱이 백그라운드 상태라서 task가 실행되지 못했다면 앱이 다시 활성화될 때 밀린 작업을 전부 한 번에 실행했었다. 

0s task 실행
10s task 실행
20s task 실행
30s 앱 background
40s
50s
60s
70s
80s
90s 앱 foreground 복귀

 

즉, 위 상황일 경우 90s에서 밀린 40s부터 90s까지의 작업을 한 번에 실행한다. 해당 부분을 catch-up execution이라고 했다.

40s task 실행
50s task 실행
60s task 실행
70s task 실행
80s task 실행
90s task 실행

 

Android 16에서는 밀린 작업 중 최대 1개만 실행하는 것으로 동작이 변경된다.

90s 복귀
→ task 1번 실행

 

 

ScheduledThreadPoolExecutor.scheduleAtFixedRate()

해당 API를 사용하는 앱은 변경된 동작을 테스트 후 대응이 필요하다.

 

누락되지 않아야 하는 작업을 scheduleAtFixedRate로 처리하고 있었다면, 필히 확인이 필요하다.

 

 

테스트 방식: STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS 플래그 사용

 

장치 폼 팩터 (Device form factors)

대형 화면 기기에서 앱이 표시될 때 다음과 같은 변경 사항이 적용

최소 너비 600에 이상의 화면에서 화면 전환 및 크기 조절, 화면 비율 제한을 무시

Android 16(API 레벨 36)을 대상으로 하는 앱의 경우, 최소 너비가 600dp 이상인 디스플레이에서는 방향, 크기 조절 및 화면 비율 제한이 더 이상 적용되지 않는다. 앱은 화면 비율이나 사용자가 선호하는 방향에 관계없이 전체 디스플레이 창을 채우며, 필러박싱(화면 하단 여백)이 사용되지 않는다.

 

이건 단순하다, 반응형 UI에 대응하며 다중화면에 대응해야 하며, 화면 구성에 대응해야 한다.

화면 너비가 600dp 이상인 기기에서 개발자들이 암암리에 사용하던 세로 모드 고정이 적용되지 않으니 대응하도록 하자.

 

기기 회전을 허용하면 액티비티가 더 많이 다시 생성되는데, 이로 인해 사용자 상태가 제대로 저장되지 않으면 손실될 수 있다.

UI 상태를 올바르게 저장하는 방법은 UI 상태 저장하기를 참조하자.

(화면 재구성에 대한 대응 필수~  ㅎㅎ,, ㅋㅋ,, ㅈㅅ!)

 

안드로이드는 앱이 다양한 화면 방향, 크기 및 화면 비율에 맞춰 조정될 것으로 기대하는 모델로 나아가고 있습니다.

 

직접적으로 경고한 것을 보니, 어서어서 대응하게 앱 구조를 수정하도록 하자.

 

구현 세부 사항

대형 화면 기기에서 전체 화면 및 다중 창 모드에서 다음과 같은 AndroidManifest 속성과 런타임 API는 무시된다.

 

screenOrientation, setRequestedOrientation()와 getRequestedOrientation()에 대한 다음 값은 무시된다.

  • portrait
  • reversePortrait
  • sensorPortrait
  • userPortrait
  • landscape
  • reverseLandscape
  • sensorLandscape
  • userLandscape

 

화면 크기 조절과 관련하여 , android:resizeableActivity="false", android:minAspectRatio와 android:maxAspectRatio는 아무런 영향을 미치지 않게 된다.

 

 

예외

안드로이드 16의 화면 방향, 크기 조절 및 화면 비율 제한은 다음과 같은 상황에서는 적용되지 않는다고 한다.

  • (android:appCategory국기를 기반으로 한) 게임
  • 사용자가 기기의 화면 비율 설정에서 앱의 기본 동작을 명시적으로 선택하는 경우
  • 화면보다 작은 sw600 dp

 

해당 설정을 적용하지 않기 위한 유예 설정이 존재하며, 참고적으로 Android 17에서 바로 제거되는 설정이다.. ^^

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>
<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

 

 

건강 및 체력

건강 및 피트니스 데이터와 관련된 변경 사항

건강 및 피트니스 관련 센서 권한 변경

Android 16(API 레벨 36) 이상을 대상으로 하는 앱의 경우, Health Connect 권한에서도 사용하는 것처럼 BODY_SENSORS보다 세분화된 권한 설정을 사용한다.

 

Android 16부터는 이전에 또는 권한을 요구했던 모든 API는 이제 해당 권한을 요구한다.

이는 다음과 같은 데이터 유형, API 및 포그라운드 서비스 유형에 영향을 미친다.

  • android.permissions.health
  • BODY_SENSORS
  • BODY_SENSORS_BACKGROUND
  • android.permissions.health

 

앱에서 이러한 API를 사용하는 경우, 각각에 대한 세부적인 권한을 요청해야 한다.

이러한 권한은 건강, 피트니스 및 웰빙 데이터를 저장하는 안드로이드 데이터 저장소인 Health Connect 에서 데이터를 읽을 때 필요한 접근 권한과 동일하다.

 

AS-IS: 이전 (Android 15 이하)

<uses-permission android:name="android.permission.BODY_SENSORS" />
<uses-permission android:name="android.permission.BODY_SENSORS_BACKGROUND" />

하나의 권한으로 여러 건강 데이터 접근

 

TO-BE: Android 16 (API 36+)

<uses-permission android:name="android.permission.health.READ_HEART_RATE" />
<uses-permission android:name="android.permission.READ_HEALTH_DATA_IN_BACKGROUND" />

데이터 종류별로 권한 분리, 권한 세분화

 

건강(health) 데이터 권한을 사용하는 앱은 “앱 내부에 개인정보 처리방침 화면(Activity)”을 반드시 제공

 

READ_HEART_RATE 세부적인 권한 설정을 사용하도록 전환하는 모바일 앱은 앱의 개인정보 보호정책을 표시하는 액티비티를 선언해야 한다. 이는 헬스 커넥트(Health Connect)와 동일한 요구 사항이다.

 

⚠️ 중요: 모바일 앱에 대한 접근 권한 부여 사유를 제공하지 않을 경우 권한이 취소될 수 있습니다.

 

 

즉, Android 16부터 건강 센서 권한이 BODY_SENSORS → android.permission.health.*로 세분화되고, 동시에 “앱 내부 개인정보처리방침(Activity)” 제공이 필수 조건이 되는 것이다.

(정책적으로 대응하는 것)

 

연결성

주변 장치와의 연결성을 개선하기 위해 Bluetooth 스택에 변경 사항

 

Android 16 부터는 원격 연결(Bluetooth)에 대한 사용성 개선을 위해 2가지의 새로운 Intent가 도입되었다.

 

 원견 연결 끊김과 암호화 변경 사항을 처리하기 위한 새로운 Intent

  • ACTION_KEY_MISSING 원격 연결 끊김이 감지되면 의도를 수신한다.
    • 사용자가 더 자세한 피드백을 제공하고 적절한 조치를 취할 수 있도록 합니다.
  • ACTION_ENCRYPTION_CHANGE 링크의 암호화 상태가 변경될 때마다 인텐트를 수신합니다 .
    • 여기에는 암호화 상태 변경, 암호화 알고리즘 변경 및 암호화 키 크기 변경이 포함됩니다.
    • 앱은 ACTION_ENCRYPTION_CHANGE 나중에 인텐트를 수신했을 때 링크가 성공적으로 암호화되어 있으면 연결이 복원된 것으로 간주해야 한다.

 

단, Android 16 OS에서는 해당 Intent가 추가되었지만, 구현 방식과 브로드캐스트 방식은 기기 제조업체(OEM)에 따라 다를 수 있다고 명시되어 있다.

(역시.. 골치 아픈 Bluetooth)

 

모든 기기에서 일관되고 안정적인 앱 환경을 제공하려면 개발자는 연결 끊김 처리 방식을 설계할 때 이러한 잠재적 차이에 유연하게 대응하도록 해야 하며, 다음과 같은 앱 동작을 권장한다.

  • ACTION_KEY_MISSING intent가 전달된 경우:
    • 앱은 이 인텐트를 연결 끊김 감지의 주요 신호로 사용해야 한다. 사용자가 원격 장치가 범위 내에 있는지 확인한 후 장치 연결을 해제하거나 다시 페어링 하도록 안내해야 한다.
      • 기기 연결이 ACTION_KEY_MISSING 수신된 후 연결이 끊어지면, 해당 기기가 더 이상 시스템과 연결되어 있지 않을 수 있으므로 앱은 재연결 시 주의해야 한다.
      • ACL(비동기 연결 없음) 링크는 시스템에 의해 연결이 끊어지지만, 장치에 대한 연결 정보는 유지된다(여기에 설명된 대로).
  • ACTION_KEY_MISSING intent가 전달되지 않는 경우:
    • 이 시나리오에서는 앱이 이전 Android 버전(Android 15 이하)과 마찬가지로 원격 연결 손실 처리 메커니즘을 계속 사용하여 원격 연결 손실 이벤트를 감지하고 관리해야 한다.
    • ACL 링크는 연결된 상태로 유지되며, 시스템에 의해 해당 장치의 본드 정보가 제거된다. 이는 안드로이드 15에서의 동작과 동일하다.

블루투스 연결을 해제하는 새로운 방법

 

Android 16을 대상으로 하는 모든 앱은 이제 공개 API(CompanionDeviceManager)를 사용하여 블루투스 장치 연결을 해제할 수 있다.

 

컴패니언 장치(Companion Device)가 CDM(CompanionDeviceManager) 연결로 관리되는 경우, 앱은 연결된 장치에서 새 API(removeBond(int))를 사용하여 블루투스 연결 해제할 수 있게 되는 것이다.

 

앱은 블루투스 장치의 ACTION_BOND_STATE_CHANGED 브로드캐스트 이벤트를 수신하여 연결 상태 변경을 모니터링할 수 있다.

 

Android 15 이하에서는 이러한 앱이 Bluetooth bond를 제거하려면 공식적인 API가 존재하지 않아 만약 하려면, reflection hack 방식으로 해제하여, 안정성 문제와 OEM 차이, Play 정책 리스크 문제가 있었으나, 이 부분을 공식적으로 지원하게 되는 것이다.

 

보안

보안 변경 사항

MediaStore.getVersion() 암호화

Android 16 이상을 대상으로 하는 앱의 경우, MediaStore#getVersion() 정보는 이제 앱마다 고유하게 생성된다.

 

val version = MediaStore.getVersion(context)

해당 API는 Media DB 상태가 변경됐는지 확인할 수 있으며, 사진/영상 목록 캐싱할 때 사용해 왔다. (version 바뀌면 다시 조회)

Android 15이하 버전까지는 해당 값이 디바이스 공통 값이 존재하며 특정 패턴 있었기 때문에, MediaStore version 분석해 OS 상태 추론하여 device fingerprinting이 가능했다.
 
version prefix로 vendor 추측하고 변경 타이밍으로 사용자 행동 추적할 수 있었던 것이다.
 

하지만 이번 Android 16 버전 이상에서 해당 부분이 보완되어 문자열에서 식별 속성을 제거하여 악용 및 앱 핑거프린팅 기법에 사용되는 것을 방지하는 것이다.

앱은 이 버전 정보의 형식에 대해 어떠한 추측도 해서는 안 된다. 앱은 이미 이 API를 사용할 때 버전 변경을 처리해야 하며, 대부분의 경우 개발자가 이 API의 의도된 범위를 넘어서는 추가 정보를 추론하려고 시도하지 않는 한 현재 동작을 변경할 필요가 없다.
 

 

Safer Intents 기능 업데이트

Safer Intents 기능은 안드로이드의 인텐트(Intent) 해석 메커니즘의 보안을 강화하기 위해 설계된 여러 단계의 보안 개선 계획이다.

이 기능의 목표는 인텐트 처리 과정에서 검사를 추가하고 특정 기준을 충족하지 않는 인텐트를 필터링하여 악의적인 행위로부터 앱을 보호하는 것이다.

 

안드로이드 15에서는intent를 보내는 앱에 초점을 맞췄지만, 안드로이드 16부터는 제어권이 받는 앱으로 옮겨가 개발자가 앱 매니페스트를 사용하여 인텐트 수신을 좀 더 엄격하게 선택적으로 활성화할 수 있게 되었습니다

 

Intent 보안 모델이 “수신 앱 중심”으로 강화된 것이다.

 

  1. 명시적 intent는 대상 구성 요소의 intent-filter와 일치해야 합니다. intent가 구성 요소를 명시적으로 대상으로 하는 경우에도 해당 구성 요소의 intent-filter와 일치해야 한다.
  2. Action이 지정되지 않은 인텐트는 어떤 intent-filter와도 일치할 수 없다. Action이 지정되지 않은 인텐트는 어떤 intent-filter로도 해석되어서는 안 된다.
이러한 변경 사항은 여러 앱이 관련된 경우에만 적용(다른 앱과 Intent 통신)되며, 단일 앱 내의 인텐트 처리(앱 내의 Intent 교환)에는 영향을 미치지 않는다.

 

즉, Safer Intents 기능을 사용할 경우 명시적 Intent일지라도, Intent라면 intent-filter를 꼭 명시하고, Action을 꼭 명시해야 하는 것이다.

 

Android 16의 Safer Intents는 기본 OFF(Opt-in)이고, 개발자가 Manifest에서 켜야만 “엄격한 Intent 매칭 규칙”이 적용된다.

👉 자세한 Safer Intents 기능 및 활성화 방법

 

GPU 시스템 호출 필터링

Mali GPU의 보안을 강화하기 위해, 더 이상 사용되지 않거나 GPU 개발 용도로만 사용되는 Mali GPU IOCTL은 프로덕션 빌드에서 차단되었다. 또한, GPU 프로파일링에 사용되는 IOCTL은 셸 프로세스 또는 디버깅 가능한 애플리케이션으로 제한된다.

(플랫폼 수준 정책에 대한 자세한 내용은 SAC 업데이트를 참조)

 

Android에서 GPU는 커널 드라이버를 통해 동작하고, 그 드라이버와 통신할 때 IOCTL(system call)을 사용한다.

앱 → 그래픽 API(OpenGL/Vulkan) → GPU driver → IOCTL (저수준 커널 호출)

일반 앱은 IOCTL을 직접 쓰지 않지만, 루팅/익스플로잇/디버깅 툴은 IOCTL을 직접 하용하게 되는데,

Android 16에서 Mali GPU 드라이버의 저수준 IOCTL(syscall)을 일부 차단해서, 앱이 GPU를 직접 건드리는 걸 막는 보안 강화 업데이트이다.

 

일반적인 앱(OpenGL/Vulkan)은 영향이 없다.

이번 변경 사항은 지원되는 그래픽 API(Vulkan 및 OpenGL 포함)에는 영향을 미치지 않으며, 개발자나 기존 애플리케이션에도 영향을 주지 않을 것으로 예상됩니다. Streamline Performance Analyzer 및 Android GPU Inspector와 같은 GPU 프로파일링 도구도 영향을 받지 않습니다.

 

SELinux 거부 메시지가 표시되면 해당 애플리케이션이 이번 변경 사항의 영향을 받았을 가능성이 높다. (더 자세한 내용)

은닉 (Privacy)

개인정보 보호 변경 사항

로컬 네트워크 권한 제한

LAN에 연결된 기기는 INTERNET권한이 있는 모든 앱에서 접근할 수 있었다. 이는 앱이 로컬 기기에 쉽게 연결할 수 있도록 해주지만, 사용자의 개인 정보를 수집하거나 위치 정보를 대신 파악하는 등의 개인정보 침해 문제도 야기할 수 있다.

 

로컬 네트워크 보호 프로젝트는 새로운 런타임 권한 설정을 통해 로컬 네트워크 접근을 제한함으로써 사용자의 개인 정보를 보호하는 것을 목표로 한다.

릴리스 계획

이 변경 사항은 25Q2와 26Q2 두 릴리스 사이에 배포될 예정이다. 개발자는 25Q2 릴리스에 대한 이 지침을 반드시 준수하고 피드백을 공유해야 한다. 이러한 보호 조치는 향후 Android 릴리스에서 강제 적용될 예정이기 때문에, 개발자는 다음 지침에 따라 암묵적인 로컬 네트워크 액세스에 의존하는 시나리오를 업데이트하고, 사용자가 새로운 권한을 거부하거나 철회할 경우에 대비해야 한다.

 

즉, LAN 연결 방식에 대한 보안 강제 업데이트가 예정되어 있으니 대비하라는 의미이다.

 

프라이버시(사용자 식별/위치 추론) 보호 목적으로, 이제 INTERNET만으로는 같은 Wi-Fi(LAN)에 있는 기기들에 접근 못 하게 하고, 별도의 “Local Network 런타임 권한”을 요구하려는 변화이다.

 

 

현재 LNP는 선택 사항 기능이므로, 해당 기능을 사용하기로 선택한 앱에만 영향을 받는다.

  • 로컬 네트워크 주소에서 원시 소켓을 직접 또는 라이브러리를 통해 사용하는 경우(예: mDNS 또는 SSDP 서비스 검색 프로토콜)
  • 로컬 네트워크에 접근하는 프레임워크 수준 클래스 사용(예: NsdManager)

👉 영향받는 앱과 대응 방식에 대한 자세한 내용

 

"선택된 사진만 허용" 권한에서의 동작 변경

Android 16 이상에서 실행되는 기기에서 SDK 36 이상을 대상으로 하는 앱(즉, Android 16 대응 앱부터)이 사진 및 비디오 권한을 요청할 때, 사용자가 특정 미디어에 대한 접근을 제한하도록 선택하면 앱이 소유한 사진이 사진 선택기에서 미리 선택된 상태로 표시된다.

사용자는 이러한 미리 선택된 항목을 선택 해제할 수 있으며, 그렇게 하면 해당 사진 및 비디오에 대한 앱의 접근 권한이 취소된다.

최근 Android에서 사진 접근 권한에 대해서 다음과 같은 선택 사항이 추가되었다.

전체 허용 ❌
선택된 사진만 허용 ⭕ (Selected Photos Access)

 

즉, 사용자가 특정 앱에서 접근할 수 있는 사진을 직접 고를 수 있게 변경되었는데,

 

예외 상황으로 앱이 만든 사진도 못 보는 상황이 생겼었다.

이미지로 저장 기능이 있는 앱→ 이미지로 저장→ (현재 권한)"선택된 사진만"→ 사용자가 해당 이미지를 선택 안 한 상태

 

현재 앱이 스스로 생성한 사진도 접근하지 못하는 상황이 생기는 것이다.

이로 인해 Android 16에서는 app-owned photos = 자동 선택으로 바뀌는 것이다.

 

즉, "선택된 사진만" 권한을 가진 앱도 스스로 생성한 사진은 접근이 가능

 

 

 

 

 

이렇게 Android 16 동작 변경사항에 대해 알아보았다.

 

해당 내용을 바탕으로 Android 16 대응을 할 때 추가적으로 참고하면 좋을 공식 페이지를 남기면서 이야기를 끝내겠다.

다들 파이팅 하고 힘내서 민첩한 개발자가 되세요.

 

 

https://developer.android.com/work/versions/android-16?hl=ko

 

Android 16의 새로운 엔터프라이즈 기능  |  Android Enterprise  |  Android Developers

Android 16의 엔터프라이즈 개발자 및 관리자를 위한 새로운 기능입니다.

developer.android.com

 

https://developer.android.com/about/versions/16/summary?hl=ko

 

Android 16 기능 및 변경사항 목록  |  Android Developers

이 문서에서는 앱 개발자에게 영향을 미칠 수 있는 Android 16의 문서화된 모든 기능과 동작 변경사항을 요약하여 제공합니다.

developer.android.com

 

 

추가적으로 알아보면 좋은 부분

  • Predictive Back의 생애주기 호출 차이
  • 반응형 레이아웃
  • 화면 구성 변경 대응

 

참고 자료

 

이미지 출처

'Android > 학습' 카테고리의 다른 글

[Android] 실전 예제로 보는 MVP Pattern의 장단점  (0) 2026.04.12
[Android] targetSdk와 compileSdk의 차이, 그에 따른 영향.  (0) 2026.02.22
[CS] "부동소수점"이란? 컴퓨터에서 소수를 표현하는 방법과 그에 따른 오차  (0) 2026.02.07
[kotlin] by로 보는 지연 초기화 by lazy 컴파일러 동작 방식  (0) 2026.01.10
[Firebase] Remote Config, 어떻게 사용하고 왜 사용하는가?  (0) 2025.11.29

'Android/학습'의 다른글

  • 현재글[Android] Android 16 (target SDK 36) 대응

관련글

댓글

티스토리툴바