I'm in production, and "always" is a strong word. I have galaxy s3 users on tmobile that can upgrade without issue and s3 users on att that cannot due to "improperly signed apk". I ran into this issue 3 years ago when manually resigning as well. For me, i have no issues on any test devices and android market didn't complain regarding the apk, but there's still a signing issue present for some users, including removing the old version of the app and simply trying to reinstall instead of upgrade.
On Wed, Jan 8, 2014 at 11:46 AM, Perry Nguyen <[email protected]> wrote: > Manual re-signing always works, as well. > > > On Wed, Jan 8, 2014 at 9:45 AM, Perry Nguyen <[email protected]> wrote: > >> And you have never indicated whether removing classes.dex works >> >> a release has nothing to do with a debug build, particularly in 1.2.5 >> >> >> On Wed, Jan 8, 2014 at 9:45 AM, Perry Nguyen <[email protected]> wrote: >> >>> bad file, cannot be unpacked. >>> >>> >>> On Wed, Jan 8, 2014 at 9:09 AM, Daniel Skinner <[email protected]> wrote: >>> >>>> bleh, link that works >>>> https://www.dropbox.com/s/xfhd7r05vgdtaj6/share.tar.gz >>>> >>>> >>>> On Wed, Jan 8, 2014 at 11:05 AM, Daniel Skinner <[email protected]> wrote: >>>> >>>>> Thanks, was a busy week for me last. I tried 1.2.5 but it doesn't >>>>> resolve anything. I tried a local install/fork of the android sdk plugin >>>>> to >>>>> do similar without much luck, but as promised >>>>> >>>>> >>>>> https://drive.google.com/a/dasa.cc/file/d/0B6hxg-gC2Uz_SDhMMFlpUHZSMnc/edit?usp=sharing >>>>> >>>>> There's an archive demonstrating the exact problem. The archive is >>>>> still pointing to 1.2.4 in the plugins file. Setup a key for signing and >>>>> such. To produce a clean build >>>>> >>>>> ~ $ sbt >>>>> android:package-debug >>>>> android:install >>>>> >>>>> Producing a release build doesn't work and manually signing seems to >>>>> *not* be much of an option b/c im seeing issues on similar devices, >>>>> different networks, where some users can upgrade and other's can't. So >>>>> random reader beware .. >>>>> >>>>> >>>>> On Monday, January 6, 2014 7:07:27 AM UTC-6, pfn wrote: >>>>> >>>>>> anyway, I've released 1.2.5 which will also force a clean dex on >>>>>> every release build >>>>>> >>>>>> >>>>>> On Wed, Jan 1, 2014 at 12:06 PM, Perry Nguyen <[email protected]>wrote: >>>>>> >>>>>>> indeed, I suppose the dex file might need to be removed for a >>>>>>> release build (when switching back and forth) >>>>>>> >>>>>>> >>>>>>> On Wed, Jan 1, 2014 at 10:52 AM, Daniel Skinner <[email protected]>wrote: >>>>>>> >>>>>>>> I'm guessing this is related here >>>>>>>> https://github.com/pfn/android-sdk-plugin/blob/ >>>>>>>> master/src/tasks.scala#L947 >>>>>>>> >>>>>>>> >>>>>>>> On Wednesday, January 1, 2014 12:35:40 PM UTC-6, pfn wrote: >>>>>>>> >>>>>>>>> same rules are applied regardless of build type >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Jan 1, 2014 at 10:23 AM, Daniel Skinner <[email protected]>wrote: >>>>>>>>> >>>>>>>>>> I'm using the pfn/android-sdk-plugin and I don't think this is >>>>>>>>>> any fault of the plugin but i have an app that depends on >>>>>>>>>> https://code.google.com/p/aacdecoder-android/ which i already >>>>>>>>>> have compiled into a jar and dropped into libs. >>>>>>>>>> >>>>>>>>>> Debug builds work just fine but release builds cause the native >>>>>>>>>> lib to seg fault and having previously carried this over from a >>>>>>>>>> non-proguard project, I was thinking there are differing options set >>>>>>>>>> by the >>>>>>>>>> plugin based on build type (debug/release). >>>>>>>>>> >>>>>>>>>> I only noticed this single file in the repo for configuring >>>>>>>>>> proguard: https://github.com/pfn/android-sdk-plugin/blob/mas >>>>>>>>>> ter/resources/android-proguard.config >>>>>>>>>> >>>>>>>>>> but might i be on the right track here? Or does the plugin apply >>>>>>>>>> the same rules regardless of build type? Digging into the source now >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>> Google Groups "scala-on-android" group. >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>>> send an email to [email protected]. >>>>>>>>>> >>>>>>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "scala-on-android" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "scala-on-android" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/scala-on-android/y_O8oSwDDTo/unsubscribe >>>>> . >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> [email protected]. >>>>> >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "scala-on-android" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "scala-on-android" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/scala-on-android/y_O8oSwDDTo/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "scala-on-android" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
