GitLab

log a message until sqlite guy gives me a fix to implement logging of
such events in a more elegant way (like sqlite3_trace)

this STOPSHIP CL is adding to the previous STOPSHIP CL for this class of bugs
  https://android-git.corp.google.com/g/#change,40395

this CL wil have to be reverted before shipping. thats why the STOPSHIP
comment all over this CL.
goal is to get stacktrace to help debug http://b/2419869 because it is
intermittently occuring bug and sqlite3 doesn't give enough info
when this error occurs.
Richard Hipp of sqlite is going to send a patch that will provide additional
info when this error occurs.

that CL isn't so useful. and it introduced a bug too: http://b/issue?id=2418478
plus, it added code to sqlite3.c. need to avoid doing that wherever possible

patch from sqlite is http://www.sqlite.org/src/ci/26cb1df735

Merge commit 'c944e589'

* commit 'c944e589':
  android-2.1_r1 snapshot

Merge commit 'fbe53add' into eclair-plus-aosp

* commit 'fbe53add':
  android-2.1_r1 snapshot

When database close() fails, sqlite gives a cryptic message
"unable to close due to unfinalised statements".
Added more info to this message to help developer look at one of the sql
statements that is not finalized and is causing this problem.

it has 2 bugs (1) needs to be extended to return strings longer than 1K
(2) the following bug
      create table a1 (i int, j varchar(5));
    insert 2 rows with j = ''
      insert into a1 values(1,'');
      insert into a1 values(1,'');
    insert 2 rows with j = null
      insert into a1 (i) values (2);
      insert into a1 (i) values (2);
    with original sqlite3 groupConcat func
       select length(group_concat(j,' ')) from a1 where i = 1;
    result is
       1
    with android sqlite3 groupConcat func
       select length(group_concat(j,' ')) from a1 where i = 2;
    result is
       0

unsupported file format error causes the database file NOT be deleted.
and that makes the app not recoverable.
by making it corruption error, db will get removed and app will get re-inited,
even though removing the DB is on corruption is extreme.
but that is a different issue..

Merge commit '8f178b47' into eclair-plus-aosp

* commit '8f178b47':
  FOR MR3: add eventlog entry for all corruption cases in sqlite3.c

this should help in identifying the line of code in sqlite3.c reporting
database corruption.
this is a redo of this CL: https://android-git.corp.google.com/g/#change,37799
(because the old CL was submitted to master branch, but I meant to submit it
to mr3)

you should notice the following from the Android changes in 3.5.9
1. Android Changes are grouped wherever possible.

To Do
1. sqlite3_get_pager_stats() needs to be completed
2. Android change lines 63480-63482 on master branch in sqlite3.c is
not ported yet. can't see where it goes in 3.6.22 code.

this should help in identifying the line of code in sqlite3.c reporting
database corruption.

Merge commit '8d413dec'

* commit '8d413dec':
  remove usage of poison_patch from sqlite.

Merge commit '2ea3148c' into eclair-plus-aosp

* commit '2ea3148c':
  remove usage of poison_patch from sqlite.

Google gears team implemented a patch to sqlite called "poison the header".
It got included in sqlite android shipped.

This patch is meant to corrupt the database header if some sqlite process
concludes that the database is corrupt. Thereafter, any other sqlite process
opening the same database file would quickly see the corruption and exit.

I am not convinced that this is a useful patch for Android.
And, it patch didn't make it to the open source version of sqlite.

could it be causing previously nonexisting
database corruption, by incorrectly poisoning the database header? thats
what I am suspecting.

Google gears team implemented a patch to sqlite called "poison the header".
It got included in sqlite android shipped.

This patch is meant to corrupt the database header if some sqlite process
concludes that the database is corrupt. Thereafter, any other sqlite process
opening the same database file would quickly see the corruption and exit.

I am not convinced that this is a useful patch for Android.
And, it patch didn't make it to the open source version of sqlite.

could it be causing previously nonexisting
database corruption, by incorrectly poisoning the database header? thats
what I am suspecting.

Merge commit 'goog/stage-korg-master' into HEAD

am fd20ece0: bug #2180646: make comparing "404-04" and "40404" return true in the native sqlite (loose) phone number comparison method.

Merge commit 'fd20ece0' into eclair-mr2-plus-aosp

* commit 'fd20ece0':
  bug #2180646: make comparing "404-04" and "40404" return true in the native sqlite (loose) phone number comparison method.

bug #2180646: make comparing "404-04" and "40404" return true in the native sqlite (loose) phone number comparison method.

- when comparing two numbers whose dialable char length is less than the MIN_MATCH (7), treat them as equal if the dialable portion of the numbers match.

Merge commit '468ecb95' into eclair-plus-aosp

* commit '468ecb95':
  fix failing test.

Change-Id: I11fc145464e29364dbf302c1e607a07031e1821d

Merge commit '3fffdd37' into eclair-plus-aosp

* commit '3fffdd37':
  make native sqlite phone_number_compare_loosely use MIN_MATCH of 7 instead of 5.

Change-Id: Ie0dde105e810c07e05471182cd0c0f81045731ef

Merge commit '7bb17d6e' into eclair-plus-aosp

* commit '7bb17d6e':
  Small change

Merge commit '948a119c' into eclair-plus-aosp

* commit '948a119c':
  Revert the default phone number comparation algorithm.

Now developers have to explicitly set the third argument of PHONE_NUMBERS_COMPARE() into 1,
when they want to use "strict" phone number comparation algorithm, which was used in Donut.
In default, PHONE_NUMBER_COMPARE() now uses "loose" phone number comparation algorithm,
which had been used in Cupcake.

Internal issue id: 1892808