How to achieve exact(accuracy to seconds) timing on Android service

Question

I'm making an app that does stuff in time intervals. The absolute longest i can wait between the updates is 30 seconds, anything between that and 0 is acceptable but i prefer 15 seconds for good measure. However, its not as easy as it sounds. I tried 4 methods, all of which are unacceptable for various reasons.

Keep in mind these problems occur in a Service, when this code is run in an Activity it runs fine. I also noticed that when the phone is plugged into my computer for debugging purposes, solution 3 run perfectly fine until i plug it out. I checked my battery settings, and there are no battery saving modes or other stuff like that, that could be the reason for this.

1.IntentService that does stuff and then reschedules itself in 15 seconds. Unfortunately AlarmManager.setExact() is completely unreliable when it comes to the alarms being exact, as i described in this tumbleweed: Android Alarm not triggering at exact time

2.Foreground service that has a Thread. In that thread i do my stuff and then sleep() for 15 seconds. This method turned out to be even worse than previous, the thread was being woken up to 5 minutes past the proper time.

3.Then i tried using Timer(as geokavel suggested) and scheduling work using scheduleAtFixedRate and schedule but the work was being done about 15-45 seconds too late, making the intervals to about 1 minute instead of 15 seconds.

4.The last way i thought of to achieve this is to not sleep in the Thread in the foreground service from above. Instead, i compare the time:

public void run(){
    nextTime = System.currentTimeMillis() + sleep;
    while (true){
        if (System.currentTimeMillis() >= nextTime) {
            nextTime = System.currentTimeMillis() + sleep;
            //do stuff
        }
    }
}

This method works like a charm except for one major downside- it uses 20-25% of the CPU all the time.

So my question is, is there maybe a way to make one the above solutions work properly(without their unacceptable downsides)? If not, is there a better way that i missed? Feel free to ask for more detail if needed.

EDIT: Requested code of run():

public void run(){
    try {
        if (Thread.currentThread().isInterrupted()){
            throw new InterruptedException();
        }
        NetworkInfo info = cm.getActiveNetworkInfo();
        if (info == null) {
            throw new UnknownHostException();
        }
        if (info.getType() == ConnectivityManager.TYPE_MOBILE) {
            Log.i(TAG, "Won't use mobile connection");
            throw new UnknownHostException();
        } else {
            internetRestored();
            st.updateData();
        }
    } catch (MalformedURLException | UnknownHostException e) {
        internetFailed();
        Log.e(TAG, "No internet connection, cant log");
    } catch (IOException e) {
        e.printStackTrace();
    } catch (InterruptedException e) {
        Log.i(TAG, "Thread iterrupted");
    }
}

Answer 1

What API are you targeting/compiling with?

Edit: Check out Handlers:

https://developer.android.com/reference/android/os/Handler.html

There are two main uses for a Handler: (1) to schedule messages and runnables to be executed as some point in the future; and (2) to enqueue an action to be performed on a different thread than your own. ... When posting or sending to a Handler, you can either allow the item to be processed as soon as the message queue is ready to do so, or specify a delay before it gets processed or absolute time for it to be processed. The latter two allow you to implement timeouts, ticks, and other timing-based behavior.

I don't see any of the caveats about specific timing here so It might be a good shot.

Some fun docs:

https://developer.android.com/reference/android/app/AlarmManager.html

Otherwise, the alarm will be set as though the application had called setRepeating(int, long, long, PendingIntent). As of API 19, all repeating alarms will be inexact and subject to batching with other alarms regardless of their stated repeat interval.

more from Alarm Manager:

Note: Beginning with API 19 (KITKAT) alarm delivery is inexact: the OS will shift alarms in order to minimize wakeups and battery use. There are new APIs to support applications which need strict delivery guarantees; see setWindow(int, long, long, PendingIntent) and setExact(int, long, PendingIntent). Applications whose targetSdkVersion is earlier than API 19 will continue to see the previous behavior in which all alarms are delivered exactly when requested.

https://developer.android.com/reference/java/lang/Thread.html

Causes the thread which sent this message to sleep for the given interval of time (given in milliseconds and nanoseconds). The precision is not guaranteed - the Thread may sleep more or less than requested.

Timer:

This class does not offer guarantees about the real-time nature of task scheduling.

ScheduledThreadPoolExecutor

Delayed tasks execute no sooner than they are enabled, but without any real-time guarantees about when, after they are enabled, they will commence. Tasks scheduled for exactly the same execution time are enabled in first-in-first-out (FIFO) order of submission.

A few thoughts:

Based on what I've seen your best bet is to lower your targetAPI < 19 and use Alarm Manager.

If that doesn't work my next best option is thread.sleep() while Setting your threads execution priority to as high as possible using Thread.setPriority();

Failing that I would look into ways to lessen your real time needs - the reality is that the way android handles processor time is complicated and it isn't really intended to be a real time system.

If you REALLY need extremely accurate timing you might explore C and trying to execute your code in the AudioFastPath which garuntees you the highest possible regularity in processor time. Thats probably wayyyy over kill though.

Answer 2

Ta-Da! https://developer.android.com/reference/java/util/Timer.html

Timer timer = new Timer();
timer.scheduleAtFixedRate(new TimerTask() {
    public void run() {
        //code to run
    }
},initial_delay,period);

Answer 3

Handler minuteHandler = new Handler();
minuteHandler.postDelayed(runnable, 60000);
final Runnable runnable = new Runnable() {
@Override
public void run() {
  // your runnable code
  minuteHandler.removeCallbacks(runnable);
  minuteHandler.postDelayed(runnable, 60000);
  }
};

Answer 4

If Timers really don't work for you, the most basic implementation would be something like this. You don't need to make a new Service for this to work:

Thread th = new Thread(new Runnable() {
    public void run() {
        while(true) {
            //do stuff
            try {
                Thread.sleep(15000);
            }
            catch(InterruptedException ex) {}
        }
    }
});
th.start();

This will go on forever unless you put a variable in the while loop, or add some conditionals and/or break statements;