Programmatically switch off silent - android

Is it possible to switch the call ringer off silent dueing an incoming call?
I am able to change the phone to normal mode and set the volume of the ringer, but because the phone was in silent previously, it doesn't just start ringing after I change the settings.
What I am doing is, when the phone is in silent and I receive an incoming call, based on certain conditions I want the phone to actually ring.
As mentioned, I have changed the settings ok, so if I receive a subsequent call the ringer works, but the initial call (which triggered the change of settings) still continues to ring in silent mode... Is there a way to (after I set the ringer modes) to force the phone to "ring" with the new settings again?
Update:
I have set the ringer off silent and set to ring at max volume using the following:
AudioManager mAudioManager = (AudioManager)getSystemService(AUDIO_SERVICE);
int origionalVolume = mAudioManager.getStreamVolume(AudioManager.STREAM_RING);
int maxVolume = mAudioManager.getStreamMaxVolume(AudioManager.STREAM_RING);
mAudioManager.setRingerMode(AudioManager.RINGER_MODE_NORMAL);
mAudioManager.setStreamVolume(AudioManager.STREAM_RING, maxVolume, AudioManager.FLAG_SHOW_UI + AudioManager.FLAG_PLAY_SOUND);
I can see in the logs that when the ringer is actually playing, it logs out:
06-13 19:22:33.984: DEBUG/CallNotifier(126): RINGING... (new)
06-13 19:22:33.984: DEBUG/CallNotifier(126): onNewRingingConnection(): incoming: true state: INCOMING post dial state: NOT_STARTED
06-13 19:22:34.094: INFO/ActivityManager(59): Start proc android.process.acore for content provider com.android.providers.contacts/.ContactsProvider2: pid=294 uid=10000 gids={3003, 1015}
06-13 19:22:34.444: INFO/ActivityThread(294): Publishing provider com.android.social: com.android.providers.contacts.SocialProvider
06-13 19:22:34.494: INFO/ActivityThread(294): Publishing provider applications: com.android.providers.applications.ApplicationsProvider
06-13 19:22:34.594: WARN/CallNotifier(126): CallerInfo query took too long; manually starting ringer
06-13 19:22:34.594: WARN/CallNotifier(126): CallerInfo query took too long; falling back to default ringtone
06-13 19:22:34.594: DEBUG/Ringer(126): ring()...
06-13 19:22:34.664: INFO/ActivityManager(59): Start proc com.android.settings for broadcast com.android.settings/.widget.SettingsAppWidgetProvider: pid=301 uid=1000 gids={3002, 3001, 3003}
06-13 19:22:34.684: DEBUG/Ringer(126): mRingHandler: PLAY_RING_ONCE...
06-13 19:22:34.684: DEBUG/Ringer(126): creating ringtone: content://settings/system/ringtone
06-13 19:22:34.734: INFO/ActivityManager(59): Starting activity: Intent { act=android.intent.action.MAIN flg=0x10840000 cmp=com.android.phone/.InCallScreen }
06-13 19:22:35.374: DEBUG/InCallScreen(126): onCreate()... this = com.android.phone.InCallScreen#44f29ad0
06-13 19:22:35.504: INFO/ActivityThread(294): Publishing provider contacts;com.android.contacts: com.android.providers.contacts.ContactsProvider2
06-13 19:22:36.184: DEBUG/AudioHardwareInterface(34): setMode(RINGTONE)
Is there a way to call these functions manually at all?

You could consider when the phone is called, your application starts playing the default ring tone. Kinda hacky though

I think that you can make a broadcast receiver that senses the incoming call,So in its onReceive method you can change the settings of your phone ,hence this settings will take effects as soon as you got the call.
Hope this work.

Check out AudioManager and it shows the developing guide how to use it for changing ringing types dynamically in your application.

Related

Media volume either 0% or 100%

I have a custom android AOSP ROM with a peculiar problem: The volume can only be set to either 0% or 100%. As a result, the volume buttons just turn the sound on or off. If I use the volume slider instead, and the volume is not muted, it jumps immediately to 100%. The volume is not reduced even momentarily.
Interestingly, the volume for ringtones and alarms is not affected and can be set as usual.
The problem occurs via headphones, internal speakers, and HDMI out.
I tried setprop ro.config.media_vol_steps 30, and that does work in that it changes the number of volume steps in the slider - but it does not affect the output volume. I found nothing in logcat, this is the only suspicious thing (I set the volume via slider to a low value):
02-08 06:18:43.117 1813 2298 V audio_hw_primary: out_set_parameters: routing=1024
02-08 06:18:43.670 22493 22493 I vol.Events: writeEvent touch_level_changed STREAM_MUSIC 3
02-08 06:18:44.127 22493 22493 I vol.Events: writeEvent touch_level_done STREAM_MUSIC 3
02-08 06:18:46.575 22493 22493 I vol.Events: writeEvent dismiss_dialog touch_outside
02-08 06:18:46.581 22493 24066 I vol.Events: writeEvent active_stream_changed UNKNOWN_STREAM_-1
02-08 06:18:46.695 1813 2298 V audio_hw_primary: out_set_parameters: routing=1024
02-08 06:18:49.842 1813 2298 D audio_hw_primary: out_standby
What could cause this? E.g. does the hardware report the current volume back to the UI (then it could be a driver problem)?
In your ROM, a fixed-volume (full) is set. Its a resource configuration. Usually done for HDMI devices.

MediaPlayer sometimes not preparing when screen is locked

I have a MusicService for MediaPlayback, wich uses a MediaPlayer with the settings:
player.setWakeMode(getApplicationContext(), PowerManager.PARTIAL_WAKE_LOCK);
player.setAudioStreamType(AudioManager.STREAM_MUSIC);
and those Listeners are set:
OnPreparedListener, OnCompletionListener, OnErrorListener, OnSeekCompleteListener
The MediaPlayer is used for mp3-Playback. When one Song is finished, onCompletion is called. Then PlayNext is called, wich resets the MediaPlayer, then sets the Datasource with the URI of the next Track. Uri is loaded with:
Uri trackUri = ContentUris
.withAppendedId(android.provider.MediaStore.Audio.Media.EXTERNAL_CONTENT_URI, songId);
Then the Player is prepared, then the player is started. This is working fine, but only sometimes, when the Device is locked and played about 1-3 Songs while it was locked and the next Song should start, the Player doesn't prepare until i hit the power button. Figured out, that if I don't hit the PowerButton it takes the Player about 2 Minutes to prepare.
I've Logged everything now and made a few custom outputs with Log.e(...).
This is put out before prepare() (prepareAsync() delivers the same result) is called:
E/MusicService: Preparing now...
This is put out, when onPrepared is called:
E/MusicService: Player prepared.
So this is the full Device-Output after "Preparing now..." is put out:
04-02 13:54:55.506 12517-12517/at.htlleonding.musync E/MusicService: Preparing now.
04-02 13:54:55.525 811-888/? E/libsuspend: Error writing to /sys/power/state: Device or resource busy
04-02 13:54:55.544 246-14756/? D/offload_visualizer: thread exit
04-02 13:54:55.546 246-14754/? V/offload_effect_bundle: offload_effects_bundle_hal_stop_output output 1879 pcm_id 9
04-02 13:54:55.546 246-14754/? D/hardware_info: hw_info_append_hw_type : device_name = speaker
04-02 13:54:55.549 246-14752/? E/audio_hw_primary: offload_thread_loop: Compress handle is NULL
04-02 13:54:55.549 246-924/? D/audio_hw_primary: adev_close_output_stream: enter:stream_handle(0xb5bfa640)
04-02 13:54:55.549 246-924/? D/audio_hw_primary: out_standby: enter: stream (0xb5bfa640) usecase(3: compress-offload-playback)
04-02 13:54:55.555 246-924/? W/AudioFlinger: moveEffectChain_l() effect chain for session 0 not on source thread 0xb59fa000
04-02 13:54:55.611 246-15030/? I/FFmpegExtractor: android-source:0xb1834060
04-02 13:54:55.820 811-888/? E/libsuspend: Error writing to /sys/power/state: Device or resource busy
04-02 13:54:55.972 246-15030/? I/FFMPEG: [mp3 # 0xae2f4400] Skipping 0 bytes of junk at 2177007.
... Then theres no output until i hit the PowerButton. Then the Song is prepared.
If someone is interested in the full output after I hit the PowerButton until "Player prepared" is called, I created a Gist here.
Sidenote:
While the App is used, a few Album-Covers are displayed in some Fragments. They are loaded with Picasso, so I don't need to worry about memory caching. Some ImageViews are filled without Picasso (for example the ImageViews that hold the drawables of my PlayerControls). Maybe there are Problems with the memory/resources?
I might have found the answer in another thread where some faced the same problem while streaming music here.
My final solution is to use a WakeLock, wich I require before preparing a Song and release again onPrepared and onError and onDestroy of my Service. It's important to release it again to save Battery. Make sure to check if the WakeLock is held before releasing it.
I create my WakeLock like this in onCreate of my Service:
PowerManager pm = (PowerManager) getApplicationContext().getSystemService(Context.POWER_SERVICE);
wakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MusicService");
aquire:
wakeLock.acquire();
release:
if(wakeLock.isHeld())
wakeLock.release();
Tested the Playback now for about 10 Minutes and didn't stop until now. I don't know if this is a very battery-saving solution

Why is Account Picker in Android application getting canceled?

Following the "Five minute quick start" documentation for uploading a file from an Android device to Google Drive, I've written a test application that successfully uploads a file but my attempt at copying the relevant code to a larger application doesn't upload a file because its Google Account Picker is always getting canceled:
the onActivityResult() result code is 0 (i.e.,
RESULT_CANCELED),
the onActivityResult() intent argument is null, and
the logcat (shown below) reveals that "Activity is launching as a new task, so
cancelling activity result."
04-22 02:04:25.098: D/alsa_ucm(162): snd_use_case_set(): uc_mgr 0x40e59388 identifier _verb value HiFi Lowlatency
04-22 02:04:25.098: D/alsa_ucm(162): Set mixer controls for Speaker enable 1
04-22 02:04:25.098: D/ACDB-LOADER(162): ACDB -> send_afe_cal
04-22 02:04:25.098: I/ActivityManager(526): START u0 {act=com.google.android.gms.common.account.CHOOSE_ACCOUNT cmp=com.google.android.gms/.common.account.AccountPickerActivity (has extras)} from pid 3484
04-22 02:04:25.098: W/ActivityManager(526): Activity is launching as a new task, so cancelling activity result.
04-22 02:04:25.108: D/alsa_ucm(162): Set mixer controls for HiFi Lowlatency enable 1
04-22 02:04:25.108: D/ALSAModule(162): Device value returned is hw:0,14
04-22 02:04:25.118: D/ALSAModule(162): setHardwareParams: reqBuffSize 1024 channels 2 sampleRate 48000
04-22 02:04:25.118: D/ALSAModule(162): setHardwareParams: buffer_size 2048, period_size 1024, period_cnt 2
04-22 02:04:25.188: D/dalvikvm(526): GC_FOR_ALLOC freed 565K, 15% free 18562K/21684K, paused 71ms, total 71ms
04-22 02:04:25.248: D/overlay(159): Unset pipe=VG0 dpy=0; Unset pipe=VG1 dpy=0; Unset pipe=RGB1 dpy=0
04-22 02:04:25.248: W/InputMethodManagerService(526): Window already focused, ignoring focus gain of: com.android.internal.view.IInputMethodClient$Stub$Proxy#41ebd7e0 attribute=null, token = android.os.BinderProxy#42018140
04-22 02:04:27.991: D/dalvikvm(526): GC_FOR_ALLOC freed 422K, 15% free 18564K/21684K, paused 65ms, total 66ms
04-22 02:04:28.011: I/ActivityManager(526): No longer want com.google.android.marvin.talkback (pid 5301): empty #17
04-22 02:04:28.241: D/overlay(159): Set pipe=RGB1 dpy=0; Set pipe=VG0 dpy=0; Set pipe=VG1 dpy=0;
04-22 02:04:28.672: D/overlay(159): Unset pipe=VG0 dpy=0; Unset pipe=VG1 dpy=0; Unset pipe=RGB1 dpy=0;
The code that launches the Google Account Picker is exactly the same in both applications but the picker gets canceled only in the larger application.
// Handle item selection
case R.id.action_select_account:
mCredential = GoogleAccountCredential.usingOAuth2(this, DriveScopes.DRIVE);
Intent intent2 = mCredential.newChooseAccountIntent();
showToast("intent extra: " + intent2.getStringExtra(AccountManager.KEY_ACCOUNT_NAME)); // TODO: remove after test
startActivityForResult(intent2, REQUEST_ACCOUNT_PICKER);
return true;
default:
return false;
The test application and the larger application are both debug versions, including the same jars (shown below), and running on the same device (Nexus 4, OS 4.2.2) but, as suggested in the five minute quickstart, each application has its own client ID generated by Google APIs Console.
The result of this cancellation is that the onActivityResult() runs as soon as the Google Account Picker gets drawn, well before an account is selected.
UPDATE:
After an approximately equal amount of trial and error, it turns out that removing the following from AndroidManifest.xml fixed the problem.
android:launchMode="singleInstance"
My initial question of why now shifts to why does the Google Account Picker in Android need to create multiple instances?
Thanks,
Greg
If you use singleInstance you permit no other activities to be part of its task. Use singleTask instead.
As stated on http://developer.android.com/guide/topics/manifest/activity-element.html#lmode
a few paragraphs down.
The "singleTask" and "singleInstance" modes also differ from each other in only one respect: A "singleTask" activity allows other activities to be part of its task. It's always at the root of its task, but other activities (necessarily "standard" and "singleTop" activities) can be launched into that task. A "singleInstance" activity, on the other hand, permits no other activities to be part of its task. It's the only activity in the task. If it starts another activity, that activity is assigned to a different task — as if FLAG_ACTIVITY_NEW_TASK was in the intent.
As described in the question's update, the account picker started working when I removed singleInstance launchMode from AndroidManifest.xml. I don't know if this single instance launch mode behavior is a bug or a lack of documentation, but I submitted it to the Android Issue Tracker: issue 54656
For some reason, the intent returned by account manager has singleTop set, which always causes your onActivityResult to fail immediately and return a 0 resultCode (Activity.RESULT_CANCELLED) or whatever. I had to zero-out the intent flags to prevent this
// prevent running AccountPicker as SingleTop which fails and calls onActivityResult immediately otherwise
intent.setFlags(0);
startActivityForResult(intent, AccountManagerUtils.GOOGLE_AUTH_REQUEST_CODE);

Android intent takes a long time to be received

In my app I am sending an intent to update an appWidget. The problem is, from the logcat I can see that the intent is taking on average ten seconds to be received.
05-16 18:12:54.070: DEBUG/PHCA_Variable(7580): Broadcast sent
05-16 18:12:54.080: INFO/ActivityManager(274): Starting: Intent { flg=0x10000000 cmp=com.skipmorrow.phca/.WidgetDialogResponseActivity (has extras) } from pid 7580
05-16 18:12:54.100: WARN/ActivityManager(274): Trying to launch com.skipmorrow.phca/.WidgetDialogResponseActivity
05-16 18:12:54.170: DEBUG/InputTransport(274): Input channel constructed: name='40832a98 com.skipmorrow.phca/com.skipmorrow.phca.WidgetDialogResponseActivity (server)', ashmemFd=299, receivePipeFd=311, sendPipeFd=310
05-16 18:12:54.170: DEBUG/InputTransport(274): Input channel constructed: name='40832a98 com.skipmorrow.phca/com.skipmorrow.phca.WidgetDialogResponseActivity (client)', ashmemFd=304, receivePipeFd=309, sendPipeFd=313
05-16 18:12:54.170: DEBUG/InputTransport(274): Input channel destroyed: name='40832a98 com.skipmorrow.phca/com.skipmorrow.phca.WidgetDialogResponseActivity (client)', ashmemFd=304, receivePipeFd=309, sendPipeFd=313
05-16 18:12:54.180: DEBUG/InputTransport(7580): Input channel constructed: name='40832a98 com.skipmorrow.phca/com.skipmorrow.phca.WidgetDialogResponseActivity (client)', ashmemFd=66, receivePipeFd=67, sendPipeFd=68
05-16 18:12:54.460: INFO/ActivityManager(274): Displayed com.skipmorrow.phca/.WidgetDialogResponseActivity: +362ms
05-16 18:12:56.140: INFO/InputDispatcher(274): Delivering key to current input target: action: 0, channel '40832a98 com.skipmorrow.phca/com.skipmorrow.phca.WidgetDialogResponseActivity (server)'
05-16 18:12:56.260: INFO/InputDispatcher(274): Delivering key to current input target: action: 1, channel '40832a98 com.skipmorrow.phca/com.skipmorrow.phca.WidgetDialogResponseActivity (server)'
05-16 18:12:56.390: DEBUG/InputTransport(7580): Input channel destroyed: name='40832a98 com.skipmorrow.phca/com.skipmorrow.phca.WidgetDialogResponseActivity (client)', ashmemFd=66, receivePipeFd=67, sendPipeFd=68
05-16 18:13:03.350: DEBUG/PHCA_PhcaAppWidgetProvider(7580): onReceive(); action = android.appwidget.action.APPWIDGET_UPDATE
The only thing I see that looks a little fishy is a warning that an activity is starting. Why would that be a warning? Other than that, everything seems ok.
The code to send the intent is nothing special:
Log.d(MY_DEBUG_TAG, "UpdateAppWidgets()");
Intent i = new Intent();
i.setAction(AppWidgetManager.ACTION_APPWIDGET_UPDATE);
ComponentName phcaWidget = new ComponentName(ctx, PhcaAppWidgetProvider.class);
i.putExtra("appWidgetIds", AppWidgetManager.getInstance(ctx).getAppWidgetIds(phcaWidget));
ctx.sendBroadcast(i);
Log.d(MY_DEBUG_TAG, "Broadcast sent");
And the onReceive in the appWidgetProvider is nothing special either. The Log statement is the first command.
What could cause an intent to take upwards of ten seconds to be received?
Skip
If the Activity you are sending the intent to does not yet exist, it has to be started. 10 seconds seems like a long time for starting an app, but not insane.
I have apps which run 5 times or more slower when in debug mode. If you are in debug mode, it could be that it will run much faster if not in debug mode. Generally, you can see logcat messages when not in debug mode, for a device connected to PC running eclipse IDE. If you can get that working, you should try running that way and see if it is faster. Also try running with phone unplugged from Eclipse entirely, it will be harder to tell if its faster but it might be.

"RingtoneManager: unable to find a usable ringtone" persistent error

Some users of our app are reporting that ringtones fail to load as expected. I've included a typical logcat output from one of these users below. It seems that the request for the default ringtone is returning null ("Failed to open ringtone content://settings/system/ringtone"). I've asked these users to change ringtones, and sometimes this resolves the issue, but in other cases (HTC Hero in both the ones I know of) changing the ringtone does not fix the problem. I have been unable to reproduce this problem on any of our test devices. Any thoughts as to what might cause this, how to debug, or how to resolve?
D/Ringtone( 743): create mAudio
D/MediaPlayer( 743): setDataSource(44, 0, 576460752303423487) pid = 743
E/Mp3HwPlayer( 56): ID:24, new Mp3HwPlayer
E/MediaPlayerService( 56): getPlayerType(): Has ID3 info, size = 1024
E/MediaPlayerService( 56): getPlayerType(): Input buffer is MPA format
E/Mp3HwPlayer( 56): ID:24, destory Mp3HwPlayer
D/MediaPlayerService( 56): Create Player playertype=6
D/MediaPlayerService( 56): new PVPlayer for MP3
D/PVPlayer( 56): setDataSource(25, 0, 180143)
D/MediaPlayerService( 56): MediaPlayerService::Client::setDataSource exit
D/MediaPlayerService( 56): returned from setDataSource() in MediaPlayerService::create
D/MediaPlayerService( 56): [23] prepareAsync
I/PlayerDriver( 56): OpenCore disable firewall payload
W/MediaPlayer( 743): info/warning (1, 26)
E/PlayerDriver( 56): Command PLAYER_PREPARE completed with an error or info PVMFErrResource
E/MediaPlayer( 743): error (1, -17)
E/RingtoneManager( 743): Failed to open ringtone content://settings/system/ringtone
E/RingtoneManager( 743): unable to find a usable ringtone
E/IncomingRinger( 743): Couldn't find a ringtone for URI: content://settings/system/ringtone
It looks like the ringtone is stored on a SD card, and you haven't permission to read SD data, so it returns null. I got similar problem with my mediaPlayer.

Categories

Resources