SQLiteContentHelper.getBlobColumnAsAssetFile should return AssetFileDescriptor?
tandanil opened this issue · 10 comments
I am looking at an error in my build and found that SQLCipher's implementation of SQLiteContentHelper.getBlobColumnAsAssetFile is returning a MemoryFile instead of AssetFileDescriptor.
I have googled this and all the src I've seen return AssetFileDescriptor.
You can convert a MemoryFile to AssetFileDescriptor using :
ParcelFileDescriptor fd = memoryFile.getParcelFileDescriptor();
AssetFileDescriptor mFD = new AssetFileDescriptor(fd, 0, memoryFile.length());
Hi Karan
Yes, I know I can do that. But by definition getBlobColumnAsAssetFile is supposed to return AssetFileDescriptor. Is there any reason why this was changed for sqlcipher?
Thx
Danilo
-----Original Message-----
From: Karan Popali [mailto:reply@reply.github.com]
Sent: Monday, September 19, 2011 6:51 AM
To: Tan, Danilo
Subject: Re: [android-database-sqlcipher] SQLiteContentHelper.getBlobColumnAsAssetFile should return AssetFileDescriptor? (#7)
You can convert a MemoryFile to AssetFileDescriptor using :
ParcelFileDescriptor fd = memoryFile.getParcelFileDescriptor();
AssetFileDescriptor mFD = new AssetFileDescriptor(fd, 0, memoryFile.length());
Reply to this email directly or view it on GitHub:
https://github.com/guardianproject/android-database-sqlcipher/issues/7#issuecomment-2132377
Danilo:
Please test out our Developer Preview 3 release, and see if this has resolved your concern:
https://github.com/downloads/guardianproject/android-database-sqlcipher/SQLCipherForAndroid-SDK-0.0.6-BETA-DP3.tar.gz
In many cases before, we were reimplementing core pieces of the android.database.* API. However, we have been trying to reuse or just build upon existing code in android.database.* where and when we can. Our goal is as close to 100% API compatibility when we can get it, but we cannot always.
Thanks.
ok. will give it a go and let you know.
thx
dt
On 10/30/2011 10:23 PM, n8fr8 wrote:
Danilo:
Please test out our Developer Preview 3 release, and see if this has resolved your concern:
https://github.com/downloads/guardianproject/android-database-sqlcipher/SQLCipherForAndroid-SDK-0.0.6-BETA-DP3.tar.gzIn many cases before, we were reimplementing core pieces of the android.database.* API. However, we have been trying to reuse or just build upon existing code in android.database.* where and when we can. Our goal is as close to 100% API compatibility when we can get it, but we cannot always.
Thanks.
Hi Nathan
I checked the SQLiteContentHelper.java and the method getBlobColumnAsAssetFile is still returning a MemoryFile instead of the normal AssetFileDescriptor.
thx
Danilo
Btw, this is what i did for getBlobColumnAsAssetFile to keep the API consistent...
public static AssetFileDescriptor getBlobColumnAsAssetFile(SQLiteDatabase db, String sql,
String[] selectionArgs) throws FileNotFoundException {
android.os.ParcelFileDescriptor fd = null;
try {
MemoryFile file = simpleQueryForBlobMemoryFile(db, sql, selectionArgs);
if (file == null) {
throw new FileNotFoundException("No results.");
}
Class c = file.getClass();
try {
java.lang.reflect.Method m = c.getDeclaredMethod("getParcelFileDescriptor");
m.setAccessible(true);
fd = (android.os.ParcelFileDescriptor)m.invoke(file);
} catch (Exception e) {
android.util.Log.i("SQLiteContentHelper", "SQLiteCursor.java: " + e);
}
AssetFileDescriptor afd = new AssetFileDescriptor(fd, 0, file.length());
return afd;
} catch (IOException ex) {
throw new FileNotFoundException(ex.toString());
}
}
Ah right. Just digging into this more, and the reason we couldn't return the AssetFileDescriptor, as you realized, was that the needed method was within the "hidden" android.os package. Your use of reflection does seem to solve it.
Will consider integration.
Your code has been included and committed. Thanks for the fix!
Great! Glad to help.
Btw, something you may want to consider as well.
I had replaced all references to SQLiteException to use the android
version instead of the guardianproject one.
The reason is I hit a case where the framework (I forget which one)
returned an android.database.sqlite.SQLiteException and I did not catch
it as I was looking for guardianproject.
Anyway, since the sqlcipher version of the exception is the same (except
for package name) as the android one, maybe it would be good to just
have sqlcipher use the android exception?
thx
dt
On 11/02/2011 11:11 AM, n8fr8 wrote:
Your code has been included and committed. Thanks for the fix!
Yes, we are slowly figuring out which redundant classes we should remove. Seems like SQLiteException might be a good candidate.