#syncadapter

Android: SharedPreferences not accessible from SyncAdapter

When I was trying to access a SharedPreferences value from my Android app’s SyncAdapter, I kept on receiving an old value that was saved to the key.

Quick solution to inaccessible SharedPreferences from SyncAdapter

A quick solution (which may be a short-term one) I tried was to remove android:process=":sync" from the following code:

original source : https://android.jlelse.eu/schedule-tasks-and-jobs-intelligently-in-android-e0b0d9201777

In the modern application development, it is very common for our application to perform tasks asynchronously and scope of them are outside the application’s life-cycle like downloading some data or updating network resources. In some situations we also have to do some work but it is not required to do it right now. To schedule background work, Android introduced several APIs which we can use wisely in our applications.

Selecting a proper scheduler can improve application performance and battery life of the device.

Android M also introduced Doze mode to minimize battery drain while user has been away from device for a period of time.

There are several APIs available to schedule tasks in Android:

Alarm Manager

Job Scheduler

GCM Network Manager

Firebase Job Dispatcher

Sync Adapter

Problems with Services

Services allows you to perform long-running operations in the background. Running services in the background is very expensive for the battery life of the device.

Services are especially harmful when it continuously uses device resources even when not performing useful tasks. Above problem increased when those background services are listening for different system broadcasts (like CONNECTIVITY_CHANGE or NEW_PICTURE etc.).

Schedule task in lifetime of your app

When application is running and we want to schedule or run a task at a specific time then it is recommended to use Handler class in conjunction with Timer and Thread. Instead of using Alarm Manger, Job Scheduler etc. it is easier and much more efficient to use Handler.

Schedule task outside the lifetime of your app

Alarm Manager

AlarmManager provides access to system-level alarm services. This give a way to perform any operations outside the lifetime of your application. So you can trigger events or actions even when your application is not running. AlarmManager can startup a service in future. It is used to trigger a PendingIntent when alarm goes off.

Registered alarms are retained while the device is asleep (and can optionally wake the device up if they go off during that time), but will be cleared if it is turned off and rebooted.

“We should only use AlarmManager API for tasks that must execute at a specific time. This does not provide more robust execution conditions like device is idle, network is available or charging detect.”

Use Case: Let’s say we want to perform a task after 1 hour or every 1 hour. In this case AlarmManager works perfectly for us. But this API is not suitable in a situations like perform the above task only when network is available or when device is not charging.

google android docs https://developer.android.com/training/scheduling/alarms.html

Job Scheduler

This is the chief among all the mentioned scheduling options and perform the background work very efficiently. JobScheduler API which was introduced in Android 5.0(API level 21).

This API allows to batch jobs when the device has more resources available or when the right conditions are met. All of the conditions can be defined when you’re creating a job. When the criteria declared are met, the system will execute this job on your application’s JobService. JobScheduler also defers the execution as necessary to comply with Doze mode and App Standby restrictions.

Batching job execution in this fashion allows the device to enter and stay in sleep states longer, preserving battery life. In general this API can be used to schedule everything that is not time critical for the user.

GCM Network Manager

GCM (Google Cloud Messaging) Network Manager has all the schedule features from JobScheduler. GCM Network Manager is also meant for performing repeated or one-off, non-imminent work while keeping battery life in mind.

It is used to support backward compatibility and can also use below Android 5.0 (API level 21). From API level 23 or higher, GCM Network Manager uses the framework’s JobScheduler. GCM Network Manager uses the scheduling engine inside Google Play services so this class will only work if the Google Play services is installed on the device.

Google has strongly recommended for GCM users to upgrade to FCM and instead use Firebase Job Dispatcher for scheduling any tasks.

Firebase Job Dispatcher

The Firebase JobDispatcher is also a library for scheduling background jobs. It is also used to support backward compatibility (below API level 21) and works on all recent versions of Android (API level 9+).

This library will also works when running device do not have Google play services installed and wants to schedule a job in the application. In this condition this library internally uses AlarmManager. If Google Play service is available on the device then it uses the scheduling engine inside Google Play services.

Tip: It uses AlarmManager to support API levels <= 21 if Google Play services is unavailable.

For the device running on API level 21, it uses JobScheduler. This library also has the same framework so there is no change in functionality.

Sync Adapter

Sync adapters are designed specifically for syncing data between a device and the cloud. It should be only use for this type of task. Syncs could be triggered from data changes in either the cloud or device, or by elapsed time and time of day. The Android system will try to batch outgoing syncs to save battery life and transfers that are unable to run will queue up for transfer at some later time. The system will attempt syncs only when the device is connected to a network.

Wherever possible, it is advised via Google to use JobScheduler, Firebase JobDispatcher, or GCM Network Manager.

original source: http://www.vogella.com/tutorials/AndroidTaskScheduling/article.html

1. Scheduling tasks

1.1. Options for scheduling

If you have a repetitive task in your Android app, you need to consider that activities and services can be terminated by the Android system to free up resources. Therefore you can not rely on standard Java schedule like the TimerTasks class.

The Android system currently has two main means to schedule tasks:

the (outdated) AlarmManager

the JobScheduler API.

Modern Android applications should use the JobScheduler API. Apps can schedule jobs while letting the system optimize based on memory, power, and connectivity conditions.

1.2. The job scheduler API

The Android 5.0 Lollipop (API 21) release introduces a job scheduler API via the JobScheduler class. This API allows to batch jobs when the device has more resources available. In general this API can be used to schedule everything that is not time critical for the user.

1.3. Advantages of the job scheduler API

Compared to a custom SyncAdapter or the alarm manager, the JobScheduler supports batch scheduling of jobs. The Android system can combine jobs so that battery consumption is reduced. JobManager makes handling uploads easier as it handles automatically the unreliability of the network. It also survives application restarts. Here are example when you would use this job scheduler:

Tasks that should be done once the device is connect to a power supply

Tasks that require network access or a Wi-Fi connection.

Task that are not critical or user facing

Tasks that should be running on a regular basis as batch where the timing is not critical

1.4. Create a Job

A unit of work is encapsulated by a JobInfo object. This object specifies the scheduling criteria. The job scheduler allows to consider the state of the device, e.g., if it is idle or if network is available at the moment. Use the JobInfo.Builder class to configure how the scheduled task should run. You can schedule the task to run under specific conditions, such as:

Device is charging

Device is connected to an unmetered network

Device is idle

Start before a certain deadline

Start within a predefined time window, e.g., within the next hour

Start after a minimal delay, e.g., wait a minimum of 10 minutes

These constraints can be combined. For example, you can schedule a job every 20 minutes, whenever the device is connected to an unmetered network. Deadline is a hard constraint, if that expires the job is always scheduled.

To implement a Job, extend the JobService class and implement the onStartJob and onStopJob. If the job fails for some reason, return true from on the onStopJob to restart the job. The onStartJob is performed in the main thread, if you start asynchronous processing in this method, return true otherwise false.

The new JobService must be registered in the Android manifest with the BIND_JOB_SERVICE permission.

<service            android:name=".TestJobService"            android:label="Word service"            android:permission="android.permission.BIND_JOB_SERVICE" > </service>

2. Exercise: Preparation

The following exercise is based on the Android local service exercise.

3. Exercise: Use JobScheduler from a receiver

You learn how to use the Android job scheduler to trigger a service from a broadcast receiver. You also register this receiver for the android.intent.action.BOOT_COMPLETEDbroadcast which is send after a reboot of the Android system. The registered receiver uses the job scheduler to trigger your custom service on a regular basis.

3.1. Create the receiver

Create the following utility class.

package com.vogella.android.localservice; import android.app.job.JobInfo; import android.app.job.JobScheduler; import android.content.ComponentName; import android.content.Context; public class Util {    // schedule the start of the service every 10 - 30 seconds    public static void scheduleJob(Context context) {        ComponentName serviceComponent = new ComponentName(context, TestJobService.class);        JobInfo.Builder builder = new JobInfo.Builder(0, serviceComponent);        builder.setMinimumLatency(1 * 1000); // wait at least        builder.setOverrideDeadline(3 * 1000); // maximum delay        //builder.setRequiredNetworkType(JobInfo.NETWORK_TYPE_UNMETERED); // require unmetered network        //builder.setRequiresDeviceIdle(true); // device should be idle        //builder.setRequiresCharging(false); // we don't care if the device is charging or not        JobScheduler jobScheduler = context.getSystemService(JobScheduler.class);        jobScheduler.schedule(builder.build());    } }

Create the following receiver

package com.vogella.android.localservice; import android.content.BroadcastReceiver; import android.content.Context; import android.content.Intent; public class MyStartServiceReceiver extends BroadcastReceiver {    @Override    public void onReceive(Context context, Intent intent) {        Util.scheduleJob(context);    } }

Register the receiver in the Android manifest for the BOOT_COMPLETED event.

<receiver android:name="MyStartServiceReceiver" >    <intent-filter>        <action android:name="android.intent.action.BOOT_COMPLETED" />    </intent-filter> </receiver>

3.2. Create your job

package com.vogella.android.localservice; import android.app.job.JobParameters; import android.app.job.JobService; import android.content.Intent; /** * JobService to be scheduled by the JobScheduler. * start another service */ public class TestJobService extends JobService {    private static final String TAG = "SyncService";    @Override    public boolean onStartJob(JobParameters params) {        Intent service = new Intent(getApplicationContext(), LocalWordService.class);        getApplicationContext().startService(service);        Util.scheduleJob(getApplicationContext()); // reschedule the job        return true;    }    @Override    public boolean onStopJob(JobParameters params) {        return true;    } }

3.3. Trigger the boot completed event from the command line

Reviving my Sync Adapter Service caused Android device into bootloop, meh.

Another obstacle. This going take time to revive my android device.

Found out the problem to be and empty contentProvider in my sync-adapter xml file :

<?xml version="1.0" encoding="utf-8"?> <sync-adapter xmlns:android="http://schemas.android.com/apk/res/android" android:contentAuthority="" android:accountType=""/>

I supposed to create a stub content provider if I don't want to user any of it.

http://developer.android.com/training/sync-adapters/creating-stub-provider.html

add it to AndroidManifest.xml :

<provider android:name="com.oxyzone.spider.ContentProvider.StubContentProvider" android:authorities="com.oxyzone.spider.ContentProvider.StubContentProvider" android:exported="false" android:syncable="true"/>

also add sync adapater service to AndroidManifest.xml :

<service android:name="com.oxyzone.spider.SyncAdapter.MySyncAdapterService" android:exported="true"> <intent-filter> <action android:name="android.content.SyncAdapter"/> </intent-filter> <meta-data android:name="android.content.SyncAdapter" android:resource="@xml/syncronizer"/> </service>

last is to provide android:resource="@xml/syncronizer" :

<?xml version="1.0" encoding="utf-8"?> <sync-adapter xmlns:android="http://schemas.android.com/apk/res/android" android:contentAuthority="com.oxyzone.spider.ContentProvider.StubContentProvider" android:accountType="com.oxyzone.spider.client.account"/>