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:
>
> > > > ===================================
> > > > <target name="copy-release-files">
> > > > <copy file="${build.resources}/api-keys-release.xml"
> > > > tofile="$
> > > > {resource-dir}/values/api-keys.xml" overwrite="true"/>
> > > > </target>
>
> > > > <target name="release" depends="copy-release-files, dex, package-
> > > > res">
> > > > ===================================
>
> > > > =======================================
> > > > Buildfile: build.xml
>
> > > > 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.
>
> > > --
> > > Xavier Ducrohet
> > > Android Engineer, Google.
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
