I read that in froyo if you change vibrate settings with setVibrateSettings() it doesn't sync with SO vibrate settings. Then I found this workaround that people use with some of the functions in this link:
https://android.googlesource.com/platform/packages/apps/Settings/+/froyo-release/src/com/android/settings/SoundSettings.java
However, that source code there are two calls to:
173 boolean vibeInSilent = (Settings.System.getInt(
174 getContentResolver(),
175 Settings.System.VIBRATE_IN_SILENT,
176 1) == 1);
227 Settings.System.putInt(getContentResolver(),
228 Settings.System.VIBRATE_IN_SILENT,
229 vibeInSilent ? 1 : 0);
That are the only difference with what I try to do in my code to change vibrate setttings. But Settings.System.VIBRATE_IN_SILENT seems to be removed in 2.2, so when I change vibrate settings "normal, off, only in silent", then I go to SO audio settings and vib value is different, and if i go back to my app, vib settings are also different to what i selected before. Any ideas?
Try the following link:
http://www.kiwidoc.com/java/l/p/android/android/8/p/android.provider/c/Settings.System
From what I have tried, the setting still exist but not exposed as it used to be. It can still be set using the Settings.System.putInt(...) just specify the name "vibrate_in_silent".
I guess that someday this will no longer work so I recommend protecting your code in any way possible (check if setting exist by calling getInt first, add try-catch...)
Related
I have been using std::chrono::steady_clock for interval calculation in an application i am making for Android platform.
Code:
// On application start
auto timeSinceEpoch = std::chrono::steady_clock::now().time_since_epoch();
auto timeInSec = std::chrono::duration_cast<seconds>(timeSinceEpoch).count();
log("On Enter Start Time Point - %lld", timeInSec);
Output:
On Enter Start Time Point - 521
Now i switch off the phone and restart the phone. I run my application and this time Output is:
On Enter Start Time Point - 114
As per definition at cppreference.com
"Class std::chrono::steady_clock represents a monotonic clock. The time points of this clock cannot decrease as physical time moves forward."
How is the output when i restart the phone giving lesser value?
If anyone has faced this issue please help me out here. Thanks!!
The formal requirement for a steady clock is that the result of a call to now() that happens before another call to now() is always less than or equal to the result of the second call. The happens before relationship only applies to actions within a program run. A steady clock is not required to be steady across different invocations of a program.
On Android, AFAICT steady_clock is the same as (from Java) System.Clock.elapsedRealtime, which resets to zero on boot -- https://developer.android.com/reference/android/os/SystemClock.html
I'm totally failing to dig up the source code for clock_gettime, though. https://android.googlesource.com/platform/ndk.git/+/43255f3d58b03cd931d29d1ee4e5144e86e875ce/sources/cxx-stl/llvm-libc++/libcxx/src/chrono.cpp#124 shows it calling clock_gettime(CLOCK_MONOTONIC), but I'm not sure how to penetrate the veil from there.
I want to make a Seek Bar that controls DTMF volume(e.g 0 to 100). I have searched a lot but could not find any thing. I am doing this but its not working..
int seekbarValue=seekBar.getProgress();
AudioManager audioManager=(AudioManager) getSystemService(Context.AUDIO_SERVICE);
audioManager.setStreamVolume(AudioManager.STREAM_DTMF, seekbarValue, 0);
Please any one tell me a solution to control DTMF volume.
None of the (AudioManager.STREAM_*) volumes go to 100 (int).
A valid stream volume for setStreamVolume(...) is between 0 and getStreamMaxVolume(int streamType).
Each stream can have a different max volume int, like 8, 10, or 16 from what I remember. Might even be different on different devices.
I hope that is enough to point you and future visitors in the right direction.
I wanted to add a little more information to the answer of #Anonsage.
As #Anonsage mentioned, each stream has a different max volume. As per Kitkat 4.4.2 implementation, these are the max values.
STREAM.DTMF: 15
STREAM.MUSIC: 15
STREAM.VOICECALL: 5
STREAM.RINGTONE: 7
If you actually get into the lower levels and look into the AudioService.java of AOSP code, there is a rescaling operation that helps to show similar UI and update the actual values of the stream.
I have been trying to capture audio, within a native linux program running on an Android device via adb shell.
Since I seemed to be getting only (very quiet) noise, i.e. no actual signal (interestingly, an Android/Java program doing similar did show there was a signal on that input),
I executed alsa_amixer, which had one entry that looked like the right one:
Simple mixer control 'Capture',0
Capabilities: cvolume cswitch penum
Capture channels: Front Left - Front Right
Limits: Capture 0 - 63
Front Left: Capture 31 [49%] [0.00dB] [off]
Front Right: Capture 31 [49%] [0.00dB] [off]
"off". That would explain the noise.
So I looked for examples of how to use alsa_amixer to unmute the channels, I found different suggestions for parameters like "49% on" or "49% unmute", or just "unmute" none of which works. (if the volume% is left out, it says "Invalid command!", otherwise, the volume is set, but the on/unmute is ignored)
I also searched how to do this programatically (which I'll ultimately need to do, although the manual approach would be helpful for now), but wasn't too lucky there.
The only ALSA lib command I found which sounds like it could do something like that was "snd_mixer_selem_set_capture_switch_all", but the docs don't day what the parameter does (1/0 is not on/off, I tried that ;) )
The manual approach to set these things via alsa_amixer does work - but only if android is built with the 'BoardConfigCommon.mk' modified, at the entry: BOARD_USES_ALSA_AUDIO := false, instead of true.
Yeah, this will probably disable ALSA for android, which is why it wouldn't meddle with the mixer settings anymore.
To you android programmers out there, note that this is a very niche use case of course, as was to be expected by my original post to begin with.
This is not what most people would want to do.
I just happen to tinker with an android device here in unusual ways ;-)
Just posting the code as question giver suggested, also don't like external links.
#include <alsa/asoundlib.h>
int main()
{
snd_mixer_t *handle;
snd_mixer_selem_id_t *sid;
snd_mixer_open(&handle, 0);
snd_mixer_attach(handle, "default");
snd_mixer_selem_register(handle, NULL, NULL);
snd_mixer_load(handle);
snd_mixer_selem_id_alloca(&sid);
snd_mixer_selem_id_set_index(sid, 0);
snd_mixer_selem_id_set_name(sid, "Capture");
snd_mixer_elem_t* elem = snd_mixer_find_selem(handle, sid);
snd_mixer_selem_set_capture_switch_all(elem, 0);
snd_mixer_selem_set_capture_dB_all(elem, 0, 0);
snd_mixer_close(handle);
}
I want to put my phone in dim mode using my application. It seems phone's home screen will be in deem mode. If I going to use Power Manager class then it will drain battery. How can I do this then? Can any one give some sample code?
In my case I just update the Android Default Settings,
android.provider.Settings.System.putInt(cr,android.provider.Settings.System.SCREEN_BRIGHTNESS, 1);
Note: here 1 is value for dim (low) (values 0 t0 250) , and cr is ContentResolver's object
For this you have to mentioned permission in manifest file,
<uses-permission android:name="android.permission.WRITE_SETTINGS"/>
Inside my app, I need a way to turn off the lights on the standard Android phone keys (Home, Menu, Back, and Search) - how can I do this programmatically?
According to this page, the hardware key backlights can be controlled by writing to a specific file in the filesystem with superuser privileges (i.e. phone must be "rooted"):
Q: How can I control the keyboard
backlight?
A: The keyboard backlight can be
controlled via
/sys/class/leds/keyboard-backlight/brightness.
It appears that it's a simple on-off
control (echoing '0' turns it off,
echoing '1' or higher turns it on).
For some reason, the default system
backlight control stuff seems to set
this to "83", but I don't know why. I
can't seem to see any difference
between 83 and any other number. The
file is readable by anyone, but only
writable by root, so you'll need root
access to the phone to manipulate it
this way.
So to turn off the backlight programmatically, you could invoke exec() on the Runtime like so:
Runtime r = Runtime.getRuntime();
r.exec("echo 0 > /system/class/leds/keyboard-backlight/brightness");
Depends on what you are doing, but would probably be wise to check the result of exec() afterwards to see if a write error occurred.
Note: I tested this on my own phone and it seems to work without acting as root. However, this may not be the case on every phone, so you may have different results.
This is applicable only for the device samsung devices:
To get the BackLight sate:
int backLight = Settings.System.getInt(getContentResolver(), "button_key_light");
// if it return -1 it means that light is on
// if it return 0 the light is off
// some time it will return values like 600(1.5 sec)
if you want to put the backLight as off u can do like this
Settings.System.putInt(getApplicationContext().getContentResolver(), "button_key_light", 0);