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.
Related
I faced the Android scan stopping issue in background when I am developing my COVID contact tracing app for my company. Here is what I have tried:
Add foreground service
Disable all the battery related optimization options in the phones
Enable the application running in background
Tesging devices:Galaxy S20 and Xperia with Android 10, Huawei with Android 8.
The scan stops immediately when going to background if you don't disable those battery optimization settings and application background update. After you disabled those settings, the scan can run about a couple of minutes(~5 minutes), then still stops. From the blog of David:http://www.davidgyoungtech.com/2017/08/07/beacon-detection-with-android-8, it seems that it is impossible to scan continuesly in background, because the JobScheduler will restart every 15 minutes while each scan lasts ~10 minutes at most. Is this the reality, or this is the best solution that I can scan 10 minutes at every 15 mins cycle?
Background beacon detections are tricky to implement because many small issues can trip you up, and the specific issues vary by Android version, Android manufacturer and sometimes model. While Android 8+ restricts background ranging to every 15 mins using the Job Scheduler, if you add a Foreground Service, you can unlock unlimited background ranging.
A few tips:
Focus first on the Galaxy S20 as Samsung behaviors are better documented and closer to vanilla Android. (Ideally you would test on a Pixel device first.) Only once it works on Samsung, move on to the others.
Using the Android Beacon Library reference app configured with the built-in foreground service, I have seen detections of a standard iBeacon or AltBeacon continue on a Galaxy S10 indefinitely in the background, even with a 1.1 second scan period. See if you can reproduce the same.
Be careful of Doze mode. If the CPU is put to sleep due to the phone being motionless with the screen off and not charging, your detections will stop. You can defeat Doze mode with wake locks, but it has a punishing impact on battery usage. You are better off accepting its limitations and keeping your phone in motion periodically during testing. If you want to get logs to see what is happening, use ADB commands to disable charging when connected via USB or learn to use ADB over WiFi.
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.
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.
Is there any way to "Power on" the device in case some alarm happens ?. This was available in old Nokia phones when you set an alarm , if the device is OFF , the devices goes on at the alarm time, then goes OFF again. Can we have this in Android ? . I'm not talking about waking up the device while sleeping, I need to power it on if he is OFF and have battery power.
Thanks alot
This isn't possible with android because once your device is shut down, the OS isn't running until the device is manually switched on.
However, with root access you can schedule a system shutdown with an alarm but you'll need a rooted device which can void your warranty.
I am based in Germany and publish the "Last Call Widget" on the Android Market. I have been steady improving it over time, but one group of users still complain about it not working on their devices.
My widget listens for the "android.intent.action.PHONE_STATE" intent, and then sets an alarm to update the last call UI in 20 seconds, then 60 seconds, then 5 minutes, 1 hour, etc. This works reliably on all my test devices, even with aggressive task killers (try it yourself). Unfortunately I have a cluster of users with Motorola Droids on the Verizon network who complain that the UI does not automatically update.
I believe Verizon is a CDMA network (we have GSM here in Europe), though the Android API docs don't specify any implementation differences. This could also be a driver issue on the Motorola Droid (we have GSM Motorola Milestones in Europe).
I am wondering if anyone reading is in a position to offer any ideas, or test the widget on a Droid and/or CDMA network to see if they can reproduce an issue (with logs)?
Regards
Mark
Well, while I have DROIDs, none have active Verizon accounts, as I moved my Verizon account to an Incredible. Hence, I cannot test your app, as I cannot place phone calls (except 911, and the police really won't appreciate my calling them just to test your app widget).
You might integrate some Flurry-type logging to see if it's that you are not getting the Intent at all, or if it is somehow not meeting your expectations (e.g., EXTRA_STATE not what you're expecting).
Beyond that, you can use the Build class to detect the DROID and have the alarm go off every N seconds all the time the phone is awake, instead of based on the incoming call. This will chew up more battery, and DROID users with your app who attack you with a task killer will stop those alarms. That's why I'd only do this for the DROID, or any other devices that you determine have similar behavior.