i have coded my 2nd android application that switches audio profiles based on a certain schedule (date and time only as of now)....the code is working without any issues if i run the code using the emulator via eclipse...however i recently exported the apk and installed it on my At&t Samsung Galaxy S2 and added the same profile schedule as the emulator, but for some odd reason the timertask is not executing after the 1st time...
For Example:
Here is the Profile Schedule from my phone as well as the emulator:
8AM - 5:30PM -- Work
5:30PM - 10PM -- Home
10PM - 8AM -- Sleep
once the above is scheduled and i press the activate button on the main activity..a background service runs switching from one profile to the next until it is de-activated...
the only difference i have noticed between the emulator and my phone is that, the emulator screen never shuts off...so im guessing that the emulator doesnt ever go on sleep? whereas, my phone's screen turns off after about 30 seconds of inactivity, in addition to the lock screen...furthermore, i turned on USB debugging on the phone and plugged it directly into the computer and from what it seemed like, the code was executing, switching one profile to the next, on my phone without any issues...(Note that, when i was doing this testing, i used smaller time intervals in the profile schedules)...Additional details: i have also added startForeground() in my service code and ensured that the service is not getting terminated...
does anyone have any idea on what im missing, or what i can do to get around this bizarre problem?...i did do some research before posting this, and found out few posts that recommended using: Android's PowerManager...
Thanks for your input
Nothing weird about this: if the phone is asleep, the CPU is off and you cannot execute code. Don't use TimerTask on Android, use AlarmManager to schedule recurring tasks. It's implemented in the kernel and can wake up the phone if necessary (that might have a negative impact on battery life, so use with caution). Also look into WakeLock's.
http://developer.android.com/reference/android/app/AlarmManager.html
Related
I have found the reference to "*alarm*:*job.heartbeat*" in JobSchedulerService.java and it appears that as the name of file suggests, "*alarm*:*job.heartbeat*"is related to scheduling of jobs and when I took the log of dumpsys batterystats, I found out that every 30 minutes, the phone come out of doze by this "*alarm*:*job.heartbeat*". What is the role of "*alarm*:*job.heartbeat*" and can we configure the interval? (I'm rooted)
I think it is related to the android standby bucket. and maybe android 9 adaptive battery. and it is deeply integrated into the system. so it is not as simple as a system app uninstall. and the process is responsible for it is (system_server) .and if you delete it you will have to re-flash your ROM. and using Battery Historian *alarm*:*job.heartbeat* is waking the device every 1 hour and half (90 minutes) but in my case, it does not wake the device out of
Doze. see the image below if the doze is off there will be a gap. and there is a gap because I turned my screen on. my theory that the android system Schedule it to work to check for any change in the bucket and behave accordingly to it
I'm currently developping an app, that need several alarm trigger at the exact time.
For this purpose i created a receiver that schedule the next alarm.
I also created a stress test :
alarmManager call my receiver which create an other alarm for the next minute.
At xx:30 and xx:00 i receive a mail with the log of all the alarm containing the expected date and the triggered date.
All work well on my phone, a samsung galaxy note 3 lite.
Sadly the behavior is not the same on all the devices.
Huawei Honor :I launched it yesterday at 6PM, it worked until 6:16PM and restarted at 6:45PM before completely stop at 7PM.
OnePlus 2 : Currently working, but some notification are not triggered, about 20%... that's a lot for what i need...
So i'm wondering, if some devices have an alarmManager that stop some Alarm When it abused of the system. Unfortunately, I did not find enough of Doc to support this theory.
Have you ever had this kind of problem, how do you solved it?
How can you make a system That will Delivered a notification at the right time with a success rate > 95%?
I had the same problem and after a lot of searching and workaround, I figured that Smart Manager of Samsung Devices in Lollipop and above may be the problem. This component can delay the Alarm Manager to goes off, it is triggered after 3 minutes, if the mobile is working on battery and with the screen closed. Of course you can deactivate the Smart Manager like this :
Launch Samsung Smart Manager application on the device
Tap Battery
Tap App optimization
Detail
Find Your APP
Select "Disabled for"
But in my case it didn't work, neither disabling the Smart Manager worked in 2 Samsung devices with Lollipop . What it did work was to "fool" Smart Manager by refactoring the name of my application's package to contains the String "alert" or "alarm", for example com.example.alarm.myApplication. You can also refer to this link for more information.
Also some other companies like Huawei have their own optimized app that can delay AlarmManager .
Also the new component Android Doze may delay the AlarmManager
Please refer to this link.
Finally your phone works well because is below Lollipop and does not contain Samsung's SmartManager.
some context:
I have an alarm app I use for myself that locks the screen when the alarm goes off for the duration you request prior. Essentially your phone is a ringing brick for x minutes. The only problem is my sleepy self is very irrational and in the morning I figured out that if I turn off the phone and get to the app location and uninstall it before the receiver gets called (boot completed) then I can bypass it bricking my phone. This didn't use to be a big deal when my LG G2 was on 4.2.2 because of how fast the receiver was called I would usually have to restart my phone about 5-8 times to uninstall the app before it was bricked so I just gave up and quit trying. Now, I upgraded to 4.4.2 and the receiver is called about a full 10 seconds later letting me delete the app on the first try every time. Making the app completely useless.
What I have tried:
I have tried using quick_boot in the manifest but I believe that this is only for HTC because on_boot doesn't get called for that OS for some reason. I have also tried the user present which only seems to work after the boot is completed when doing things like unlocking your phone.
Is there really no way to make onReceive be called quicker than onBoot? It would make sense if there isn't , I'm just hoping someone could provide a definite answer either way.
In some cases it is. I'm not 100% sure but i think (some) systemapps have higher priority then the ACTION_BOOT_COMPLETED event. AND there is ACTION_SCREEN_ON which should be triggered before ACTION_BOOT_COMPLETED.
I should have answered this a week or so after I asked this question because I found a pretty useful workaround, although, it is a little sloppy.
I made a new activity(homeLock) with the intent filter . homeLock extends activity and my old main activity(alarmMain) extends homeLock now instead of activity. All homeLock does is start the overlay service(so you can't stop the alarm/use the phone) that will be turned off by alarmMain when it determines whether an alarm should be ringing currently or not. In alarmMain there is a button now that says "change home" which lets you make homeLock the home application. Now, when you turn off the phone and restart to try and delete the application before onBootReceived is called which starts the broadcast receiver(triggers alarm and overlay) the homeLock activity is called which puts an overlay on the screen until it can be removed after the application determines if an alarm should be playing or not (after onBootReceived).
Basically, before you go to sleep just set this application as your home application from within the app or through settings. Now, it should be impossible to delete the application or turn off the alarm once it has started ringing until it has rung its duration because there will always be an overlay on the screen even when restarting the phone.
Obviously this addition is only needed for phones that boot slowly or extremely degenerate sleepers, or both like me. While it is unlikely this will help anyone because it is such a unique problem I thought I should post the workaround I have been using just in case someone does end up finding it useful.
the last couple of days i was busy getting a service up and running for an phone gap application (using the eclipse ide with the device (motorola defy android 2.3.) connected to my computer)/ the service runs in the background when the application is off and has a timer scheduled that passes an intent to launch my application at irregular times/ everything is working as intended/ when the application is off and the device sleeps (screen is black) the timer is still running and at the scheduled time the device gets woken up, the lock removed and the app starts/ however, the bummer came when i unplugged my device from my computer/ the timer seems to work only reliable in sleepmode when the device is connected to my computer/ when its not connected to my computer the timer only fires correctly when the screen is on/ when it is not on it fires unpredictable at will and more often not at all/ i switched off the option that the device should not go in deep sleep when charging/ but it still works when the device is either connected to a power outlet or computer
can anyone try to explain what the reason might be?
is there anything i can do to make sure the timer is running as is should unplugged while the device is sleeping
Sorry my bad, it doesn't FULLY answer your question
One way is to register for ACTION_SCREEN_OFF and ACTION_SCREEN_ON event at the native level and propagate that event to phonegap layer (# html/js level).
More details on handling Screen Off and On intent click here.
More on how to Notify UI layer click here.
The question is very strange:
i have done an app that set an Alarm Manager that lunch a service (it does some operation and at the end stopself()) every 5 minutes. For at least 6 month or more (plugged).
This because i have tranformed my phone in a webcam (IP wireless for panorama wiev), so the service started each 5 minutes take a photo and send it by wifi. So there isn't any user interaction and the phone is away from user control. My app works fine with very fine result, but after 5-6 days working something happens and the app crashes. I think that is the Andorid OS that close the app, but i can't understand how it can cancel di alarm manager schedule operation..
The app is installed on a Samsung Galaxy ACE, i'm thinking to root the phone and cancel all other app on the phone, so that may not be problem.
There is a better way to be sure that the app will run for 6 month or more?
Would be better make a custom rom for this pourpose?
Sorry for my english..
Android can (and actually does) kill applications for its internal reasons. So if you need something resurrected, best way is to use broadcast receiver, and schedule repeating alarm with alarm manager (you have choices, whether it will wake up the phone or not, or whether this shall be at exact times or there is amouint if slip allowed). I also discovered that scheduled alarms not always survive phone reboot - but you can overcome it by registering BOTT_COMPLETE listener, which will reschedule your briadcasts on reboot.
I'm developing application which does this:
https://github.com/ko5tik/camerawatch