Home/ Questions/Q 9260201
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-18T12:50:01+00:00

For instance, I need a BroadcastReceiver to get these events: REBOOT or SHUTDOWN SCREEN

  • 0

For instance, I need a BroadcastReceiver to get these events:

REBOOT or SHUTDOWN

SCREEN ON or OFF

battery status (voltage, plugged in, temperature)

physical button presses (camera, media, etc.)

But I need Listener to get these events:

EventListener for sensor events (acceleration,magnetic fields, orientation, proximity, temperature, light level, etc.)

LocationListener for location events (Network location, GPS)

It seems like both Receivers and Listeners both exist so that I can receive events. Other than the obvious semantic differences, what are the difference between the two? Are there things I can do in one but not the other, especially in regards to things like how much CPU I can take and running while the screen is off? Why are there two totally different constructs for the purposes of receiving events?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There are so many differences between these two, them responding to something is one of the only similarities.

    Differences:

    • BroadcastReceivers receive Intents whereas a Listener can do basically anything, since it does not have a defined purpose, it’s just a naming convention. Eg, search for “BroadcastReceiver” on the dev website then search for “Listener”

    • BroadcastReceivers just receive an Intent Broadcast which is non-direct, Listeners get called explicitly.

    • A BroadcastReceiver is its own defined class since it has a definite purpose (receiving Intents) whereas Listeners can be anything – they’re usually an interface and they are provided so that callbacks can be made from one class to another.

    • BroadcastReceivers are usually used for global, system-wide events, Listeners for specific events (ie a Location sensor shouldn’t give location updates every second unless it has something, such as a Listener to publish to. Contrasted with a screen-off intent – this is important, it affects everything, and so should be broadcast to all interested Receivers)

    • Events a BroadcastReceiver picks up are usually non-continuous events (one shot), whereas Listeners, depending on what they do, can be used for constant updates (continuous).

    • BroadcastReceivers can be instantiated by the system if they’re declared in the manifest, Listeners are only dynamically made (so via code).

    • CPU/Power usage depends on implementation of both, especially since as mentioned, Listeners can be anything.

    Are there things I can do in one but not the other, especially in regards to things like how much CPU I can take and running while the screen is off?

    BroadcastReceivers only have 10 seconds of guaranteed execution time. Listeners, since they don’t serve a specific purpose, don’t have this limit.

    What you definitely can’t do from a BroadcastReceiver:

    In particular, you may not show a dialog or bind to a service from
    within a BroadcastReceiver.

    There are probably more – this is what I came up with.

    • 0