{
	"id": "171972",
	"key": "MOD-2443",
	"fields": {
		"issuetype": {
			"id": "1",
			"description": "A problem which impairs or prevents the functions of the product.",
			"name": "Bug",
			"subtask": false
		},
		"project": {
			"id": "10034",
			"key": "MOD",
			"name": "Appcelerator Modules",
			"projectCategory": {
				"id": "10100",
				"description": "Titanium and related SDKs used in application development",
				"name": "Client"
			}
		},
		"fixVersions": [],
		"resolution": null,
		"resolutiondate": null,
		"created": "2018-07-26T22:52:54.000+0000",
		"priority": null,
		"labels": [],
		"versions": [
			{
				"id": "20058",
				"name": "appcelerator.encrypteddatabase 3.0.1",
				"archived": false,
				"released": false
			}
		],
		"issuelinks": [],
		"assignee": {
			"name": "jquick",
			"key": "jquick",
			"displayName": "Joshua Quick",
			"active": true,
			"timeZone": "America/Los_Angeles"
		},
		"updated": "2018-07-30T21:13:21.000+0000",
		"status": {
			"description": "The issue is open and ready for the assignee to start work on it.",
			"name": "Open",
			"id": "1",
			"statusCategory": {
				"id": 2,
				"key": "new",
				"colorName": "blue-gray",
				"name": "To Do"
			}
		},
		"components": [
			{
				"id": "13609",
				"name": "Encrypted SQLite DB"
			}
		],
		"description": "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).\r\n\r\nUnfortunately, 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.\r\n\r\nHowever, 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:\r\n\r\nOur enc.db.js file in the Migrate function:\r\n{code:js}\r\nif (OS_ANDROID && config.adapter.db_name === ALLOY_DB_DEFAULT) {\r\n    _database = Ti.Database\r\n}\r\nif (typeof targetNumber === 'undefined' || targetNumber === null) {\r\n    var tmpDb = _database.open(config.adapter.db_name);\r\n}\r\n{code}\r\n\r\nThis has not solved the issue. Our next step is to modify the _database.open() call as follows:\r\n{code:js}\r\nif (typeof targetNumber === 'undefined' || targetNumber === null) {\r\n    var tmpDb = _database.open(config.adapter.db_name || 'fallback'); // Give it a name if none comes from the config.adapter.db_name.\r\n}\r\n{code}\r\n\r\nIf 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.\r\n* Have there been similar reports?\r\n* Is there a preferred way to handle the changes we're looking at?\r\n* Is there any documentation relating to the encrypteddatabase module?\r\n\r\nThank you for your help!",
		"attachment": [
			{
				"id": "65389",
				"filename": "AndroidErrorScreenshot.jpg",
				"author": {
					"name": "awarnes",
					"key": "awarnes",
					"displayName": "Alex Warnes",
					"active": true,
					"timeZone": "America/Los_Angeles"
				},
				"created": "2018-07-26T22:51:02.000+0000",
				"size": 259573,
				"mimeType": "image/jpeg"
			}
		],
		"flagged": false,
		"summary": "Android: EncryptedDatabase error in Ti 7.1.1 using Android 8",
		"creator": {
			"name": "awarnes",
			"key": "awarnes",
			"displayName": "Alex Warnes",
			"active": true,
			"timeZone": "America/Los_Angeles"
		},
		"subtasks": [],
		"reporter": {
			"name": "awarnes",
			"key": "awarnes",
			"displayName": "Alex Warnes",
			"active": true,
			"timeZone": "America/Los_Angeles"
		},
		"environment": "appcelerator.encrypteddatabase v3.0.1\r\nTiSDK 7.1.1.GA\r\nAppcli 7.0.1",
		"comment": {
			"comments": [
				{
					"id": "439525",
					"author": {
						"name": "mrahman",
						"key": "mrahman",
						"displayName": "Mostafizur Rahman",
						"active": true,
						"timeZone": "Asia/Dhaka"
					},
					"body": "Hello,\r\n\r\nAre you getting the same error using the latest SDK 7.2.0.GA?\r\n",
					"updateAuthor": {
						"name": "mrahman",
						"key": "mrahman",
						"displayName": "Mostafizur Rahman",
						"active": true,
						"timeZone": "Asia/Dhaka"
					},
					"created": "2018-07-27T04:13:03.000+0000",
					"updated": "2018-07-27T04:13:03.000+0000"
				},
				{
					"id": "439529",
					"author": {
						"name": "hknoechel",
						"key": "hansknoechel",
						"displayName": "Hans Knöchel",
						"active": true,
						"timeZone": "Europe/Berlin"
					},
					"body": "Hey there,\r\n\r\nwe 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!\r\n\r\nHans",
					"updateAuthor": {
						"name": "hknoechel",
						"key": "hansknoechel",
						"displayName": "Hans Knöchel",
						"active": true,
						"timeZone": "Europe/Berlin"
					},
					"created": "2018-07-27T10:12:46.000+0000",
					"updated": "2018-07-27T10:12:46.000+0000"
				},
				{
					"id": "439547",
					"author": {
						"name": "awarnes",
						"key": "awarnes",
						"displayName": "Alex Warnes",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "Great, thank you!\r\n\r\nThe 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.\r\n\r\nWe'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.\r\n\r\nAlso, 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.\r\n\r\n-Alex",
					"updateAuthor": {
						"name": "awarnes",
						"key": "awarnes",
						"displayName": "Alex Warnes",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2018-07-27T16:47:02.000+0000",
					"updated": "2018-07-27T16:55:41.000+0000"
				},
				{
					"id": "439548",
					"author": {
						"name": "hknoechel",
						"key": "hansknoechel",
						"displayName": "Hans Knöchel",
						"active": true,
						"timeZone": "Europe/Berlin"
					},
					"body": "Thanks for the insight! Our Android team will check the ticket and let you know the progress.",
					"updateAuthor": {
						"name": "hknoechel",
						"key": "hansknoechel",
						"displayName": "Hans Knöchel",
						"active": true,
						"timeZone": "Europe/Berlin"
					},
					"created": "2018-07-27T16:59:25.000+0000",
					"updated": "2018-07-27T16:59:25.000+0000"
				},
				{
					"id": "439576",
					"author": {
						"name": "jquick",
						"key": "jquick",
						"displayName": "Joshua Quick",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "I don't fully understand how you're reproducing this issue.\r\nIs the issue happening when giving it an invalid file name?\r\n\r\nFrom 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.",
					"updateAuthor": {
						"name": "jquick",
						"key": "jquick",
						"displayName": "Joshua Quick",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2018-07-27T23:54:42.000+0000",
					"updated": "2018-07-27T23:54:42.000+0000"
				},
				{
					"id": "439577",
					"author": {
						"name": "jquick",
						"key": "jquick",
						"displayName": "Joshua Quick",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "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.",
					"updateAuthor": {
						"name": "jquick",
						"key": "jquick",
						"displayName": "Joshua Quick",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2018-07-27T23:55:57.000+0000",
					"updated": "2018-07-27T23:55:57.000+0000"
				},
				{
					"id": "439597",
					"author": {
						"name": "awarnes",
						"key": "awarnes",
						"displayName": "Alex Warnes",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "Hi Joshua,\r\n\r\nThe 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.\r\n\r\nI 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!\r\n\r\n-Alex",
					"updateAuthor": {
						"name": "awarnes",
						"key": "awarnes",
						"displayName": "Alex Warnes",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2018-07-30T15:49:19.000+0000",
					"updated": "2018-07-30T15:49:19.000+0000"
				},
				{
					"id": "439608",
					"author": {
						"name": "jquick",
						"key": "jquick",
						"displayName": "Joshua Quick",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "[~awarnes], do you think you might be running into a restore-from-backup issue?\r\n\r\nYour 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.\r\nhttps://developer.android.com/guide/topics/data/autobackup#Files\r\n\r\nAlso, 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).\r\n{code:javascript}\r\nvar database = require(\"appcelerator.encrypteddatabase\");\r\ndatabase.setPassword(\"password\");\r\nvar dbConnection = database.open(null);\r\nTi.API.info(\"@@@ DB connection opened\");\r\ndbConnection.close();\r\n{code}\r\n",
					"updateAuthor": {
						"name": "jquick",
						"key": "jquick",
						"displayName": "Joshua Quick",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2018-07-30T21:13:21.000+0000",
					"updated": "2018-07-30T21:13:21.000+0000"
				}
			],
			"maxResults": 10,
			"total": 10,
			"startAt": 0
		}
	}
}