Recently there is a new option "Copy Protection" in Android Market
Developer Console. We thought that was a nice protection on us and
turned it on. Then here comes the impact: our app was no longer
listed & downloadable on ADP, and *MUCH WORSE*, those who can
download have experienced severe force closes when the app starts! We
have confirmed this by just downloading&running the app before and
after that option is turned on.
I have no idea what mechanism Google uses to implement that option,
but it seems they are changing the apk -- the application size is
larger when the option is on.
Seen from the exception trace, it seems it's related to an issue that
I reported before: http://groups.google.com/group/android-developers/browse_thread/threa... It seems the resource is screwed up. Basically findViewById returns a
wrong thing, and in turn you get either NullPointerException or
ClassCastException. We are still not able to use an ant script to
automate the build&sign process, which triggers the bug and gives you
a corrupted apk. However, exporting an unsigned apk using Eclipse and
signing it manually works with no problem.
What a bug,... we have lost 5000+ users due to this. Google should
have tested more carefully it before making it available.
On Sat, Feb 21, 2009 at 6:20 PM, focuser <linto...@gmail.com> wrote:
> Hi fellow developers,
> Recently there is a new option "Copy Protection" in Android Market
> Developer Console. We thought that was a nice protection on us and
> turned it on. Then here comes the impact: our app was no longer
> listed & downloadable on ADP, and *MUCH WORSE*, those who can
> download have experienced severe force closes when the app starts! We
> have confirmed this by just downloading&running the app before and
> after that option is turned on.
> I have no idea what mechanism Google uses to implement that option,
> but it seems they are changing the apk -- the application size is
> larger when the option is on.
> Seen from the exception trace, it seems it's related to an issue that
> I reported before: http://groups.google.com/group/android-developers/browse_thread/threa... > It seems the resource is screwed up. Basically findViewById returns a
> wrong thing, and in turn you get either NullPointerException or
> ClassCastException. We are still not able to use an ant script to
> automate the build&sign process, which triggers the bug and gives you
> a corrupted apk. However, exporting an unsigned apk using Eclipse and
> signing it manually works with no problem.
> What a bug,... we have lost 5000+ users due to this. Google should
> have tested more carefully it before making it available.
> I had users talking about these Force Close issues yesterday and I was
> scratching my head for a long time :O :O O
> Thanks man!
> On Sat, Feb 21, 2009 at 6:20 PM, focuser <linto...@gmail.com> wrote:
> > Hi fellow developers,
> > Recently there is a new option "Copy Protection" in Android Market
> > Developer Console. We thought that was a nice protection on us and
> > turned it on. Then here comes the impact: our app was no longer
> > listed & downloadable on ADP, and *MUCH WORSE*, those who can
> > download have experienced severe force closes when the app starts! We
> > have confirmed this by just downloading&running the app before and
> > after that option is turned on.
> > I have no idea what mechanism Google uses to implement that option,
> > but it seems they are changing the apk -- the application size is
> > larger when the option is on.
> > Seen from the exception trace, it seems it's related to an issue that
> > I reported before:http://groups.google.com/group/android-developers/browse_thread/threa...
> > It seems the resource is screwed up. Basically findViewById returns a
> > wrong thing, and in turn you get either NullPointerException or
> > ClassCastException. We are still not able to use an ant script to
> > automate the build&sign process, which triggers the bug and gives you
> > a corrupted apk. However, exporting an unsigned apk using Eclipse and
> > signing it manually works with no problem.
> > What a bug,... we have lost 5000+ users due to this. Google should
> > have tested more carefully it before making it available.
Something else - 1 of the mysteries just unveiled - both of my apps
which wouldn't show on Cyrket are there now (at least by searching for
them, not in the list yet).
On Sat, Feb 21, 2009 at 6:38 PM, focuser <linto...@gmail.com> wrote:
> good to know that we are not alone. :)
> I have reported this issue through Android Market support and hoping
> they could fix it soon...
> On Feb 21, 8:31 am, Stoyan Damov <stoyan.da...@gmail.com> wrote:
>> :OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
>> I had users talking about these Force Close issues yesterday and I was
>> scratching my head for a long time :O :O O
>> Thanks man!
>> On Sat, Feb 21, 2009 at 6:20 PM, focuser <linto...@gmail.com> wrote:
>> > Hi fellow developers,
>> > Recently there is a new option "Copy Protection" in Android Market
>> > Developer Console. We thought that was a nice protection on us and
>> > turned it on. Then here comes the impact: our app was no longer
>> > listed & downloadable on ADP, and *MUCH WORSE*, those who can
>> > download have experienced severe force closes when the app starts! We
>> > have confirmed this by just downloading&running the app before and
>> > after that option is turned on.
>> > I have no idea what mechanism Google uses to implement that option,
>> > but it seems they are changing the apk -- the application size is
>> > larger when the option is on.
>> > Seen from the exception trace, it seems it's related to an issue that
>> > I reported before:http://groups.google.com/group/android-developers/browse_thread/threa...
> - Show quoted text -
>> > It seems the resource is screwed up. Basically findViewById returns a
>> > wrong thing, and in turn you get either NullPointerException or
>> > ClassCastException. We are still not able to use an ant script to
>> > automate the build&sign process, which triggers the bug and gives you
>> > a corrupted apk. However, exporting an unsigned apk using Eclipse and
>> > signing it manually works with no problem.
>> > What a bug,... we have lost 5000+ users due to this. Google should
>> > have tested more carefully it before making it available.
> Seen from the exception trace, it seems it's related to an issue that > I reported before: > http://groups.google.com/group/android-developers/browse_thread/threa... > It seems the resource is screwed up. Basically findViewById returns a > wrong thing, and in turn you get either NullPointerException or > ClassCastException. We are still not able to use an ant script to > automate the build&sign process, which triggers the bug and gives you > a corrupted apk. However, exporting an unsigned apk using Eclipse and > signing it manually works with no problem.
1. Why are you "still not able to use an ant script to automate the build&sign process"?
2. If you aren't able to do #1, how do you know it "triggers the bug and gives you a corrupted apk"?
3. Do you have a reproducible scenario you can publish with code? Or does the phenomenon only occur with this one app?
> What a bug,... we have lost 5000+ users due to this. Google should > have tested more carefully it before making it available.
I realize you are frustrated, and that is understandable under the circumstances. However, at this point, we don't know much. We know in this one specific instance for this one specific app we get this one specific condition. What we need is a way to reproduce this problem on demand for an open source app, so we can get a better feel for what is going on. Only when we know where the problem lies will we know truly who is to blame.
Any more information you can provide, such as answers to the preceding questions, will be helpful.
-- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 2.0 Available!
> I realize you are frustrated, and that is understandable under the > circumstances. However, at this point, we don't know much. We know in this > one specific instance for this one specific app we get this one specific > condition. What we need is a way to reproduce this problem on demand for > an open source app, so we can get a better feel for what is going on. Only > when we know where the problem lies will we know truly who is to blame.
And at the risk of replying to myself, since other reports have come in while I was typing my previous message, the odds of a "copy protection"-specific problem have risen...but we still need a way to reproduce it.
If anyone sees this problem and has some code that demonstrates it that they are willing to release, post it here, in the bug tracker (b.android.com), or both.
-- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 2.0 Available!
I think this is related to the restriction that an app with copy
protection on cannot be downloaded to an unlocked phone, i.e. ADP. We
have seen that too before turning the option off.
On Feb 21, 8:40 am, Stoyan Damov <stoyan.da...@gmail.com> wrote:
> Something else - 1 of the mysteries just unveiled - both of my apps
> which wouldn't show on Cyrket are there now (at least by searching for
> them, not in the list yet).
> On Sat, Feb 21, 2009 at 6:38 PM, focuser <linto...@gmail.com> wrote:
> > good to know that we are not alone. :)
> > I have reported this issue through Android Market support and hoping
> > they could fix it soon...
> > On Feb 21, 8:31 am, Stoyan Damov <stoyan.da...@gmail.com> wrote:
> >> :OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
> >> I had users talking about these Force Close issues yesterday and I was
> >> scratching my head for a long time :O :O O
> >> Thanks man!
> >> On Sat, Feb 21, 2009 at 6:20 PM, focuser <linto...@gmail.com> wrote:
> >> > Hi fellow developers,
> >> > Recently there is a new option "Copy Protection" in Android Market
> >> > Developer Console. We thought that was a nice protection on us and
> >> > turned it on. Then here comes the impact: our app was no longer
> >> > listed & downloadable on ADP, and *MUCH WORSE*, those who can
> >> > download have experienced severe force closes when the app starts! We
> >> > have confirmed this by just downloading&running the app before and
> >> > after that option is turned on.
> >> > I have no idea what mechanism Google uses to implement that option,
> >> > but it seems they are changing the apk -- the application size is
> >> > larger when the option is on.
> >> > Seen from the exception trace, it seems it's related to an issue that
> >> > I reported before:http://groups.google.com/group/android-developers/browse_thread/threa...
> > - Show quoted text -
> >> > It seems the resource is screwed up. Basically findViewById returns a
> >> > wrong thing, and in turn you get either NullPointerException or
> >> > ClassCastException. We are still not able to use an ant script to
> >> > automate the build&sign process, which triggers the bug and gives you
> >> > a corrupted apk. However, exporting an unsigned apk using Eclipse and
> >> > signing it manually works with no problem.
> >> > What a bug,... we have lost 5000+ users due to this. Google should
> >> > have tested more carefully it before making it available.
On Feb 21, 8:42 am, "Mark Murphy" <mmur...@commonsware.com> wrote:
> 1. Why are you "still not able to use an ant script to automate the
> build&sign process"?
> 2. If you aren't able to do #1, how do you know it "triggers the bug and
> gives you a corrupted apk"?
OK, to clarify: If the ant script is used to sign the apk, it might
produce a corrupted apk, i.e. throwing ClassCastException or
NullPointerException at some point. This seems not happening all the
time though. However, if I export an unsigned apk using Eclipse and
sign it manually on the exactly same source code, everything is fine.
So we had to give up using the ant script.
The only "fancy" thing we do in the build script is to copy an xml
that has the release Google Maps api key into res/values. But I think
this should have no impact since the copy happens before compilation
and the R.java will be regenerated by the build script:
copy-release-files:
[copy] Copying 1 file to /workspaces/android-ws/theProject/res/
values
dirs:
[echo] Creating output directories if needed...
[mkdir] Created dir: /workspaces/android-ws/theProject/bin-build
[mkdir] Created dir: /workspaces/android-ws/theProject/bin-build/
classes
resource-src:
[echo] Generating R.java / Manifest.java from the resources...
[exec] (skipping hidden file 'res/drawable/.DS_Store')
...
=======================================
I'm not saying this is the same issue as the copy protection. Just
they look very related.
> 3. Do you have a reproducible scenario you can publish with code? Or does
> the phenomenon only occur with this one app?
We have not put any effort to reproduce the problem in other code base
since we can still export and sign the apk manually without any
problems. We will submit the code if we find a way to reproduce it.
On Sat, Feb 21, 2009 at 9:51 AM, focuser <linto...@gmail.com> wrote:
> On Feb 21, 8:42 am, "Mark Murphy" <mmur...@commonsware.com> wrote:
>> 1. Why are you "still not able to use an ant script to automate the
>> build&sign process"?
>> 2. If you aren't able to do #1, how do you know it "triggers the bug and
>> gives you a corrupted apk"?
> OK, to clarify: If the ant script is used to sign the apk, it might
> produce a corrupted apk, i.e. throwing ClassCastException or
> NullPointerException at some point. This seems not happening all the
> time though. However, if I export an unsigned apk using Eclipse and
> sign it manually on the exactly same source code, everything is fine.
> So we had to give up using the ant script.
> The only "fancy" thing we do in the build script is to copy an xml
> that has the release Google Maps api key into res/values. But I think
> this should have no impact since the copy happens before compilation
> and the R.java will be regenerated by the build script:
> I'm not saying this is the same issue as the copy protection. Just
> they look very related.
>> 3. Do you have a reproducible scenario you can publish with code? Or does
>> the phenomenon only occur with this one app?
> We have not put any effort to reproduce the problem in other code base
> since we can still export and sign the apk manually without any
> problems. We will submit the code if we find a way to reproduce it.
Yes, it's probably not related to copy protection because I've had
users complaining of "Force close" issues w/ the latest update.
On top of that, I just go an e-mail saying:
"I am trying to update my game but perhaps your data connection is
weak . It seems to go on and on and takes forever to update . "
Now hey, guys @ Google, why wouldn't you put some help in the Market
application explaining how network and installation issues couldn't
possibly be *our* fault.
And DON'T TELL ME that there's help online for whoever wanted to see
it because I am starting to read Douglas Adams here and that the plans
for the Earth's destruction being on Alpha Centaurus for 2 million
years (or whatever it was).
On Sat, Feb 21, 2009 at 8:13 PM, focuser <linto...@gmail.com> wrote:
>> 2. If you aren't able to do #1, how do you know it "triggers the bug and
>> gives you a corrupted apk"?
> To further clarify, :) "the bug" I mentioned is not necessarily the
> bug with copy protection. It's the problem we see when using the ant
> build script.
> - Show quoted text -
There's no error whatsoever when that happens. Apk was successfully
created and signed just as if everything was fine. But when you
install and run the apk, you will see the errors.
I will try to see if I could reproduce the problem with a smaller code
base.
On Feb 21, 1:20 pm, Xavier Ducrohet <x...@android.com> wrote:
> do you have an output from Ant when the error happens?
> Ant and Eclipse use mostly the same code to generate the apk, so I'm a
> bit surprised to see this.
> thanks
> Xav
> On Sat, Feb 21, 2009 at 9:51 AM, focuser <linto...@gmail.com> wrote:
> > On Feb 21, 8:42 am, "Mark Murphy" <mmur...@commonsware.com> wrote:
> >> 1. Why are you "still not able to use an ant script to automate the
> >> build&sign process"?
> >> 2. If you aren't able to do #1, how do you know it "triggers the bug and
> >> gives you a corrupted apk"?
> > OK, to clarify: If the ant script is used to sign the apk, it might
> > produce a corrupted apk, i.e. throwing ClassCastException or
> > NullPointerException at some point. This seems not happening all the
> > time though. However, if I export an unsigned apk using Eclipse and
> > sign it manually on the exactly same source code, everything is fine.
> > So we had to give up using the ant script.
> > The only "fancy" thing we do in the build script is to copy an xml
> > that has the release Google Maps api key into res/values. But I think
> > this should have no impact since the copy happens before compilation
> > and the R.java will be regenerated by the build script:
> > I'm not saying this is the same issue as the copy protection. Just
> > they look very related.
> >> 3. Do you have a reproducible scenario you can publish with code? Or does
> >> the phenomenon only occur with this one app?
> > We have not put any effort to reproduce the problem in other code base
> > since we can still export and sign the apk manually without any
> > problems. We will submit the code if we find a way to reproduce it.
I can confirm that there is a bug with the "forward locking" on the
Android Market. The problem I've experienced is that users upgrading
from an unlocked version of Locale to a locked version of Locale are
experiencing a crash when opening the app. The failure is that the
app can't open its ContentProvider (a call to
SQLiteOpenHelper.getWritableDatabase() fails). As an experiment, I
tried wrapping the section in a try-catch and to use a new database
file name. My thought was that the old sqlite file might be
unreadable because of permissions or other problems. This didn't work
though.
In your apps, you should be able to reproduce this bug by doing a
plain old "adb install myapp.apk", open the app on the phone, then do
an "adb install -l -r myapp.apk". The -l option enables forward-
locking. When you re-open the app of the device, you should see the
problem reproduce. This problem also occurs both ways, so users who
successfully installed the locked version of the app will see a crash
if the next version of the app is unlocked.
I've also contacted someone at Google about this, so we'll see what
happens.
On Feb 21, 4:43 pm, focuser <linto...@gmail.com> wrote:
> There's no error whatsoever when that happens. Apk was successfully
> created and signed just as if everything was fine. But when you
> install and run the apk, you will see the errors.
> I will try to see if I could reproduce the problem with a smaller code
> base.
> On Feb 21, 1:20 pm, Xavier Ducrohet <x...@android.com> wrote:
> > Hello,
> > do you have an output from Ant when the error happens?
> > Ant and Eclipse use mostly the same code to generate the apk, so I'm a
> > bit surprised to see this.
> > thanks
> > Xav
> > On Sat, Feb 21, 2009 at 9:51 AM, focuser <linto...@gmail.com> wrote:
> > > On Feb 21, 8:42 am, "Mark Murphy" <mmur...@commonsware.com> wrote:
> > >> 1. Why are you "still not able to use an ant script to automate the
> > >> build&sign process"?
> > >> 2. If you aren't able to do #1, how do you know it "triggers the bug and
> > >> gives you a corrupted apk"?
> > > OK, to clarify: If the ant script is used to sign the apk, it might
> > > produce a corrupted apk, i.e. throwing ClassCastException or
> > > NullPointerException at some point. This seems not happening all the
> > > time though. However, if I export an unsigned apk using Eclipse and
> > > sign it manually on the exactly same source code, everything is fine.
> > > So we had to give up using the ant script.
> > > The only "fancy" thing we do in the build script is to copy an xml
> > > that has the release Google Maps api key into res/values. But I think
> > > this should have no impact since the copy happens before compilation
> > > and the R.java will be regenerated by the build script:
> > > I'm not saying this is the same issue as the copy protection. Just
> > > they look very related.
> > >> 3. Do you have a reproducible scenario you can publish with code? Or does
> > >> the phenomenon only occur with this one app?
> > > We have not put any effort to reproduce the problem in other code base
> > > since we can still export and sign the apk manually without any
> > > problems. We will submit the code if we find a way to reproduce it.
confirmed. If you first install an apk unlocked, and then install a
locked one, you will get that sqlite exception. also, the old
preferences seems to be deleted after the locked apk is installed.
Another thing is, even installed locked from scratch (uninstall and
adb install -l), there are some problems with resources. Our app
displays an HTML page when it starts, but now I get "Web page not
available: file:///android_asset/welcome.html ...". This works fine
if it's installed unlocked.
This might explain the resource problem that I had before?
On Feb 22, 9:18 am, Carter <ccjerni...@gmail.com> wrote:
> I can confirm that there is a bug with the "forward locking" on the
> Android Market. The problem I've experienced is that users upgrading
> from an unlocked version of Locale to a locked version of Locale are
> experiencing a crash when opening the app. The failure is that the
> app can't open its ContentProvider (a call to
> SQLiteOpenHelper.getWritableDatabase() fails). As an experiment, I
> tried wrapping the section in a try-catch and to use a new database
> file name. My thought was that the old sqlite file might be
> unreadable because of permissions or other problems. This didn't work
> though.
> In your apps, you should be able to reproduce this bug by doing a
> plain old "adb install myapp.apk", open the app on the phone, then do
> an "adb install -l -r myapp.apk". The -l option enables forward-
> locking. When you re-open the app of the device, you should see the
> problem reproduce. This problem also occurs both ways, so users who
> successfully installed the locked version of the app will see a crash
> if the next version of the app is unlocked.
> I've also contacted someone at Google about this, so we'll see what
> happens.
> On Feb 21, 4:43 pm, focuser <linto...@gmail.com> wrote:
> > There's no error whatsoever when that happens. Apk was successfully
> > created and signed just as if everything was fine. But when you
> > install and run the apk, you will see the errors.
> > I will try to see if I could reproduce the problem with a smaller code
> > base.
> > On Feb 21, 1:20 pm, Xavier Ducrohet <x...@android.com> wrote:
> > > Hello,
> > > do you have an output from Ant when the error happens?
> > > Ant and Eclipse use mostly the same code to generate the apk, so I'm a
> > > bit surprised to see this.
> > > thanks
> > > Xav
> > > On Sat, Feb 21, 2009 at 9:51 AM, focuser <linto...@gmail.com> wrote:
> > > > On Feb 21, 8:42 am, "Mark Murphy" <mmur...@commonsware.com> wrote:
> > > >> 1. Why are you "still not able to use an ant script to automate the
> > > >> build&sign process"?
> > > >> 2. If you aren't able to do #1, how do you know it "triggers the bug and
> > > >> gives you a corrupted apk"?
> > > > OK, to clarify: If the ant script is used to sign the apk, it might
> > > > produce a corrupted apk, i.e. throwing ClassCastException or
> > > > NullPointerException at some point. This seems not happening all the
> > > > time though. However, if I export an unsigned apk using Eclipse and
> > > > sign it manually on the exactly same source code, everything is fine.
> > > > So we had to give up using the ant script.
> > > > The only "fancy" thing we do in the build script is to copy an xml
> > > > that has the release Google Maps api key into res/values. But I think
> > > > this should have no impact since the copy happens before compilation
> > > > and the R.java will be regenerated by the build script:
> > > > I'm not saying this is the same issue as the copy protection. Just
> > > > they look very related.
> > > >> 3. Do you have a reproducible scenario you can publish with code? Or does
> > > >> the phenomenon only occur with this one app?
> > > > We have not put any effort to reproduce the problem in other code base
> > > > since we can still export and sign the apk manually without any
> > > > problems. We will submit the code if we find a way to reproduce it.
focuser wrote: > 02-22 09:57:00.242: ERROR/AndroidRuntime(25948): Uncaught handler: > thread WebViewCoreThread exiting due to uncaught exception > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): > android.database.sqlite.SQLiteException: unable to open database file > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at > android.database.sqlite.SQLiteDatabase.dbopen(Native Method) > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at > android.database.sqlite.SQLiteDatabase.<init>(SQLiteDatabase.java: > 1421) > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at > android.database.sqlite.SQLiteDatabase.openDatabase > (SQLiteDatabase.java:537) > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at > android.database.sqlite.SQLiteDatabase.openOrCreateDatabase > (SQLiteDatabase.java:558) > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at > android.database.sqlite.SQLiteDatabase.openOrCreateDatabase > (SQLiteDatabase.java:551) > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at > android.app.ApplicationContext.openOrCreateDatabase > (ApplicationContext.java:427) > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at > android.content.ContextWrapper.openOrCreateDatabase > (ContextWrapper.java:181) > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at > android.webkit.WebViewDatabase.getInstance(WebViewDatabase.java:167) > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at > android.webkit.CacheManager.init(CacheManager.java:146) > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at > android.webkit.BrowserFrame.<init>(BrowserFrame.java:112) > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at > android.webkit.WebViewCore.initialize(WebViewCore.java:168) > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at > android.webkit.WebViewCore.access$400(WebViewCore.java:43) > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at > android.webkit.WebViewCore$WebCoreThread$1.handleMessage > (WebViewCore.java:425) > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at > android.os.Handler.dispatchMessage(Handler.java:88) > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at > android.os.Looper.loop(Looper.java:123) > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at > android.webkit.WebViewCore$WebCoreThread.run(WebViewCore.java:468) > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at > java.lang.Thread.run(Thread.java:935)
Ick.
That's not even your app's database, if I'm reading this stack trace correctly -- it's one used by WebView. I was hoping it would be your database and a more useful error message than simply "unable to open database file".
That's correct, it's not my app's database. But my app uses a WebView
and just stops there. Write anything that uses a WebView (or uses
sqlite) and you should see the problem.
The following is everything I got in LogCat's error view:
02-22 10:43:59.242: ERROR/Database(27448): sqlite3_open_v2("/data/data/
crashtest.test/databases/webview.db", &handle, 6, NULL) failed
02-22 10:43:59.262: ERROR/AndroidRuntime(27448): Uncaught handler:
thread WebViewCoreThread exiting due to uncaught exception
02-22 10:43:59.282: ERROR/AndroidRuntime(27448):
android.database.sqlite.SQLiteException: unable to open database file
02-22 10:43:59.282: ERROR/AndroidRuntime(27448): at
android.database.sqlite.SQLiteDatabase.dbopen(Native Method)
02-22 10:43:59.282: ERROR/AndroidRuntime(27448): at
android.database.sqlite.SQLiteDatabase.<init>(SQLiteDatabase.java:
1421)
02-22 10:43:59.282: ERROR/AndroidRuntime(27448): at
android.database.sqlite.SQLiteDatabase.openDatabase
(SQLiteDatabase.java:537)
02-22 10:43:59.282: ERROR/AndroidRuntime(27448): at
android.database.sqlite.SQLiteDatabase.openOrCreateDatabase
(SQLiteDatabase.java:558)
02-22 10:43:59.282: ERROR/AndroidRuntime(27448): at
android.database.sqlite.SQLiteDatabase.openOrCreateDatabase
(SQLiteDatabase.java:551)
02-22 10:43:59.282: ERROR/AndroidRuntime(27448): at
android.app.ApplicationContext.openOrCreateDatabase
(ApplicationContext.java:427)
02-22 10:43:59.282: ERROR/AndroidRuntime(27448): at
android.content.ContextWrapper.openOrCreateDatabase
(ContextWrapper.java:181)
02-22 10:43:59.282: ERROR/AndroidRuntime(27448): at
android.webkit.WebViewDatabase.getInstance(WebViewDatabase.java:167)
02-22 10:43:59.282: ERROR/AndroidRuntime(27448): at
android.webkit.CacheManager.init(CacheManager.java:146)
02-22 10:43:59.282: ERROR/AndroidRuntime(27448): at
android.webkit.BrowserFrame.<init>(BrowserFrame.java:112)
02-22 10:43:59.282: ERROR/AndroidRuntime(27448): at
android.webkit.WebViewCore.initialize(WebViewCore.java:168)
02-22 10:43:59.282: ERROR/AndroidRuntime(27448): at
android.webkit.WebViewCore.access$400(WebViewCore.java:43)
02-22 10:43:59.282: ERROR/AndroidRuntime(27448): at
android.webkit.WebViewCore$WebCoreThread$1.handleMessage
(WebViewCore.java:425)
02-22 10:43:59.282: ERROR/AndroidRuntime(27448): at
android.os.Handler.dispatchMessage(Handler.java:88)
02-22 10:43:59.282: ERROR/AndroidRuntime(27448): at
android.os.Looper.loop(Looper.java:123)
02-22 10:43:59.282: ERROR/AndroidRuntime(27448): at
android.webkit.WebViewCore$WebCoreThread.run(WebViewCore.java:468)
02-22 10:43:59.282: ERROR/AndroidRuntime(27448): at
java.lang.Thread.run(Thread.java:935)
On Feb 22, 10:07 am, Mark Murphy <mmur...@commonsware.com> wrote:
> focuser wrote:
> > 02-22 09:57:00.242: ERROR/AndroidRuntime(25948): Uncaught handler:
> > thread WebViewCoreThread exiting due to uncaught exception
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948):
> > android.database.sqlite.SQLiteException: unable to open database file
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at
> > android.database.sqlite.SQLiteDatabase.dbopen(Native Method)
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at
> > android.database.sqlite.SQLiteDatabase.<init>(SQLiteDatabase.java:
> > 1421)
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at
> > android.database.sqlite.SQLiteDatabase.openDatabase
> > (SQLiteDatabase.java:537)
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at
> > android.database.sqlite.SQLiteDatabase.openOrCreateDatabase
> > (SQLiteDatabase.java:558)
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at
> > android.database.sqlite.SQLiteDatabase.openOrCreateDatabase
> > (SQLiteDatabase.java:551)
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at
> > android.app.ApplicationContext.openOrCreateDatabase
> > (ApplicationContext.java:427)
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at
> > android.content.ContextWrapper.openOrCreateDatabase
> > (ContextWrapper.java:181)
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at
> > android.webkit.WebViewDatabase.getInstance(WebViewDatabase.java:167)
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at
> > android.webkit.CacheManager.init(CacheManager.java:146)
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at
> > android.webkit.BrowserFrame.<init>(BrowserFrame.java:112)
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at
> > android.webkit.WebViewCore.initialize(WebViewCore.java:168)
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at
> > android.webkit.WebViewCore.access$400(WebViewCore.java:43)
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at
> > android.webkit.WebViewCore$WebCoreThread$1.handleMessage
> > (WebViewCore.java:425)
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at
> > android.os.Handler.dispatchMessage(Handler.java:88)
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at
> > android.os.Looper.loop(Looper.java:123)
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at
> > android.webkit.WebViewCore$WebCoreThread.run(WebViewCore.java:468)
> > 02-22 09:57:00.272: ERROR/AndroidRuntime(25948): at
> > java.lang.Thread.run(Thread.java:935)
> Ick.
> That's not even your app's database, if I'm reading this stack trace
> correctly -- it's one used by WebView. I was hoping it would be your
> database and a more useful error message than simply "unable to open
> database file".
Crap. I was hoping it would log the return code from that function call.
6 is SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE, which is pretty much as one might expect. The NULL fourth parameter just means we're using the stock SQLite vfs.
Have you tried opening one of those databases using sqlite3 (either on-device or on your dev machine after pulling it off) to see if it gives you any additional clues as to what is considered wrong with it?
Below is the stack trace from Locale when this problem reproduces.
The JavaDocs suggest that file permissions or a full disk might be the
cause. I've confirmed that disk space isn't the problem.
02-21 00:21:47.652: ERROR/AndroidRuntime(349):
java.lang.RuntimeException: Unable to get provider
edu.mit.locale.providers.LocaleProvider:
android.database.sqlite.SQLiteException: unable to open database file
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.app.ActivityThread.installProvider(ActivityThread.java:3648)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.app.ActivityThread.installContentProviders(ActivityThread.java:
3450)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.app.ActivityThread.handleBindApplication(ActivityThread.java:
3409)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.app.ActivityThread.access$2500(ActivityThread.java:112)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.app.ActivityThread$H.handleMessage(ActivityThread.java:1617)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.os.Handler.dispatchMessage(Handler.java:88)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.os.Looper.loop(Looper.java:123)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.app.ActivityThread.main(ActivityThread.java:3739)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
java.lang.reflect.Method.invokeNative(Native Method)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
java.lang.reflect.Method.invoke(Method.java:515)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
(ZygoteInit.java:739)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:497)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
dalvik.system.NativeStart.main(Native Method)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): Caused by:
android.database.sqlite.SQLiteException: unable to open database file
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.database.sqlite.SQLiteDatabase.dbopen(Native Method)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.database.sqlite.SQLiteDatabase.<init>(SQLiteDatabase.java:
1421)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.database.sqlite.SQLiteDatabase.openDatabase
(SQLiteDatabase.java:537)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.database.sqlite.SQLiteDatabase.openOrCreateDatabase
(SQLiteDatabase.java:558)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.database.sqlite.SQLiteDatabase.openOrCreateDatabase
(SQLiteDatabase.java:551)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.app.ApplicationContext.openOrCreateDatabase
(ApplicationContext.java:427)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.content.ContextWrapper.openOrCreateDatabase
(ContextWrapper.java:181)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.database.sqlite.SQLiteOpenHelper.getWritableDatabase
(SQLiteOpenHelper.java:98)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
edu.mit.locale.providers.LocaleProvider.onCreate(LocaleProvider.java:
264)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.content.ContentProvider.attachInfo(ContentProvider.java:559)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): at
android.app.ActivityThread.installProvider(ActivityThread.java:3645)
02-21 00:21:47.652: ERROR/AndroidRuntime(349): ... 12 more
On Feb 22, 1:56 pm, Mark Murphy <mmur...@commonsware.com> wrote:
> Crap. I was hoping it would log the return code from that function call.
> 6 is SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE, which is pretty much as
> one might expect. The NULL fourth parameter just means we're using the
> stock SQLite vfs.
> Have you tried opening one of those databases using sqlite3 (either
> on-device or on your dev machine after pulling it off) to see if it
> gives you any additional clues as to what is considered wrong with it?
> Crap. I was hoping it would log the return code from that function call.
> 6 is SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE, which is pretty much as
> one might expect. The NULL fourth parameter just means we're using the
> stock SQLite vfs.
> Have you tried opening one of those databases using sqlite3 (either
> on-device or on your dev machine after pulling it off) to see if it
> gives you any additional clues as to what is considered wrong with it?
focuser wrote: > Mark, I created a test project that reproduces three problems with > forward-lock, where should I upload it?
I don't see an issue on http://b.android.com referencing forward-lock. I recommend you start an issue, with the information you've supplied here, and attach a ZIP of the test project. Post the issue link here, so folk like me know which issue it is and can take a look at your project.
-- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 2.0 Available!
> focuser wrote:
> > Mark, I created a test project that reproduces three problems with
> > forward-lock, where should I upload it?
> I don't see an issue onhttp://b.android.comreferencing forward-lock. I
> recommend you start an issue, with the information you've supplied here,
> and attach a ZIP of the test project. Post the issue link here, so folk
> like me know which issue it is and can take a look at your project.
> --
> Mark Murphy (a Commons Guy)http://commonsware.com > _The Busy Coder's Guide to Android Development_ Version 2.0 Available!
I'm been tracking down this exact issue with my app and it matches
what "focuser" describes.
I turned on copy protection on a free app. People started getting
crashes.
The app starts with a help activity containing a webview.
This web view is now throwing an exception trying to access a sqlite
webview.db database on it's own thread and crashing.
In addition, this help activity only starts up if there are no
settings but even upgrades are getting this activity now.
It problem extends to other android APIs as well because if I avoid
the webview, it still crashes in other APIs.
In summary, if you change copy protection for your app:
1. user preferences will be wiped
2. webview will crash
3. other APIs will crash
Removing copy protection does not help because now I've got some users
with and without copy protection and changes in either direction
causes the problem. Argh...
rob
On Feb 22, 9:55 am, focuser <linto...@gmail.com> wrote:
> confirmed. If you first install an apk unlocked, and then install a
> locked one, you will get that sqlite exception. also, the old
> preferences seems to be deleted after the locked apk is installed.
> Another thing is, even installed locked from scratch (uninstall and
> adb install -l), there are some problems with resources. Our app
> displays an HTML page when it starts, but now I get "Web page not
> available:file:///android_asset/welcome.html ...". This works fine
> if it's installed unlocked.
> This might explain the resource problem that I had before?
> On Feb 22, 9:18 am, Carter <ccjerni...@gmail.com> wrote:
> > I can confirm that there is a bug with the "forward locking" on the
> > Android Market. The problem I've experienced is that users upgrading
> > from an unlocked version of Locale to a locked version of Locale are
> > experiencing a crash when opening the app. The failure is that the
> > app can'topenits ContentProvider (a call to
> > SQLiteOpenHelper.getWritableDatabase() fails). As an experiment, I
> > tried wrapping the section in a try-catch and to use a newdatabase
> >filename. My thought was that the old sqlitefilemight be
> > unreadable because of permissions or other problems. This didn't work
> > though.
> > In your apps, you should be able to reproduce this bug by doing a
> > plain old "adb install myapp.apk",openthe app on the phone, then do
> > an "adb install -l -r myapp.apk". The -l option enables forward-
> > locking. When you re-openthe app of the device, you should see the
> > problem reproduce. This problem also occurs both ways, so users who
> > successfully installed the locked version of the app will see a crash
> > if the next version of the app is unlocked.
> > I've also contacted someone at Google about this, so we'll see what
> > happens.
> > On Feb 21, 4:43 pm, focuser <linto...@gmail.com> wrote:
> > > There's no error whatsoever when that happens. Apk was successfully
> > > created and signed just as if everything was fine. But when you
> > > install and run the apk, you will see the errors.
> > > I will try to see if I could reproduce the problem with a smaller code
> > > base.
> > > On Feb 21, 1:20 pm, Xavier Ducrohet <x...@android.com> wrote:
> > > > Hello,
> > > > do you have an output from Ant when the error happens?
> > > > Ant and Eclipse use mostly the same code to generate the apk, so I'm a
> > > > bit surprised to see this.
> > > > thanks
> > > > Xav
> > > > On Sat, Feb 21, 2009 at 9:51 AM, focuser <linto...@gmail.com> wrote:
> > > > > On Feb 21, 8:42 am, "Mark Murphy" <mmur...@commonsware.com> wrote:
> > > > >> 1. Why are you "still not able to use an ant script to automate the
> > > > >> build&sign process"?
> > > > >> 2. If you aren't able to do #1, how do you know it "triggers the bug and
> > > > >> gives you a corrupted apk"?
> > > > > OK, to clarify: If the ant script is used to sign the apk, it might
> > > > > produce a corrupted apk, i.e. throwing ClassCastException or
> > > > > NullPointerException at some point. This seems not happening all the
> > > > > time though. However, if I export an unsigned apk using Eclipse and
> > > > > sign it manually on the exactly same source code, everything is fine.
> > > > > So we had to give up using the ant script.
> > > > > The only "fancy" thing we do in the build script is to copy an xml
> > > > > that has the release Google Maps api key into res/values. But I think
> > > > > this should have no impact since the copy happens before compilation
> > > > > and the R.java will be regenerated by the build script:
> > > > > I'm not saying this is the same issue as the copy protection. Just
> > > > > they look very related.
> > > > >> 3. Do you have a reproducible scenario you can publish with code? Or does
> > > > >> the phenomenon only occur with this one app?
> > > > > We have not put any effort to reproduce the problem in other code base
> > > > > since we can still export and sign the apk manually without any
> > > > > problems. We will submit the code if we find a way to reproduce it.
|
