Broadcast receiver란 무엇이며 Android 앱에서 어떻게 작동합니까?

Android의 broadcast receiver는 애플리케이션이 다른 애플리케이션이나 시스템 자체에서 보내는 메시지, 즉 “broadcast”를 받고 대응할 수 있게 하는 구성 요소입니다. Broadcast는 기기가 시작될 때, battery 잔량이 바뀔 때, network 연결이 전환될 때처럼 시스템에서 생성될 수 있습니다. Broadcast receiver가 특정 유형의 broadcast에 등록되어 있으면 해당 메시지가 전송될 때 자동으로 활성화됩니다.

Broadcast receiver는 시스템이나 다른 애플리케이션이 보내는 메시지인 특정 intent를 수신하는 방식으로 작동합니다. Broadcast receiver는 intent를 받으면 사용자 interface 업데이트나 작업 예약 같은 짧은 작업을 수행합니다. onReceive()는 main thread에서 실행되어 너무 오래 걸리면 사용자 interface를 막을 수 있으므로 broadcast receiver는 오래 걸리는 작업을 수행할 수 없다는 점에 유의해야 합니다.

Service 같은 다른 구성 요소는 background에서 더 오랜 시간 실행될 수 있습니다. 이에 반해 broadcast receiver는 가볍게 설계되어 짧은 시간 동안만 활성화됩니다. 그래서 불필요한 리소스를 소비하지 않고 시스템 이벤트에 대응하는 효율적인 방법입니다. 즉각적인 반응은 필요하지만 지속적인 process는 필요 없는 이벤트를 처리하는 데 특히 유용합니다.

Broadcast receiver는 두 가지 방식으로 등록할 수 있습니다. 정적 등록에서는 receiver 요소와 어떤 메시지를 수신할지 지정하는 intent filter로 AndroidManifest.xml에 선언합니다. 그러나 Android 8.0부터 대부분의 암시적 시스템 broadcast는 더 이상 이 방식으로 받을 수 없습니다.

동적 등록에서는 receiver를 코드에서 생성하고 registerReceiver로 등록하며, 보통 activity나 service에서 이를 수행합니다. Receiver는 등록되어 있는 동안에만 메시지를 받으며, 더 이상 필요 없을 때 unregisterReceiver로 등록을 해제해야 합니다. Android 14부터는 receiver가 다른 앱의 메시지를 받을 수 있는지 지정해야 합니다.

Android의 broadcast receiver는 여러 유형의 broadcast를 받을 수 있으며, 이는 세 가지 핵심 유형으로 나눌 수 있습니다.

• 시스템 생성 broadcast: 이 broadcast는 다양한 시스템 이벤트에 대응하여 Android 시스템이 보냅니다. 예로는 network 연결이나 battery 잔량의 변화, 기기 부팅 완료가 있습니다. 이러한 broadcast는 background에서 계속 실행되지 않고 시스템 상태 변화에 대응해야 하는 앱에 필수적입니다.
• 앱별 broadcast: 앱은 같은 앱 안의 다른 구성 요소나 다른 앱과 통신하기 위해 자체 broadcast를 보낼 수 있습니다. 이는 file 다운로드 완료나 사용자 login처럼 특정 동작이 완료되었음을 알리는 데 사용할 수 있습니다. 이러한 broadcast는 보통 더 표적화되도록 설계되며, 공개될 수도 있고 앱 자체로 제한될 수도 있습니다.
• 암시적 broadcast: 이 broadcast는 특정 receiver를 대상으로 하지 않고 일반적인 동작을 기반으로 합니다. 예를 들어 예전에는 앱이 새 앱이 설치되었음을 알리는 broadcast를 받도록 등록할 수 있었습니다. Android 8부터 이러한 암시적 broadcast는 대부분 코드에서 등록된 receiver가 필요하며, Android 11부터는 package 가시성 규칙도 어떤 앱이 보이는지 제한합니다. 암시적 broadcast는 앱이 특정 발신자를 알지 못해도 이벤트에 대응할 수 있게 하므로 유연성을 제공합니다.

시스템 생성, 앱별, 암시적 broadcast의 결합으로 broadcast receiver는 시스템과 애플리케이션 수준 모두에서 효율적인 통신과 이벤트 대응을 가능하게 하는 Android의 강력한 메커니즘이 됩니다. 이를 통해 개발자는 사용자 환경과 시스템 환경의 변화에 모두 적응할 수 있는 역동적이고 반응성 있는 앱을 만들 수 있습니다.

Android의 broadcast receiver는 시스템과 애플리케이션 이벤트를 받고 대응하는 강력한 메커니즘입니다. Broadcast receiver를 다룰 때 보안과 올바른 permission 처리를 보장하려면 몇 가지 중요한 측면을 고려해야 합니다.

• 제한된 도달 범위: 다른 앱이 정말로 receiver에 보내야 하는 경우가 아니라면 receiver를 export하지 않아야 하며(manifest의 android_exported=“false” 또는 코드에서 등록할 때 RECEIVER_NOT_EXPORTED), 이는 무단 접근 위험을 줄입니다.
• Permission 사용: AndroidManifest.xml이나 전송 시 필요한 permission을 지정하면 어떤 앱이 특정 broadcast를 보내거나 받을 수 있는지 제어할 수 있습니다. Signature 수준 permission은 같은 key로 서명된 앱만 receiver와 상호 작용할 수 있도록 합니다.
• 명시적 broadcast: 특정 receiver를 대상으로 하는 명시적 intent나 intent에 package 이름을 설정하는 방식은 broadcast를 받을 수 있는 대상을 제한하여 의도하지 않거나 악의적인 수신을 막아 보안을 높입니다.
• Runtime permission: 민감한 작업에는 사용자가 runtime에 명시적으로 permission을 허용하도록 요구할 수 있으며, 이는 사용자가 동작을 인지하고 승인하도록 하여 추가 보안 계층을 더합니다.
• 제한된 데이터: 민감한 데이터는 다른 앱이 받을 수 있는 broadcast로 보내지 않아야 하며, receiver는 필요한 데이터에만 접근해야 합니다.
• 입력 검증: 코드의 logic은 들어오는 broadcast를 검증하고 filter하여 유효하고 예상된 데이터만 처리되도록 해야 합니다.
• LocalBroadcastManager의 대안: 앱 안에서만 broadcast를 보내던 LocalBroadcastManager는 deprecated되었습니다. 내부 애플리케이션 이벤트에는 대신 LiveData나 Kotlin Flow 같은 관찰 가능한 유형 또는 공유 ViewModel이 권장되며, 이렇게 하면 외부 앱이 이러한 이벤트를 가로채거나 보낼 수 없습니다.

전반적으로 제한된 도달 범위, permission 확인, 명시적 broadcast, runtime permission, 제한된 데이터, 입력 검증, broadcast의 앱 내 대안을 결합하면 Android broadcast receiver의 보안과 permission을 효과적으로 처리할 수 있습니다. 이는 애플리케이션을 안전하게 유지하고 무단 접근과 조작에 강하게 만드는 데 도움이 됩니다.

Android의 broadcast receiver는 두 가지 방식으로 등록할 수 있습니다. 바로 정적 등록과 동적 등록입니다. 이 방법들은 용도와 보안상의 영향이 서로 다르며, 애플리케이션에 맞는 접근 방식을 선택하려면 이를 이해하는 것이 중요합니다.

Broadcast receiver의 정적 등록은 AndroidManifest.xml file을 통해 이루어집니다. 여기서 receiver는 애플리케이션 구성의 일부로 정의되므로 애플리케이션이 실행 중이 아닐 때도 broadcast를 받을 수 있습니다. 이는 기기 부팅 완료 같은 이벤트에 유용하지만, Android 8.0부터 network 변경 같은 대부분의 암시적 broadcast는 더 이상 이 방식으로 받을 수 없습니다. Export된 정적 receiver는 다른 앱이 언제든 대상으로 삼을 수 있어, 보호되지 않으면 악성 애플리케이션에 악용될 가능성도 있습니다.

반면 동적 등록은 보통 activity나 service에서 애플리케이션의 코드 안에서 이루어집니다. Receiver는 관련 구성 요소가 실행되는 동안에만 등록되므로 receiver가 활성화되는 시점을 더 잘 제어할 수 있습니다. 동적 등록은 특정 activity가 열려 있는 동안 특정 이벤트를 수신하는 것처럼 일시적인 필요에 이상적입니다. Receiver가 제한된 기간에만 활성화되므로 이 방법은 원치 않는 접근의 위험을 줄입니다.

정적 등록과 동적 등록 사이의 선택은 애플리케이션의 가용성과 보안 요구에 달려 있습니다. 정적 등록은 앱이 실행 중이 아닐 때도 특정 메시지를 받도록 보장하지만 보안 위험을 높일 수 있습니다. 동적 등록은 더 나은 제어와 보안을 제공하지만 broadcast를 받으려면 애플리케이션이 실행 중이어야 합니다.

Broadcast receiver는 애플리케이션이 시스템이나 애플리케이션 이벤트를 수신하고 대응할 수 있게 하는 Android 앱의 필수 구성 요소입니다. 앱에서 broadcast receiver를 사용할 때 성능을 최적화하려면 효율성을 보장하고 불필요한 리소스 소비를 줄이는 몇 가지 모범 사례를 따르는 것이 중요합니다.

성능을 최적화하는 가장 효과적인 방법 중 하나는 가능한 경우 정적 broadcast receiver 대신 동적 broadcast receiver를 사용하는 것입니다. 동적 broadcast receiver는 보통 activity나 service의 코드에서 등록되며, 더 이상 필요 없을 때 등록을 해제할 수 있습니다. 이렇게 하면 시스템이 broadcast를 전달하기 위해서만 앱의 process를 시작하는 일을 막을 수 있으며, receiver가 필요할 때만 활성화되므로 memory, CPU 시간, battery를 절약합니다.

또한 broadcast는 순수하게 앱 내부 통신에 사용하지 않아야 합니다. 예전에는 이를 위해 LocalBroadcastManager를 사용했지만 deprecated되었습니다. LiveData나 Kotlin Flow 같은 관찰 가능한 유형은 broadcast 시스템의 overhead를 완전히 피하고 앱의 반응성을 향상합니다.

또 다른 중요한 최적화는 onReceive() 메서드에서 보내는 시간을 최소화하는 것입니다. Broadcast receiver는 main thread에서 실행되므로 onReceive()의 긴 작업은 사용자 interface를 막고 나쁜 사용자 경험을 초래할 수 있습니다. 이를 피하려면 onReceive()를 빠르게 끝내고, 더 오래 걸리는 작업은 WorkManager에 위임하거나 짧은 비동기 작업이라면 background thread와 결합한 goAsync()에 위임해야 합니다.

마지막으로 battery 소비를 인식하는 것이 중요합니다. 꼭 필요한 경우가 아니라면 자주 발생하는 이벤트에 receiver를 등록하지 않아야 합니다. 기기가 전원에 연결되어 있거나 network 연결이 좋을 때처럼 비동기로 또는 나중에 수행할 수 있는 작업은 JobScheduler나 WorkManager로 처리할 수도 있습니다.

이러한 지침을 따르면 앱은 broadcast receiver를 효율적으로 사용할 수 있으며, 이는 성능과 사용자 경험을 모두 향상합니다.