scheduling alarm for every second in android 5.1

Question

I want to run alarm service for every second in my application.It is working fine below 5.1 version. but it is not triggering in 5.1 devices. I am using commonsware wa

Answer 1

Why would you do that?
Use an handler instead:

Runnable runnable = new Runnable() {
    @Override
    public void run() {
        // do your stuff here, called every second
        mHandler.postDelayed(this, 1000);
    }
};

// start it with:
mHandler.post(runnable);

And use the following to stop your 1 sec timer:

mHandler.removeCallbacks(runnable);

Answer 2

I've successfully changed the minimum AlarmManager interval from 1 minute to 30 seconds.

On your device copy /system/framework/services.jar to your computer. Extract classes.dex from it, open with Winrar for example.

 

Download baksmali

java -jar baksmali.jar -o extractfolder classes.dex

edit extractfolder\com\android\server\AlarmManagerService$Constants.smali

Replace all values 0xea60 (60000ms /1min in hex) to however many ms you want the minimum interval to be example 30seconds 0x7530

Save and Smali back to classes.dex

java -Xmx512M -jar smali.jar extractfolder -o classes.dex

Open services.jar again in Winrar, delete classes.dex and drag the newly created classes.dex into services.jar.

Copy back to /system/framework/services.jar

Restart device.

Also on my Samsung device, having the word alarm OR alert(not tested) in the package name adds it to a whitelist. My alarms are fired exactly when I do this.

Answer 3

This is normal behavior in Android Lollipop.

Suspiciously short interval 1000 millis; expanding to 60 seconds

Tells you that the system does not like those short time intervals anymore.

Issue #161244 documented that:

This is working as intended, though is at present inadequately documented (and we're aware of that side of the problem).

Speaking very generally: short-period and near-future alarms are startlingly costly in battery; apps that require short-period or near-future work should use other mechanisms to schedule their activity.

So don't use an AlarmService for this. Prefer a thread or Executors or TimerTask or something else:

// Using Handler
new Handler().postDelayed(runnable, TimeUnit.SECONDS.toMillis(1));

// Using Executors
Executors.newSingleThreadScheduledExecutor().schedule(runnable, 1, TimeUnit.SECONDS);

Answer 4

Use both 1 and 2:

• Use the AlarmManager for the role of alerting the user at an interval greater than one minute (such as the requested 30 minutes)

• If the notification triggers an activity where you need to show updates is in the foreground, then also do something cheap, like postDelayed(), to give the user periodic updates in that activity

Answer 5

This is a reported issue for Android 5.1 that happens whenever you try to set an alarm for an interval less than 60000 milliseconds.

This warning happens because setting a very low interval like this will drain your battery very fast.

Project member on the platform said:

Speaking very generally: short-period and near-future alarms are startlingly costly in battery; apps that require short-period or near-future work should use other mechanisms to schedule their activity.

That's why it is not recommended to use Alarm in your case.

According to your Question update. You want to keep your background service Awake even if the user manually swiped it from the recent apps list. This can be done simple using the START_STICKY flag such as the following. Add this code to your service in onStartCommand method:

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
Log.i("LocalService", "Received start id " + startId + ": " + intent);
// We want this service to continue running until it is explicitly
// stopped, so return sticky.
return START_STICKY;
} 

Source: answer

Answer 6

Try These Steps.

1. Use a Alarmmaager periodical after 1 min
2. Inside that alarm manager use a handler that call after some seconds and perform your task.

Remember

Its not a Good Idea, As the alarm manager is not aware of the current situation of the device, e.g., it does not consider if the device is connected to a power plug, idle or connected to a network Also the alarm manager waste of resources because its doesn't care about when the device has more resources available.