I’ve registered a BroadcastReceiver in the manifest for android:name=”android.intent.action.MEDIA_BUTTON”
and I’ve registered the receiver with the AudioManager using the registerMediaButtonEventReceiver method. Now my receive function is defined below.
public void onReceive(final Context context, Intent intent) {
Log.e(LOG_TAG, "Entering Receiver");
KeyEvent event = (KeyEvent) intent.getParcelableExtra(Intent.EXTRA_KEY_EVENT);
int action = event.getAction();
if (action == KeyEvent.ACTION_DOWN) {
Log.e(LOG_TAG, "Down");
} else {
Log.e(LOG_TAG, "Up");
}
}
This code just prints when the media button up and down events are logged. If I click fast enough, I’m not able to register all the up events. Do you have any ideas about what is wrong? My LogCat output is below. Just to note, it is possible to reproduce this output by holding the button down, though I am not doing that.
04-24 01:47:38.136: E/MicReceiver(3769): Entering Receiver
04-24 01:47:38.136: E/MicReceiver(3769): Down
04-24 01:47:38.187: E/MicReceiver(3769): Entering Receiver
04-24 01:47:38.187: E/MicReceiver(3769): Down
04-24 01:47:38.257: E/MicReceiver(3769): Entering Receiver
04-24 01:47:38.257: E/MicReceiver(3769): Down
04-24 01:47:38.281: E/MicReceiver(3769): Entering Receiver
04-24 01:47:38.281: E/MicReceiver(3769): Down
04-24 01:47:38.390: E/MicReceiver(3769): Entering Receiver
04-24 01:47:38.390: E/MicReceiver(3769): Down
04-24 01:47:38.402: E/MicReceiver(3769): Entering Receiver
04-24 01:47:38.402: E/MicReceiver(3769): Up
The true question would be, can you guarantee that the system is sending events that you think you are missing (Logcat, etc.)? When a broadcast is fired, it is evaluated by the system for targets and placed in a message queue to be sent to the receiver, so it is unlikely that events created are not being sent to your receiver.
A more likely scenario is that certain events are not being sent because of the frequency with which you are generating them. Many parts of the framework that generate broadcasts send events when the system settles, meaning a new event can cancel a pending broadcast if it comes in before the previous one is sent because that old broadcast no longer represents the system state; the screen on/off broadcast is one example I know of that works this way.
This means you can be guaranteed that you will receive broadcasts that represent the current (latest) state of that particular subsystem even if you didn’t get every intermediate event in between. Notice how your test always ends with an “Up” message.
HTH