SQLiteDatabaseLockedException: database is locked (code 5)

[ramack]

	at android.database.sqlite.SQLiteConnection.executeForChangedRowCount(SQLiteConnection.java:938)
	at android.database.sqlite.SQLiteSession.executeForChangedRowCount(SQLiteSession.java:754)
	at android.database.sqlite.SQLiteStatement.executeUpdateDelete(SQLiteStatement.java:64)
	at android.database.sqlite.SQLiteDatabase.updateWithOnConflict(SQLiteDatabase.java:2113)
	at android.database.sqlite.SQLiteDatabase.update(SQLiteDatabase.java:2058)
	at de.rampro.activitydiary.db.ActivityDiaryContentProvider.update(ActivityDiaryContentProvider.java:418)
	at android.content.ContentProvider$Transport.update(ContentProvider.java:359)
	at android.content.ContentResolver.update(ContentResolver.java:1678)
	at android.content.AsyncQueryHandler$WorkerHandler.handleMessage(AsyncQueryHandler.java:100)
	at android.os.Handler.dispatchMessage(Handler.java:106)
	at android.os.Looper.loop(Looper.java:164)
	at android.os.HandlerThread.run(HandlerThread.java:65)

probably it occurs due to the conditions, as they tend to use mOpenHelper.getReadableDatabase(); instead of the ContentProvider

[ramack]

The situation is improved with 3327a281e60a63be42740b55cf6cb5830b8655e3 but the big portion is a major rewrite of the condition evaluation by moving them into the contentprovider I'd like to shift this to the next release

[ramack]

Also keep #182 in mind and #71 - if the likelihood is completely evaluated in the ContentProvider it is easy to put the current likelyhood into activity - on the other side the contributors would be interesting which is with #182 the weights in the network, hough I am not sure that they are so helpful for the end user...

[ramack]

Mh, seems to get problematic these days if location services are active... If you face this bug you could disable the location logging in the settings of the app to get rid of too many crashes.