I have an Android application for a Samsung tablet that uses an external device which draws its power from the tablet headphone jack. When the external device is powered on (by programmatically maxing out the volume), Android briefly displays a warning popup saying: "Loud music may harm your hearing if you listen to it for too long..." I would like that message to not be displayed.
Here's the offending line of code:
mAudioMgr.setStreamVolume(AudioManager.STREAM_MUSIC, mAudioMgr.getStreamMaxVolume(AudioManager.STREAM_MUSIC), 0);
It's not an option to only turn it up halfway. In fact, I've seen the tablet display the warning (when changing the volume by hand) even on volume settings lower than the max setting.
And yes, I record the original volume, and restore it when we're done with the external device.
Thanks for any suggestions.
Since you cannot disable the systems message, and you will also have a problem when the user manually lowers the volume, I suggest you do a series of controls which will help with that.
To max the volume:
public void maxVolume() {
AudioManager audioManager = (AudioManager)context.getSystemService(this.AUDIO_SERVICE);
while ( audioManager.getStreamVolume(AudioManager.STREAM_MUSIC) < audioManager.getStreamMaxVolume(AudioManager.STREAM_MUSIC)) {
audioManager.adjustStreamVolume(AudioManager.STREAM_MUSIC, AudioManager.ADJUST_RAISE, 0);
}
}
To prevent users from manually changing volume:
#Override
public boolean onKeyDown(int keyCode, KeyEvent event) {
if ((keyCode == KeyEvent.KEYCODE_VOLUME_DOWN)
|| (keyCode == KeyEvent.KEYCODE_VOLUME_UP)
|| (keyCode == KeyEvent.KEYCODE_VOLUME_MUTE)) {
return true;
}
return super.onKeyDown(keyCode, event);
}
You can call maxVolume() in your onCreate method, and later call it just before you start using the jack output procedure to make sure the system has not changed your volume.
Alternatively you can register a listener to listen for volume changes, make maxVolume() static and call it from the listener. Hope it helps you out!
I know that this question is quite old, but I just ran across this issue myself. I figured that I would add to the answers given with what I found in case it helps someone else that happens upon this.
One of the posts here mentions that the warning is not in the AOSP, but this is not true. Please reference the VolumePanel::SafteyWarning class here: VolumePanel::SafetyWarning
Once you peruse through the SafetyWarning class you'll notice that there is a hidden method inside of the AudioManager class called disableSafeMediaVolume. You can, through reflection, invoke this hidden method easily enough, but if you do then you'll get a security exception as it requires the system permission "android.permission.STATUS_BAR_SERVICE".
So... with that said, the dialog as far as I can tell, cannot be programmatically suppressed unless you have this system permission.
What we ended up doing with the blessing of product management is we cache the volume setting in SharedPreferences and then reset it from the cache when our application starts. If it happens to be above the threshold for the warning dialog then the warning will be shown and the user will just have to press OK to get the volume setting that they want, but at least they won't have to manually reset the volume themselves.
A couple of other notes on why some don't see this dialog. You will only see it if you have headphones (or earbuds, or a wired headset) plugged into the device and you attempt to set the media volume stream over a certain threshold (on the Samsung Galaxy Tab A this threshold is 60%). If you press OK at the dialog then it will not be shown again unless you either restart the device or unplug the headphones and plug them back in (with the volume set at or above the threshold).
Hope this helps someone.
I don't know if you can consider this much of an answer but I'm pretty sure you can't remove that message as its displayed by the system automatically and not by something you can access. My Samsung Galaxy S3 does the same thing.
Also from what I can read on the net some android devices also lower the volume when you put in a jack stick so "you don't harm your hearing".
Can you override the notification by displaying your own notification just before or after perhaps? The notification is just a standard Toast.
Related
I'm building an application for a COSU device. I based my code on the following example provided by Google:
Codelabs.developers.google.com/cosu
In the LockedActivity there is the following piece of code:
private void setDefaultCosuPolicies(boolean active){
// Set user restrictions
setUserRestriction(UserManager.DISALLOW_SAFE_BOOT, active);
setUserRestriction(UserManager.DISALLOW_FACTORY_RESET, active);
setUserRestriction(UserManager.DISALLOW_ADD_USER, active);
setUserRestriction(UserManager.DISALLOW_MOUNT_PHYSICAL_MEDIA, active);
setUserRestriction(UserManager.DISALLOW_ADJUST_VOLUME, active);
// remainder of this method is left out for simplicity
}
private void setUserRestriction(String restriction, boolean disallow){
if (disallow) {
mDevicePolicyManager.addUserRestriction(mAdminComponentName,
restriction);
} else {
mDevicePolicyManager.clearUserRestriction(mAdminComponentName,
restriction);
}
}
When active == true in the above snippet, the volume buttons are disabled correctly as a consequence of setUserRestriction(UserManager.DISALLOW_ADJUST_VOLUME, true). However, this also mutes the master volume (which is documented here). That prevents my application from playing any sound. Personally, I think it would be better if the volume would simply be frozen at the level it was or if the volume were at least programmatically still configurable (which seems not to be the case).
I could programmatically override the volume up/down buttons, but that feels more like a workaround/hack (this is for instance done here).
So my question is: Is there a way to unmute the master volume while having the UserManager.DISALLOW_ADJUST_VOLUMEuser permission set to true? Or are there any decent workarounds?
I've been running into an issue with the MediaPlayer on Lollipop devices. Basically when the device screen is off (i.e. user locked the device) the playback continues, but ends about 1 - 2 seconds too early. This doesn't happen when the screen is on though.
I have an onCompletionListener on the MediaPlayer:
#Override
public void onCompletion(final MediaPlayer mediaPlayer) {
int progress = mediaPlayer.getCurrentPosition();
int duration = mediaPlayer.getDuration();
Log.d("PlaybackController", "progress: " + progress + " duration: " + duration);
Log.d("PlaybackController", "Delay: " + (duration - progress)); // I'm seeing a difference of 1 - 3 seconds :(.
mServiceHandler.postDelayed(new Runnable() {
#Override
public void run() {
broadcastCompleted();
}
}, Math.max(duration - progress, 0));
}
This usually prints: Delay: [1500 - 3000]. I was wondering if there was a wake lock I'm missing, but I'm making the correct locks mentioned here: http://developer.android.com/guide/topics/media/mediaplayer.html, which include a PARTIAL_WAKE_LOCK and a WifiLock. Is there something else I'm missing?
Ok it looks like the issue is Android 5.0.1's experimental MediaPlayer called NuPlayer. NuPlayer is being enabled by default on all Android 5.0.1 devices and is only disabled through Developer Options. I've filed a bug against Android here: https://code.google.com/p/android/issues/detail?id=94069&thanks=94069&ts=1420659450
Here's a sample email you can send your users when they face issues with Media playback on Android 5.0.1 devices:
It looks like this might be a bug on Android's new experimental MediaPlayer called NuPlayer. To fix this, please follow these steps:
Go to Android Settings
Go to "About Phone"
Scroll down to "Build Number" and tap the Build number 7 times.
You'll see a message saying "you are now X steps away from being a developer".
After tapping it 7 times it will say "You are now a developer!"
Go back to the main settings screen and you'll see a new option called "Developer Options" right above "About Phone"
Go into Developer Options and Unselect "Use NuPlayer (experimental)" under the Media section.
Update:
Setting a partial wake lock on the MediaPlayer resolves this problem:
playerToPrepare.setWakeMode(context, PowerManager.PARTIAL_WAKE_LOCK);
A partial wake lock shouldn't have too big of an impact, and it seems like MediaPlayer itself cleans this up when playback completes.
-- Original Answer ---
I'm cross-posting my answer from here Prevent my audio app using NuPlayer on Android Lollipop 5.x?, until there's a fix out for NuPlayer, the best you can do is to detect when NuPlayer is enabled and take the user to the Developer Settings.
This approach checks Android's system properties values to see if the user have enabled the use of AwesomePlayer or not under Developer Settings. Since Lollipop have NuPlayer on by default, if this value is disabled, we know NuPlayer will be used.
Drop SystemProperties.java into your project for access to read the system properties, do not change its package name from android.os (it calls through to its corresponding JNI methods, so needs to stay the same).
You can now check if the phone is Lollipop/5.0, if AwesomePlayer is enabled, and act accordingly if it's not (e.g. by opening the Developer Settings):
public void openDeveloperSettingsIfAwesomePlayerNotActivated(final Context context) {
final boolean useAwesome = SystemProperties.getBoolean("persist.sys.media.use-awesome", false);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP && !useAwesome) {
final Intent intent = new Intent(Settings.ACTION_APPLICATION_DEVELOPMENT_SETTINGS);
context.startActivity(intent);
}
}
I have a ContentObserver set up to check for audio changes in a service. I want to know if there's a way to restrain the triggering of the ContentObserver to only certain apps.
Say, I'm playing a game where I can change the volume, after which I change the volume in the settings. I want the service to trigger an alert only when the volume is changed by the game. How do I go about this?
NOTE: The game is a 3rd party app.
EDIT
Is there a way to receive the stack order of the commands? Say a program accesses settings to change the volume, obviously settings is gonna know which program is trying to change the volume. Is there a way to get settings to throw the app's package name? Or is there a way to know if it was changed directly in the settings.
Say I'm in the app drawer and change the volume, that would be categorized as direct change and via an app a third party change. Is there a way to find out when it's a direct change?
you can make a broadcast intent of your own and fire it when game makes the change. Then receive it in your second app.
If game is a third party app, then there would be no way I guess.
I found a way to circumvent this.
To the service with the ContentObserver, I added this piece of code
private RunningAppProcessInfo getForegroundApp() {
RunningAppProcessInfo result=null, info=null;
if(mActivityManager==null)
mActivityManager = (ActivityManager)mContext.getSystemService(Context.ACTIVITY_SERVICE);
List <RunningAppProcessInfo> l = mActivityManager.getRunningAppProcesses();
Iterator <RunningAppProcessInfo> i = l.iterator();
while(i.hasNext()){
info = i.next();
if(info.importance == RunningAppProcessInfo.IMPORTANCE_FOREGROUND
&& !isRunningService(info.processName)){
result=info;
break;
}
}
return result;
}
So, now that I know the foreground app, the probability that it triggered the volume change is very high. So I can exclude it from triggering any respone. It's not flawless, but it works.
My code listens to the DCIM folder, using a FileObserver.
All Android versions I used, except 4.1.1, sent only 1 event - when the video was finished taken.
I think it's the correct behavior - write continually and close when finished.
In 4.1.1 (Galaxy Nexus and Nexus S) though, the event FileObserver.CLOSE_WRITE is sent
twice - when the video starts and when it ends.
Also the same for photos - the event is sent twice - though it's not that critical.
The problem is that I can't distinguish between the start event and end event of a video.
I could try and check the size of the file, but because the event may have been delayed (slow/busy device), the size may be quite big.
Any idea why was the behavior changed? Do you know where is the camera's app source code? I can try and look at the history to understand that.
As I wrote in one of my comments, the difference between 4.1 and previous Android versions is that in 4.1.1, the file is written and closed twice. Once when an empty video file is created. Then the video is written into a tmp file. Then the rename/copy of the tmp file is the second write_close event.
In previous versions there's not tmp file - only the original - thus only one close_write event.
Please comment if you think it's a bug. I'm not sure.
I have myself an app which monitors the DCIM/Camera directory through a FileObserver. What I noticed, and could be of help to you, is that the first operation is a CLOSE_WRITE, however the final operation is a MOVED_TO from the .tmp to the real file, which means you can recognize when the video is (really) ready.
My real code is more complex due to the requirements of my app, but the general idea is something like this:
/* My FileObserver implementation field */
private HashSet<String> jbCache = new HashSet(...)
...
protected void onEvent(int event, String path) {
boolean isJellyBean = Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLYBEAN;
if ((event & FileObserver.CLOSE_WRITE) > 0) {
if (isJellyBean) {
jbCache.add(path);
} else {
performYourWork(path);
}
} else if ((event & FileObserver.MOVED_TO) > 0 && isJellyBean && jbCache.contains(path)) {
performYourWork(path);
jbCache.remove(path);
}
}
You have to listen to both CLOSE_WRITE and MOVED_TO when you register the events you want to catch, obviously.
Although I starred your bug, I doubt Google will ever acknowledge it, as it looks like there could be some (disagreeable) reasoning behind the change. The Camera app is mostly a no-standard crap anyway (e.g.: fake DCIM standard compliance)
I had caught phone boot event.
On boot complete event I am writing following code
KeyguardManager mKeyguardManager = (KeyguardManager) mContext.getSystemService(KEYGUARD_SERVICE);
KeyguardLock mLock = mKeyguardManager.newKeyguardLock("MyApp");
mLock.disableKeyguard();
but what happing I can able to see lock and after that screen is getting unlocked. But requirement is that lock should not be visible at all after booting.
My guess is that I need to make modification in framework somewhere in setting file.
But I don't know where to modify.
but what happing I can able to see lock and after that screen is getting unlocked
You did not lock the screen. Hence, you cannot unlock it. disableKeyguard() is only used to reverse the effects of reenableKeyguard().
My guess is that I need to make modification in framework somewhere in setting file.
If by "setting file" you mean "Java, or possibly C/C++, source code", then yes that is probably the case.
But I don't know where to modify.
StackOverflow is not a great resource for assistance with firmware modifications, sorry.
I have did it by commenting following code in KeyguardViewMediator
private void showLocked() {
/* if (DEBUG) Log.d(TAG, "showLocked");
Message msg = mHandler.obtainMessage(SHOW);
mHandler.sendMessage(msg);*/
}