We have been receiving reports from various users primarily on Android 8.0 with a run time error that prevents them from using our app (please see attached screenshot).
Unfortunately, we have been unable to reproduce this error _organically_ in our testing over the past six weeks. Due to this inability to reproduce the error we have been flying blind as to what is causing the error and hence what could fix the error.
However, in our testing we were able to reproduce the error by intentionally breaking the system. When we forced the app to look at the default _alloy_ database, we saw the same error message. It appears that when this database is fed into the appcelerator.encrypteddatabase module it will crash since they are looking for different types of information. In order to fix this we allowed the app to use the unencrypted database if it was going to break:
Our enc.db.js file in the Migrate function:
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);
}
This has not solved the issue. Our next step is to modify the _database.open() call as follows:
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.
}
If this fails our next step is to remove the encrypteddatabase module entirely. Any insight would be appreciated. As mentioned above, we have been unable to reproduce this issue ourselves.
* Have there been similar reports?
* Is there a preferred way to handle the changes we're looking at?
* Is there any documentation relating to the encrypteddatabase module?
Thank you for your help!
Hello, Are you getting the same error using the latest SDK 7.2.0.GA?
Hey there, we did not get any reports for this issue so far but will investigate it. Could you confirm that this is
onlyhappening 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! HansGreat, 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
Thanks for the insight! Our Android team will check the ticket and let you know the progress.
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
SQLExceptionis thrown when failing to open the database, a JavaNullPointerExceptioncan 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 potentialSQLExceptionwhich would causedatabase.open()to returnnull. 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.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.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_namevariable 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[~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
nulllike 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();