Just for whoever's still running into the database malformed issue.
We still never figured out what was causing it (some sources say its
an inherent sqlite bug), but we ended up just backing up the db at
certain points and restoring after a corruption delete
:-)
Part of the answer probably lie in this file :
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/java/android/database/sqlite/SQLiteDatabase.java
look for the method called onCorruption().
Why it would ever be called is beyond me, but seems to happen as time
goes by
I just got this on a G1, so its definitely not Droid exclusive...
On Mar 30, 11:22 am, Matt (preinvent) m...@preinvent.com wrote:
On Mar 24, 4:40 pm, Doug dougforp...@gmail.com wrote:
This problem happened to one of my users just today - he has a Droid.
I asked if anything weird had
I got several reports from users that my application had lost the
preferences. This is more than a year ago when the G1 was most
prevalent... I switched to saving preferences in a file instead, and
complaints stopped. Check the following threads for similar reports:
On Mar 24, 4:40 pm, Doug dougforp...@gmail.com wrote:
This problem happened to one of my users just today - he has a Droid.
I asked if anything weird had happened before the problem occurred
(like the phone misbehaving).
He said:
The only random weird behavior I noticed before the problem
Here's my $0.02 worth.
This problem happened to one of my users just today - he has a Droid.
I asked if anything weird had happened before the problem occurred
(like the phone misbehaving).
He said:
The only random weird behavior I noticed before the problem was that
my phone suddenly stopped
To discount any possibility of concurrency problems I've synchronized
the static getInstance on my singleton and every function that calls
the DB (be it read or write). Makes no different though... it just
wiped it all again.
It must be a filesystem problem (delayed writes?), or something buggy
Uh, have you considered changing out your flash chip just to disprove
the notion that
it's widespread? While sqlite certainly makes higher demand on the
crappy underlying
FAT file system, it also possible that it's just a hardware problem.
I have a lot of users reporting this issue. All of
Matt (preinvent) wrote:
To discount any possibility of concurrency problems I've synchronized
the static getInstance on my singleton and every function that calls
the DB (be it read or write). Makes no different though... it just
wiped it all again.
1. Have you been getting reports of
I was recently was doing some file io stuff and discovered that when
debugging the application gets killed in a more drastic way than is
not possible on the phone. What I found is that if a debug session is
started during a file io write the data file gets corrupted. On the
phone you have to pull
1. Have you been getting reports of problems from Nexus One owners? In
other words, is this a DROID/Milestone thing or a 2.0+ thing?
Nope, Droid/Nilestone only, not Nexus One. I had one possible report
from an HTC Hero owner, but have yet to confirm. Will follow up.
2. Are you writing other
Matt (preinvent) wrote:
I now believe that the SharedPrefs issue was a red herring. Since I
set all my app preferences to use persistent storage (I didn't realise
this was NOT the default) I only experience problems with the DB.
AFAIK, SharedPreferences always use persistent storage. You just
So I haven't been following this thread very closely so apologies in
advance if you've already
been over this.
The SQLite thing kind of has the stench about it like there are possibly
multiple writers. AFAIK,
SQLite is very single threaded and multiple writers is a big no-no. So
let me toss
Matt (preinvent) wrote:
Well there it is:
03-19 22:43:02.624: ERROR/AndroidRuntime(2002): Caused by:
android.database.sqlite.SQLiteDatabaseCorruptException: database disk
image is malformed
03-19 22:43:02.624: ERROR/AndroidRuntime(2002): at
Matt (preinvent) wrote:
Still no nearer getting this fixed... I rooted my Droid and can see
that the /data/data/myapp/lib directory was created some time ago -
that implies to me that the main app directory has not been deleted
since it was installed some time ago, therefore it's unlikely that
Well there it is:
03-19 22:43:02.624: ERROR/AndroidRuntime(2002): Caused by:
android.database.sqlite.SQLiteDatabaseCorruptException: database disk
image is malformed
03-19 22:43:02.624: ERROR/AndroidRuntime(2002): at
android.database.sqlite.SQLiteQuery.native_fill_window(Native Method)
03-19
Uh, have you considered changing out your flash chip just to disprove
the notion that
it's widespread? While sqlite certainly makes higher demand on the
crappy underlying
FAT file system, it also possible that it's just a hardware problem.
FWIW, we've been using a sqlite db on the iPhone
Out of curiosity, why? Have you tried not doing this, and just using
PreferenceManager.getDefaultSharedPreferences() everywhere, to see if
this is somehow contributing to your woe?
That's what the docs said when I read them! I'm loathe to change as
all my disgruntled users who upgrade will
Well, it could point to a different application, if you make the
mistake of calling getApplicationContext() rather than
getApplication().
So make sure to use getApplication() instead!
I only see getApplication() for services and activities - how do I get
this in my widget code and my
(thought I posted this, can't see the post!)
Well, it could point to a different application, if you make the
mistake of calling getApplicationContext() rather than
getApplication().
So make sure to use getApplication() instead!
I only see getApplication on services and activities.. how do
Still no nearer getting this fixed... I rooted my Droid and can see
that the /data/data/myapp/lib directory was created some time ago -
that implies to me that the main app directory has not been deleted
since it was installed some time ago, therefore it's unlikely that
android is simply
On Mar 16, 5:21 pm, Bob Kerns r...@acm.org wrote:
If you're using getDefaultSharedPreferences, you want to use
getApplication() to get the context to supply.
I'm using context.getSharedPreferences(constant string, 0) - ie i'm
definitely specifying the same filename to every call., it's just
The underlying getSharedPreferences() method takes a string, which is the
unique set of preferences for that package. Any context in that application
using that same string will be working with the same preferences (hence why
they are shared).
The context I'm being passed may come from a
Matt (preinvent) wrote:
The underlying getSharedPreferences() method takes a string, which is the
unique set of preferences for that package. Any context in that application
using that same string will be working with the same preferences (hence why
they are shared).
The context I'm being
The context I'm being passed may come from a service, widget update
request, activity or broadcast receiver (from the BATTERY_CHANGE
action). Can I be sure that the context points to my application in
all those instances?
What else would it point to?
That's pretty much my exact
Matt (preinvent) wrote:
The context I'm being passed may come from a service, widget update
request, activity or broadcast receiver (from the BATTERY_CHANGE
action). Can I be sure that the context points to my application in
all those instances?
What else would it point to?
That's pretty
On Mar 17, 3:58 pm, Mark Murphy mmur...@commonsware.com wrote:
That being said, you should consider whether doing database I/O in the
BroadcastReceiver's onReceive() method is the right answer. That method
is being invoked with foreground priority, which means any time you
spend in that
OK, my app just did this again - wiped my DB and the sharedpreferences
that I set manually using the edit/putstring/commit system. However,
it did NOT wipe the shared preferences set by my PreferenceActivity.
I'm positive they're stored in the same place as I can iterate through
the same shared
Matt (preinvent) wrote:
OK, my app just did this again - wiped my DB and the sharedpreferences
that I set manually using the edit/putstring/commit system.
How did you do this?
However,
it did NOT wipe the shared preferences set by my PreferenceActivity.
I'm positive they're stored in the
OK, my app just did this again - wiped my DB and the sharedpreferences
that I set manually using the edit/putstring/commit system.
How did you do this?
I can't reproduce it - sometimes it just does it. It seems more
likely to happen after a power cycle but I can't make it happen when I
Matt (preinvent) wrote:
OK, my app just did this again - wiped my DB and the sharedpreferences
that I set manually using the edit/putstring/commit system.
How did you do this?
I can't reproduce it - sometimes it just does it.
Sorry, I misread your previous post -- I though you wiped it
Well, it could point to a different application, if you make the
mistake of calling getApplicationContext() rather than
getApplication().
It might usually be the right one, but then one day in another
circumstance be the wrong one.
The only thing you can say is it will be in the same process.
BINGO!
If you're using getDefaultSharedPreferences, you want to use
getApplication() to get the context to supply.
The shared preference file name can differ if you use differing
contexts. You want to use the same context every time, no matter which
activity or service you look at it from. So
getDefaultSharedPreferences() returns the same preferences for every
context, provided that getDefaultSharedPreferencesName() returns the same
thing. The default string returned by getDefaultSharedPreferencesName() is
the package name concatenated with _preferences, which will be the same
for
One thing has just occurred to me. My app contains a service, an
activity and a widget. Depending on what gets updated first, the
database connection is instantiated using a Context from one of these.
If it's instantiated with the Context from say the service, then at
another point it's
I didn't get any corrupt DB errors - it's as if my app was uninstalled
them reinstalled. It worked perfectly after losing all the data but
of course without any of the actual data available.
On Mar 13, 5:21 pm, Yuvi yuvidr...@gmail.com wrote:
Hi,
the database issue happened on my phone (HTC
This just happened yet again earlier today. Unfortunately I didn't
get my Droid hooked up to adb quick enough to look through the logs.
Guess I'll have to wait until next time :(
This is killing me!
On Mar 14, 5:47 pm, Matt (preinvent) m...@preinvent.com wrote:
I didn't get any corrupt DB
For SharedPreferences this isn't unheard of but I'd question an issue
with SQLite. Perhaps users got irritated that things went haywire as a
result of the missing SharedPreferences, and reinstalled the app.
On Mar 13, 2:16 pm, Matt (preinvent) m...@preinvent.com wrote:
I've had several reports
Matt (preinvent) wrote:
This just happened yet again earlier today. Unfortunately I didn't
get my Droid hooked up to adb quick enough to look through the logs.
Guess I'll have to wait until next time :(
This is killing me!
Hopefully not. Dead developers make no sales.
:-)
More seriously,
On Mar 14, 8:31 pm, Mark Murphy mmur...@commonsware.com wrote:
This is killing me!
Hopefully not. Dead developers make no sales.
Neither do developers with unhappy customers!
More seriously, consider hooking into Android Log Collector or
something, so that when you detect this
ForSharedPreferencesthis isn't unheard of but I'd question an issue
with SQLite. Perhaps users got irritated that things went haywire as a
result of the missingSharedPreferences, and reinstalled the app.
This happened to me earlier today on my Droid. I didn't uninstall/
reinstall so I know
41 matches
Mail list logo
