Re: [sqlite] SQLite in Android N

[Simon Slavin]

On 15 Jun 2016, at 8:21pm, Eric Sink  wrote:

> FWIW, I wrote a blog entry about this issue to shine a bit more light on it:
> 
> http://ericsink.com/entries/sqlite_android_n.html

"GitHub says the sqlite-net library has 857 forks"

OMG.  /me hides under bed.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite in Android N

[Eric Sink]

FWIW, I wrote a blog entry about this issue to shine a bit more light on it:

http://ericsink.com/entries/sqlite_android_n.html

--
E


On Mon, Jun 13, 2016 at 3:51 PM, Richard Hipp  wrote:

> On 6/13/16, Eric Sink  wrote:
> > "Richard (et al), you no doubt have some contact with the Android folks
> at
> > Google.  Do you have any information you can share about these issues?"
> >
> > I don't think I've seen any reply to this question.  It was a yes/no
> > question, so I *could* interpret radio silence as "no".  :-)
>
> I don't have any information on Android N, unfortunately.
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite in Android N

[Richard Hipp]

On 6/13/16, Eric Sink  wrote:
> "Richard (et al), you no doubt have some contact with the Android folks at
> Google.  Do you have any information you can share about these issues?"
>
> I don't think I've seen any reply to this question.  It was a yes/no
> question, so I *could* interpret radio silence as "no".  :-)

I don't have any information on Android N, unfortunately.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite in Android N

[Eric Sink]

"Richard (et al), you no doubt have some contact with the Android folks at
Google.  Do you have any information you can share about these issues?"

I don't think I've seen any reply to this question.  It was a yes/no
question, so I *could* interpret radio silence as "no".  :-)

But I think I'll cast the line into this water one more time.

Anybody know if the folks at Google/Android are even aware of the
possibility of corrupting a SQLite file by using multiple instances of the
library?

Anybody know if there is any likelihood they will decide to make libsqlite
part of the NDK?

--
E


On Mon, Jun 6, 2016 at 12:26 PM, Eric Sink  wrote:

>
> It is my understanding that Android N will no longer allow apps to use the
> system-installed SQLite library (unless they go through the Android Java
> API, android.database.sqlite).
>
> This is unfortunate, as many existing Android apps do access libsqlite3
> directly and will crash on Android N.
>
> Apps which ONLY use the Java API will be unaffected.
>
> Apps that do NOT use the Java API will need to bundle their own SQLite
> library, if they are not doing so already.
>
> And then, there is a particularly unfortunate group:  Apps which do some
> of their SQLite operations through the Java API, but also do some things
> through direct access to libsqlite.
>
> Because of the POSIX locking issues, these apps cannot just bundle a
> SQLite and let the two sections of their code each use their own instance
> of the library.  The result will be a corrupt SQLite file.  So the only
> obvious fix for apps in this situation is to change their code to "ONLY use
> the Java API" or "NOT use the Java API".
>
> Of course, another option would be for Google to reconsider and make
> libsqlite part of the NDK public APIs.  :-)
>
> Richard (et al), you no doubt have some contact with the Android folks at
> Google.  Do you have any information you can share about these issues?
>
> Thanks,
>
> --
> E
>
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite in Android N

[Chris Brody]

On Jun 6, 2016 7:47 PM, "Eric Sink"  wrote:
>
> Official, but slightly vague:
>
> https://developer.android.com/preview/behavior-changes.html#ndk

SQLCipher (based on SQLite) has already dealt with this in:
https://github.com/sqlcipher/android-database-sqlcipher/issues/216

I also made a library to make it easy to embed a SQLite build for Android
at: https://github.com/liteglue/Android-sqlite-connector with the native
NDK build in: https://github.com/liteglue/Android-sqlite-native-driver (It
should work OK with Android N.)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite in Android N

[Eric Sink]

Official, but slightly vague:

https://developer.android.com/preview/behavior-changes.html#ndk

>From Xamarin:

https://developer.xamarin.com/releases/android/xamarin.android_6/xamarin.android_6.0/

--
E


On Mon, Jun 6, 2016 at 12:40 PM, Jason H  wrote:

> > It is my understanding that Android N will no longer allow apps to use
> the
> > system-installed SQLite library (unless they go through the Android Java
> > API, android.database.sqlite).
> >
> > This is unfortunate, as many existing Android apps do access libsqlite3
> > directly and will crash on Android N.
> >
> > Apps which ONLY use the Java API will be unaffected.
> >
> > Apps that do NOT use the Java API will need to bundle their own SQLite
> > library, if they are not doing so already.
> >
> > And then, there is a particularly unfortunate group:  Apps which do some
> of
> > their SQLite operations through the Java API, but also do some things
> > through direct access to libsqlite.
> >
> > Because of the POSIX locking issues, these apps cannot just bundle a
> SQLite
> > and let the two sections of their code each use their own instance of the
> > library.  The result will be a corrupt SQLite file.  So the only obvious
> > fix for apps in this situation is to change their code to "ONLY use the
> > Java API" or "NOT use the Java API".
> >
> > Of course, another option would be for Google to reconsider and make
> > libsqlite part of the NDK public APIs.  :-)
>
> This would be problematic for me too. Is there a citation?
>
> Having used the Android API and the C API in the same app, I have to
> conclude that the Android API corrupts databases at a prolific rate. The
> Android API is also rather stupid, forcing the use of
> stupid "convenience" APIs like  update(java.lang.String table,
> android.content.ContentValues values, java.lang.String whereClause,
> java.lang.String[] whereArgs). (I was never able to use an UPDATE statement
> and not have things break.)
>
> I hope Google comes to their senses, or provides a proper interface.
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite in Android N

[Jason H]

> It is my understanding that Android N will no longer allow apps to use the
> system-installed SQLite library (unless they go through the Android Java
> API, android.database.sqlite).
> 
> This is unfortunate, as many existing Android apps do access libsqlite3
> directly and will crash on Android N.
> 
> Apps which ONLY use the Java API will be unaffected.
> 
> Apps that do NOT use the Java API will need to bundle their own SQLite
> library, if they are not doing so already.
> 
> And then, there is a particularly unfortunate group:  Apps which do some of
> their SQLite operations through the Java API, but also do some things
> through direct access to libsqlite.
> 
> Because of the POSIX locking issues, these apps cannot just bundle a SQLite
> and let the two sections of their code each use their own instance of the
> library.  The result will be a corrupt SQLite file.  So the only obvious
> fix for apps in this situation is to change their code to "ONLY use the
> Java API" or "NOT use the Java API".
> 
> Of course, another option would be for Google to reconsider and make
> libsqlite part of the NDK public APIs.  :-)

This would be problematic for me too. Is there a citation?

Having used the Android API and the C API in the same app, I have to conclude 
that the Android API corrupts databases at a prolific rate. The Android API is 
also rather stupid, forcing the use of 
stupid "convenience" APIs like  update(java.lang.String table, 
android.content.ContentValues values, java.lang.String whereClause, 
java.lang.String[] whereArgs). (I was never able to use an UPDATE statement and 
not have things break.) 

I hope Google comes to their senses, or provides a proper interface.



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users