we have problem with incomming call broadcast on newest OS Android 4.2.2.
We are developing app, which should mute ringing for some contacts. It works fine on older systems, but on OS 4.2.2 the device rings for about 1-2 seconds until we are able to mute it.
This happens only when the device is in sleep mode (screen is off). Is the broadcast on this system delayed in some way? Has anybody experienced similar problem to this? Thank you for any reply.
EDIT: After some experiments (on Nexus 4) we found this: when we turn Wi-Fi off, the problem disapear so maybe Wi-fi use too much cpu time when turning on again from sleep (it's only hypothesis). And other think we found: it's happen about 3 times of 4 attempts.
Not very nice, but solved by this:
for contacts we want to mute, set silent ringtone (it's empty 1s ogg file). Of course we backup previous ringtone and restore it when mute function is turned off.
Related
I am currently working on an application which requires a service running in the background to play music when the phone is in sleep mode.
I would like to know what are the actions that can be performed to trigger play music action while the device is in sleep mode.
Basically when your phone is in sleep mode it shuts down the CPU, when it is in sleep mode only thing which works is GSM or CDMA radio that is your incoming calls, SMSs, IP packets and AlarmManager...
After this answer you would think that, It even stop the services also if the phone is in sleep mode.
Then my Answer is, Yes. it does, since the CPU is powered down, all processes freeze in place. For more information you can visit this link.
Thanks to #CommonsWare for great answer.
I can't get a Note 2 running 4.1.2 or Nexus One running 2.2 to stay 'awake enough' with the screen off to keep acting on UDP broadcast packets. I have tried various wakelocks and permissions (see below), it works fine on a Desire HD on 2.3, a Huawei U8110 (T-Mobile pulse mini) on 2.1 and a Samsung Galaxy Mini on 2.2.1.
It does receive and act on new TCP connections directly to its IP/port, but not broadcast UDP packets. If I tap the power button to wake the screen it immediately responds to broadcasts.
Forcing the the screen to stay on (PowerManager.SCREEN_DIM_WAKE_LOCK or higher) does keep it listening but that's not practical.
I'm acquiring wakelocks:
powerManager.newWakeLock(PARTIAL_WAKE_LOCK)
wifiManager.createWifiLock(WifiManager.WIFI_MODE_FULL)
wifiManager.createMulticastLock()
And declaring permissions:
android.permission.INTERNET
android.permission.WAKE_LOCK
android.permission.CHANGE_WIFI_MULTICAST_STATE
android.permission.ACCESS_WIFI_STATE
android.permission.CHANGE_WIFI_STATE
System Wifi sleep policy is 'never'.
The working devices all timeout their screens but still respond to the UDP broadcasts.
In the debugger's Threads view I can see it is still blocking at
DatagramSocket.receive()
whereas on the working devices that returns with a packet which is then logged to logcat.
All devices are running the same .apk.
An update for anyone else with the same problem:
Google seem to think this should work fine:
http://code.google.com/p/android/issues/detail?id=34278
The Nexus One is old so I guess nobody cares.
The Note 2 however is not so I asked in Samsung's developer forum. They don't care either:
http://developer.samsung.com/forum/board/thread/view.do?boardName=General&messageId=247968#postId247968
My current workaround is to provide an option in user-preferences to grab a full wakelock instead of the partial. I added code to cover my UI with a black screen which disappears on a tap; although the backlight is still on this is less annoying and stops potential screen burn. Turning the other lights (capacative buttons) off should be doable but IMHO it's 'good' to let the user know their phone is actually still fully awake.
It stops the device's normal lockscreen timeout. A manual power button press will lock but turns the screen off and so stops UDP receiving, on wake the lockscreen stays on forever until the user unlocks.
So this provides a poor user experience but it's the best I've found.
Any suggestions welcome.
I cannot get some Android devices to wake up using the AlarmManager. Following the advice in other StackOverflow posts, I am testing CommonsWares cwac-wakeful demo unmodified, compiled in Eclipse, and sent directly to my tablet devices.
When the screen is on the app wakes every 15 minutes and dutifully writes a log message, if I switch the screen off (short press on the power button) and remove the USB cable, then reconnect say 30 minutes later, there are no log messages for the period during which the device was asleep. The alarm does trigger immediately after I wake the device up (according to the log message timestamp). If I leave the USB cable connected the alarm does trigger even with the screen off, presumably because the device is in "debug" mode.
I have seen this behaviour on an older Android 2.2 tablet and I think it might be a bug in the hardware or OS common to both devices. However, I would like to rule out a bug in the cwac-wakeful utility and "operator error" if possible.
Has anyone else seen this behaviour and have any suggestions about further diagnostics or remedies?
I actually get the same behaviour when I set the built-in clock alarm from the home page, i.e. the A90 and the VEGAn-TAB don't wake up until the next manual power on. Therefore it must be a fundamental problem with the tablets rather than a bug in AlarmManager or WakefulIntentService.
I have a background Service that control with sensor accelerometer when the phone is upside down and if it's true phone sound. If I run the service and put my phone upside down it's ok but if I push power button and able a lock screen the phone not sound. I don't understand if the service is stopped or is the sensorchangelistener. i have also used into onCreate the wakelock.acquire method but it work good with my phone (galaxy s) but not work with phone of my friend (motorolo defy).. Can you help me? :-(
It's not possible to use sensors while the phone is in standby, or even with a partial wake lock. You need a full wake lock to keep receiving sensor updates. Supposedly some phones have a workaround, in that once the phone goes into standby you can request sensor updates again, but this only works for a few phones, and is hardly a reliable solution. So in short, the only way is to keep the phone awake.
I am new to Android SDK. Maybe someone here can show me how to debug the following problem I have with my Android enabling and keeping the wifi switched on.
I have myself a Samsung Galaxy ACE s5830 which I got just few days back and had found this problem where the phone just displayed error while switching on wifi. I then restarted the phone and found that wifi was working fine. After this I began noticing that the phone occasionally (two or three times a day) got hung up with a blank screen while the keypad is locked (while charging and while idle). When I tried unlocking the keypad, the phone do not respond. I would then have to disconnect the battery or press and hold the power key for 10 seconds to bring my phone back to life. However, I can see that if I switch off wifi, the phone does not get hung up.
I have installed SDK and Dalvik Debug Monitor in my PC but I would like to know how I will be able to debug this issue with the phone connected. Thanks in advance.
If I understand correctly, this issue occurs when you are on a charger with wifi active and the device goes to sleep.
You might attempt to understand the issue by connecting the phone to your computer via usb and leaving "adb logcat" or its DDMS-window equivalent running, and see if anything interesting is shown if it dies. But you may just get buried in extraneous messages until you have some real familiarity with what is normal (lots of weird errors/warnings all the time) and what isn't. After a restart you can look at things like /proc/last_kmsg
Incidentally, if the problem happens on the mains charger but not when connected to the pc (just connected, SD card not mounted and DDMS not running), that could suggest the culprit is electrical noise from the charger.
Or you could attempt to work around it. Some devices have in their settings menu an option to stay "on" whenever connected to a charger.
I believe that you could also write an application which listens for ACTION_BATTERY_CHANGED intents, detects that you have gone on the charger, finds out if wifi is on, and if it is acquires a wakelock. You'd also look for going off the charger or disabling wifi, at which point you would release the wakelock.