TelephonyManager.listen() Deprecated!

TelephonyManager.listen() Deprecated! TelephonyCallback으로 마이그레이션하기 (Java)

Android SDK를 최신 버전으로 업데이트하면 Android Studio에서 다양한 Deprecated 경고를 볼 수 있다.

그중 하나가 바로 TelephonyManager.listen() 이다.

기존에는 전화 상태나 데이터 연결 상태 등을 확인하기 위해 대부분 PhoneStateListener와 listen() 메서드를 사용했다.

하지만 Android 12(API 31)부터는 TelephonyCallback 사용이 권장되며, 최신 SDK에서는 listen() 메서드가 Deprecated로 표시된다.

이번 글에서는 기존 코드를 TelephonyCallback으로 변경하는 방법과 실제 적용하면서 주의했던 점을 정리해 보려고 한다.

왜 변경해야 할까?

기존 방식은 다음과 같았다.

TelephonyManager telephonyManager =
        (TelephonyManager) getSystemService(TELEPHONY_SERVICE);

telephonyManager.listen(
        phoneStateListener,
        PhoneStateListener.LISTEN_CALL_STATE
);

이 방식은 오랫동안 사용되어 왔지만 Android 12(API 31)부터 Deprecated 되었다.

Google에서는 기능별 Callback 인터페이스를 사용하는 TelephonyCallback 방식으로 변경할 것을 권장하고 있다.

SDK 36으로 변경하더라도 기존 코드가 바로 동작하지 않는 것은 아니지만, 앞으로의 호환성을 위해서는 변경하는 것이 좋다.

기존 PhoneStateListener 코드

예를 들어 전화 상태를 감시하는 코드는 다음과 같다.

PhoneStateListener listener =
        new PhoneStateListener() {

    @Override
    public void onCallStateChanged(int state, String phoneNumber) {

        switch (state) {

            case TelephonyManager.CALL_STATE_IDLE:

                break;

            case TelephonyManager.CALL_STATE_RINGING:

                break;

            case TelephonyManager.CALL_STATE_OFFHOOK:

                break;

        }

    }

};

그리고 등록은 다음과 같이 수행했다.

telephonyManager.listen(
        listener,
        PhoneStateListener.LISTEN_CALL_STATE
);

TelephonyCallback으로 변경하기

먼저 Callback 클래스를 생성한다.

private class CallStateCallback extends TelephonyCallback
        implements TelephonyCallback.CallStateListener {

    @Override
    public void onCallStateChanged(int state) {

        switch (state) {

            case TelephonyManager.CALL_STATE_IDLE:

                break;

            case TelephonyManager.CALL_STATE_RINGING:

                break;

            case TelephonyManager.CALL_STATE_OFFHOOK:

                break;

        }

    }

}

Callback 등록

등록 방법도 변경되었다.

기존에는

telephonyManager.listen(...)

을 사용했지만

이제는

telephonyManager.registerTelephonyCallback(
        getMainExecutor(),
        callback
);

을 사용한다.

예를 들면

CallStateCallback callback = new CallStateCallback();

telephonyManager.registerTelephonyCallback(
        getMainExecutor(),
        callback
);

Executor를 반드시 전달해야 한다는 점이 기존 방식과 가장 큰 차이점이다.

Callback 해제

Activity가 종료될 때는 Callback도 반드시 해제해야 한다.

telephonyManager.unregisterTelephonyCallback(callback);

보통은

onDestroy()

또는

onStop()

에서 해제하는 경우가 많다.

Android 11 이하도 함께 지원해야 한다면?

많은 프로젝트는 아직 minSdk가 23 또는 24이다.

때마침, 현재 작업하고 있는 프로젝트는 minSdk가 23으로 설정되어 있다.

이 경우에는 API 레벨에 따라 분기 처리를 해야 한다.

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {

    telephonyManager.registerTelephonyCallback(
            getMainExecutor(),
            callback
    );

} else {

    telephonyManager.listen(
            listener,
            PhoneStateListener.LISTEN_CALL_STATE
    );

}

이렇게 하면 Android 12 이상에서는 새로운 API를 사용하고, 이전 버전에서는 기존 코드를 사용할 수 있다.

실제 적용하면서 겪었던 문제

1. Executor를 전달해야 한다

기존에는 단순히 listen()만 호출하면 되었지만

새로운 API는 Executor가 필요하다.

대부분의 Activity에서는

getMainExecutor()

를 사용하면 된다.

2. Callback 해제를 잊기 쉽다

등록만 하고

unregisterTelephonyCallback()

를 호출하지 않으면 메모리 누수가 발생할 수 있다.

Lifecycle에 맞춰 반드시 해제하는 것이 좋다.

3. 권한을 다시 확인해야 한다

전화 상태를 읽으려면

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

권한이 필요하다.

Android 6.0 이상에서는 런타임 권한도 함께 요청해야 한다.

4. 전화번호는 대부분 얻을 수 없다

예전에는

SubscriptionInfo.getNumber()

등을 이용하여 전화번호를 가져오는 경우가 있었다.

하지만 최신 Android에서는 개인정보 보호 정책 때문에 대부분의 일반 앱은 실제 전화번호를 얻을 수 없다.

통신사 앱이나 시스템 앱이 아니라면 null이 반환되는 경우가 많다.

따라서 전화번호를 이용하는 로직이 있다면 다른 방식으로 변경하는 것을 고려해야 한다.

변경 전후 비교

기존 방식

새로운 방식

PhoneStateListener

TelephonyCallback

listen()

registerTelephonyCallback()

LISTEN_* 플래그

Callback 인터페이스

Executor 없음

Executor 필요

listen(…, LISTEN_NONE)

unregisterTelephonyCallback()

마이그레이션 체크리스트

SDK를 변경할 때는 다음 항목을 확인하는 것을 추천한다.

  • TelephonyManager.listen() 검색
  • PhoneStateListener 검색
  • LISTEN_* 플래그 검색
  • TelephonyCallback으로 변경
  • Callback 해제 추가
  • Runtime Permission 확인
  • Android 12 이상 실기기 테스트

마무리

TelephonyManager.listen()은 아직 완전히 제거된 것은 아니지만 이미 Deprecated 상태이다.

새로운 프로젝트라면 처음부터 TelephonyCallback을 사용하는 것이 좋으며, 기존 프로젝트도 SDK를 업데이트하는 시점에 함께 마이그레이션하는 것을 추천한다.

이번 프로젝트에서는 API 레벨에 따라 분기 처리하여 Android 12 이상에서는 TelephonyCallback, 그 이하에서는 기존 PhoneStateListener를 사용하도록 변경하였다.

덕분에 기존 기능은 유지하면서 최신 SDK에서도 Warning 없이 빌드할 수 있었다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

Android SDK 36 대응 - Edge-to-edge 예외 설정이 더 이상 동작하지 않는 이유와 해결 방법

  Android SDK 36 대응 - Edge-to-edge 예외 설정이 더 이상 동작하지 않는 이유와 해결 방법 Android SDK 35에서 SDK 36으로 마이그레이션하면서 가장 먼저 확인했던 부분 중 하나는 Edge-to-edge 설정이었다. 처음에는 Android 16에서 Edge-to-edge가 새롭게 적용되는 줄 알았지만, 공식 문서를 다시 확인해 보니 실제 변경 사항은 조금 달랐다. Edge-to-edge 자체는 이미 Android 15(API 35)부터 기본 적용되었다. Android 16(API 36)에서는  Edge-to-edge를 임시로 비활성화하기 위해 사용하던 예외 설정이 더 이상 동작하지 않는다. 이번 글에서는 이 변경 사항이 무엇인지, 어떤 프로젝트가 영향을 받는지, 그리고 어떻게 대응해야 하는지 정리해 보려고 한다. Edge-to-edge는 SDK 36에서 새롭게 추가된 기능이 아니다 많은 글에서 “Android 16부터 Edge-to-edge가 적용된다”고 설명하지만, 이는 정확하지 않다. 실제로 Edge-to-edge는  Android 15(API 35)  에서 targetSdkVersion 35 이상을 대상으로 기본 적용되었다. 즉 Android 14 이하 → 기존 방식 Android 15(API 35) → Edge-to-edge 기본 적용 Android 16(API 36) → 기존 예외 설정 제거 이것이 가장 큰 차이점이다. 문제가 되는 설정은 무엇인가? Android 15 대응 당시 많은 프로젝트에서는 Theme에 다음 속성을 사용하여 기존 화면을 유지했다. <item name="android:windowOptOutEdgeToEdgeEnforcement">true</item> 이 설정을 사용하면 Window Insets 처리를 하지 않아도 기존처럼 화면을 표시할 수 있었다. 예를 들면 <style name="AppTheme" parent="Theme...
자세한 내용 보기

Android SDK 35 → 36 마이그레이션에서 실제 수정한 항목 7가지

Android SDK 35 → 36 마이그레이션에서 실제 수정한 항목 7가지 Android 프로젝트를 운영하다 보면 매년 새로운 Target SDK 대응 작업을 하게 된다. 하지만 모든 SDK 업데이트가 대규모 수정을 요구하는 것은 아니다. Android 15(API 35)는 Edge-to-edge가 기본 적용되는 등 UI 측면에서 큰 변화가 있었던 반면, Android 16(API 36)은 기존 정책을 강화하고 일부 API의 동작을 변경하는 수준의 업데이트가 많다. 이번 프로젝트에서는 기존 Android SDK 35 기반 앱을 SDK 36으로 마이그레이션했다. 생각보다 수정해야 할 부분은 많지 않았지만, 몇 가지는 반드시 확인해야 하는 항목들이 있었다. 이 글에서는 실제로 SDK 36 대응 과정에서 확인했던 주요 수정 사항들을 정리해 보려고 한다. 개발 환경 마이그레이션 전후 환경은 다음과 같다. 항목 변경 전 변경 후 compileSdk 35 36 targetSdk 35 36 minSdk 23 23 언어 Java Java 프로젝트는 Java 기반의 일반적인 Android 애플리케이션이며, WebView와 다양한 시스템 API를 사용하고 있다. 1. Edge-to-edge 예외 설정 제거 여부 확인 가장 먼저 확인한 것은 Edge-to-edge였다. 처음에는 SDK 36에서 새롭게 적용된 정책이라고 생각했지만, 다시 확인해 보니 Edge-to-edge는 이미 Android 15(API 35)부터 기본 적용되어 있었다. SDK 36에서 달라진 점은 기존에 사용하던 Edge-to-edge 예외 설정이 Android 16에서는 더 이상 동작하지 않는다는 것이다. 예를 들어 다음과 같은 설정으로 기존 레이아웃을 유지했던 프로젝트라면 반드시 확인이 필요하다. <item name="android:windowOptOutEdgeToEdgeEnforcement">true</item> 이 속성은 Android 16에서 더 이상 효과가 없...
자세한 내용 보기

Android Predictive Back 적용하기

  Android Predictive Back 적용하기 - 기존 onBackPressed() 코드에서 무엇을 수정해야 할까? Android SDK를 35에서 36으로 마이그레이션하면서 가장 먼저 확인했던 항목 중 하나가 바로  Predictive Back 이었다. 처음에는 Android 16(API 36)에서 새롭게 추가된 기능이라고 생각했지만, 실제로는 Android 13(API 33)부터 도입된 기능이다. 다만 SDK를 최신 버전으로 올리면서 기존 Back 버튼 처리 방식과 충돌하는 코드가 없는지 반드시 확인해야 한다. 이번 글에서는 Predictive Back이 무엇인지, 기존 프로젝트에서 어떤 부분을 수정해야 하는지, 그리고 실제 프로젝트에서는 어떻게 대응했는지 정리해 보려고 한다. Predictive Back이란? Predictive Back은 사용자가 뒤로 가기 제스처를 수행하는 동안  다음 화면으로 어떻게 이동할지 미리 보여주는 시스템 애니메이션 이다. 기존에는 뒤로 가기 버튼이나 제스처를 수행하면 즉시 이전 화면으로 이동했다. 하지만 Predictive Back에서는 사용자가 화면 가장자리에서 스와이프하는 순간부터 이전 화면이 미리 보이기 시작한다. 덕분에 사용자는 뒤로 가기를 수행하기 전에 어떤 화면으로 이동하는지 확인할 수 있다. 왜 기존 코드가 문제가 될 수 있을까? 예전 Android 프로젝트에서는 대부분 다음과 같은 방식으로 Back 버튼을 처리했다. @Override public void onBackPressed() { finish(); } 또는 @Override public boolean onKeyDown(int keyCode, KeyEvent event) { if (keyCode == KeyEvent.KEYCODE_BACK) { finish(); return true; } return super.onKeyDown(keyCode, event); } 이...
자세한 내용 보기