[MOD-2443] Android: EncryptedDatabase error in Ti 7.1.1 using Android 8

Description

if (OS_ANDROID && config.adapter.db_name === ALLOY_DB_DEFAULT) {
    _database = Ti.Database
}
if (typeof targetNumber === 'undefined' || targetNumber === null) {
    var tmpDb = _database.open(config.adapter.db_name);
}

if (typeof targetNumber === 'undefined' || targetNumber === null) {
    var tmpDb = _database.open(config.adapter.db_name || 'fallback'); // Give it a name if none comes from the config.adapter.db_name.
}

Attachments

Comments

1. Mostafizur Rahman 2018-07-27 Hello, Are you getting the same error using the latest SDK 7.2.0.GA?
2. Hans Knöchel 2018-07-27 Hey there, we did not get any reports for this issue so far but will investigate it. Could you confirm that this is only happening on Android 8 or are there single reports that are not Android 8 based? Also, in general, please try the 7.3.0 prerelease (appc ti sdk install -b 7_3_X) which targets Android 8.1 by default (by retaining backwards compatibility to Android 4.1) and fixes many issues around it as well. If it does not help, we will take a closer look. In that case, we definitely need an isolated sample or more concrete steps to be able to reproduce it. Thank you in advance! Hans
3. Alex Warnes 2018-07-27 Great, thank you! The majority of issues have been seen on android 8.0 and 8.1, however we have seen some issues show on 7. Also the majority has been on Samsung phones, though we have seen some LG, and other manufacturers. We've had some issues upgrading our apps through each of the 7.x SDKs, but we can certainly try pushing all the way up to 7.2/7.3 and see where that goes. Also, is there any documentation internal or external on how the encrypted database is meant to be setup? At this point we've just copied what's in the examples folder, and assumed that that's best practice. -Alex
4. Hans Knöchel 2018-07-27 Thanks for the insight! Our Android team will check the ticket and let you know the progress.
5. Joshua Quick 2018-07-27 I don't fully understand how you're reproducing this issue. Is the issue happening when giving it an invalid file name? From looking at our code, I do see an issue where if a SQLException is thrown when failing to open the database, a Java NullPointerException can occur on our end when attempting log the name of the database that we've failed to open. We can fix that, but that would not resolve the potential SQLException which would cause database.open() to return null. From my perspective, this is the right solution. From your perspective, you would not expect the database to return null in this case unless of course the file does not exist.
6. Joshua Quick 2018-07-27 Also, you can work-around this by wrapping the database.open() call in a JavaScript try/catch block. Titanium converts Java exceptions into JavaScript exceptions so that you can handle them.
7. Alex Warnes 2018-07-30 Hi Joshua, The way that we've been able to force reproduce the issue is by passing '_alloy_' as the database name. This appears to point to the built in database, which seems to not have the same methods associated with it. Every other string we've pushed into that config.adapter.db_name variable has worked just fine, whether or not we've used it in the past. I agree, that definitely seems like the proper functionality (I don't want to keep talking to something that isn't there!). We'll give the try/catch block workaround a try as well. However, the weirdness that we've been surprised about is that this only affects Android. Thank you so much for continuing to review this for us! -Alex
8. Joshua Quick 2018-07-30 [~awarnes], do you think you might be running into a restore-from-backup issue? Your app's sandboxed files and shared preferences are all supposed to be restored from backup. So, normally this would not be an issue. But it might be worth checking out on your end. https://developer.android.com/guide/topics/data/autobackup#Files Also, I'm able to reproduce this issue by setting the database file name to null like the below. Note that this will also throw an exception on iOS as well, but iOS gives a more sensible exception message versus Android does not (we can resolve that).

      var database = require("appcelerator.encrypteddatabase");
      database.setPassword("password");
      var dbConnection = database.open(null);
      Ti.API.info("@@@ DB connection opened");
      dbConnection.close();
      

JSON Source