Crash when scheduling jobs at Application's onCreate method

I have 2 types of jobs which runs at application’s onCreate in the following sequence:

EventJobUploader.schedulePeriodicJob(); EventJobUploader.runJobImmediately(); FavoriteJob.schedulePeriodicJob(); FavoriteJob.runJobImmediately();

Implementation of jobs methods a similar:

    public static void runJobImmediately(){
        new JobRequest.Builder(EventJobUploader.TAG)
                .setExecutionWindow(TimeUnit.SECONDS.toMillis(10), TimeUnit.SECONDS.toMillis(20))
                .build()
                .schedule();
    }

    public static void schedulePeriodicJob(){
        new JobRequest.Builder(EventJobUploader.TAG)
                .setPeriodic(TimeUnit.MINUTES.toMillis(15), TimeUnit.MINUTES.toMillis(5))
                .setUpdateCurrent(true)
                .setRequiredNetworkType(JobRequest.NetworkType.CONNECTED)
                .build()
                .schedule();
    }

And on several devices (unknown, sentry did not provide any info about them, sorry) I’ve got crash with the following stacktrace:

android.database.sqlite.SQLiteException: table jobs already exists (code 1)
    at dalvik.system.NativeStart.main
    at com.android.internal.os.ZygoteInit.main
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
    at java.lang.reflect.Method.invoke
    at java.lang.reflect.Method.invokeNative
    at android.app.ActivityThread.main
    at android.os.Looper.loop
    at android.os.Handler.dispatchMessage
    at android.app.ActivityThread$H.handleMessage
    at android.app.ActivityThread.access$1300
    at android.app.ActivityThread.handleBindApplication
    at android.app.Instrumentation.callApplicationOnCreate
    at xxx.Application.onCreate
    at xxx.EventJobUploader.schedulePeriodicJob
    at com.evernote.android.job.JobRequest.schedule
    at com.evernote.android.job.JobManager.schedule
    at com.evernote.android.job.JobStorage.put
    at com.evernote.android.job.JobStorage.store
    at com.evernote.android.job.JobStorage.getDatabase
    at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase
    at android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked
    at com.evernote.android.job.JobStorage$JobOpenHelper.onCreate
    at com.evernote.android.job.JobStorage$JobOpenHelper.createJobTable
    at android.database.sqlite.SQLiteDatabase.execSQL
    at android.database.sqlite.SQLiteDatabase.executeSql
    at android.database.sqlite.SQLiteStatement.executeUpdateDelete
    at android.database.sqlite.SQLiteSession.executeForChangedRowCount
    at android.database.sqlite.SQLiteConnection.executeForChangedRowCount
    at android.database.sqlite.SQLiteConnection.nativeExecuteForChangedRowCount

[kukuhyoniatmoko]

In android’s training its said we should leave our database connection open for as long as we possibly need to access it

Since getWritableDatabase() and getReadableDatabase() are expensive to call when the database is closed, you should leave your database connection open for as long as you possibly need to access it. Typically, it is optimal to close the database in the onDestroy() of the calling Activity.

Ref: https://developer.android.com/training/data-storage/sqlite.html

Also post post by a Google engineer (Dianne Hackborn)

Android made a deliberate design decision that is can seem surprising, to just give up on the whole idea of applications cleanly exiting and instead let the kernel clean up their resources. After all, the kernel needs to be able to do this anyway. Given that design, keeping anything open for the entire duration of a process’s life and never closing it is simply not a leak. It will be cleaned up when the process is cleaned up.

Ref: https://groups.google.com/forum/#!msg/android-developers/nopkaw4UZ9U/cPfPL3uW7nQJ

[GrahamBorland]

A much simpler fix would be to just open the database connection once, and reuse it everywhere. You don’t need to open and close the database connection every time you read or write. SQLite itself takes care of thread safety.