1

Our database create fails on about 1% of new users when they try to launch our app. Happens mostly in China, sometimes in Russia and other locales. Can't reproduce it on any of my devices, but I've gathered info from log uploads.

One thing I noticed: when the db create fails the file permissions of our package directory /data/data/com.lootworks.swords are --x i.e. cannot read/write. This is different from my test devices which have rwx access.

Is --x on the package directory why the db create fails? It sure sounds bad to me unless the OS does something funky like change permissions when SQLite tries to access it. Has anyone seen this before?

More info:

  • The app uses subclassed SQLiteOpenHelper, very routine (not copying a prepared db file or anything like that)
  • Initial call to getWritableDatabase() happens during Application.onCreate()
  • That call fails before it gets as far as calling our SQLiteOpenHelper.onCreate() method

Exception is on the first call to getWritableDatabase(). That should call back to our onCreate but it fails before that:

Caused by: android.database.sqlite.SQLiteException: unable to open database file
at android.database.sqlite.SQLiteDatabase.dbopen(Native Method)
at android.database.sqlite.SQLiteDatabase.<init>(SQLiteDatabase.java:1880)
at android.database.sqlite.SQLiteDatabase.openDatabase(SQLiteDatabase.java:851)
at android.database.sqlite.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:885)
at android.database.sqlite.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:878)
at android.app.ContextImpl.openOrCreateDatabase(ContextImpl.java:599)
at android.content.ContextWrapper.openOrCreateDatabase(ContextWrapper.java:234)
at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:149)
at com.lootworks.swords.db.SwSqlDbOpenHelper.getDb(SourceFile:379)
at com.lootworks.swords.db.SwSqlDbOpenHelper.getOpenHelper(SourceFile:88)
at com.lootworks.swords.db.SwSqlDb.prepareDatabase(SourceFile:66)
at com.lootworks.swords.SwApplication.onCreate(SourceFile:291)
at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1004)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:3372)
at android.app.ActivityThread.access$2200(ActivityThread.java:155)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1031)
at android.os.Handler.dispatchMessage(Handler.java:130)
at android.os.Looper.loop(SourceFile:351)
at android.app.ActivityThread.main(ActivityThread.java:3818)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:538)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:901)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:659)
at dalvik.system.NativeStart.main(Native Method)

Things I checked already:

  • Some users are sideloaded (some CN file share thing?) but have examples where installer is com.android.vending (GPlay)
mwk
  • 1,959
  • 1
  • 14
  • 22

1 Answers1

1

Is --x on the package directory why the db create fails?

That would be my guess. Your process cannot even see if databases/ exists, let alone create it.

Some users are sideloaded (some CN file share thing?) but have examples where installer is com.android.vending (GPlay)

Bear in mind the Play Store is pirated a fair bit, so just because the app claimed to be installed by Google Play does not mean that the device is compatible with the Play Store.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • It didn't occur to me that Play Store would be pirated, though in hindsight of course it would be. So I suspect these are messed up installs from some unofficial distribution. I've added some more info collection to get a better idea of the success/fail % in regions where there are alternate android versions/piracy. – mwk Feb 02 '13 at 22:40
  • With 24h of data every launch where package direction permission is rwx succeeds. I think the pirated gplay info was the answer I needed, thx – mwk Feb 04 '13 at 03:24