The CommonsBlog


Allow Overrides of Your Overrides

Alan Zeichick is the conference chair for the AnDevCon series. He uses an Android phone. And he has a complaint.

One of his apps (I didn’t ask which) is some sort of replacement SMS client. It will chirp whenever an SMS arrives, and continue chirping every so often until he reads the message. That part is fine.

However, it will chirp even if he has the phone set to vibrate or mute.

In other words, from his perspective, the app is overriding the device-level volume setting.

This too is fine… as an option. If the user wants this sort of chirping despite having the phone on vibtate or mute, that’s fine.

However, the user should be given a choice about this behavior. As it stands, Alan is frustrated with the app, which he otherwise likes a lot. Frustrated users are unlikely to give you five-star ratings on the Play Store, or recommend your app to others in private conversation, or extol the virtues of your app in front of an audience of Android developers at conferences.

You can see the same behavior with the stock alarm clock app: the alarm rings audibly despite the vibrate/mute setting of the device. However, at least with the alarm clock, you are opting into individual alarms. Users of SMS clients have little control over when SMSes arrive.

This may be purely accidental. Android has the notion of separate audio streams with separate volumes. It may be that Alan’s device’s interpretation of mute/vibrate does not affect the stream that the app is using. That does not change the user perception that the app is at fault, though, as users will only perceive this pain from the app, even if the device or Android is really the culprit. The app developers may need to experiment and give the user the option of which volume to use (e.g., STREAM_RING instead of STREAM_ALARM), so device-level muting works as expected.

Alan’s reaction was (and I’m paraphrasing here), “with an iPhone, when I say ‘mute’, everything mutes”. This is illustrative of the difference between iOS and Android. iOS, more than Android, enforces behavior that Apple feels is appropriate. Android gives developers the option of doing things differently, because there are cases where users would like it if we would “think different”. However, as a result, Android gives developers enough rope to hang themselves and their users… even if Android or the device manufacturers sometimes play the role of the hangman.

If you are doing something that would behave counter to the user’s perception of the current default device configuration — from chiming while muted to running background services — the user needs a choice. The user needs to be able to override the override.


Stuck on an Android problem? Subscribers have access to live office hours chats with Mark Murphy, to help you work through your challenges!