cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: [Android] CB-8976, CB-8453 and is there anyone building multiple APKs
Date Thu, 03 Mar 2016 20:23:26 GMT
OK, Last call on this.

I'm deleting a bunch of the code that's not related to Crosswalk.  That
said, it's going to make this obsolete:
https://software.intel.com/en-us/xdk/articles/android-and-crosswalk-cordova-version-code-issues

We're not going to do the stupid minSDK mapping anymore because it's
counter to the philosophy of the Cordova project, and it should have never
been done to begin with.  However, we're keeping the modification to the
version codes if you're using Crosswalk.

So, if you're releasing without crosswalk, and you set your version code to
1, here's what's going to happen:
android-release.apk = Version Code 1

If you're releasing WITH CROSSWALK, here's what's going to happen:
android-armv7-release.apk = Version Code 12
android-x86-release.apk = Version Code 14

If you add Crosswalk to a project somewhere along the line, know that
you're going to have to multiply your version code by 10.  I hope this
doesn't go past maxInt, but it's the only way I can think of to give
developers back the control they lost with the earlier version code issues.

If this breaks your stuff, or causes you to have a massive problem (i.e.
You're at version 12, and you somehow have a collision with your Crosswalk
version because you didn't set your sdk version), please let me know now.

On Wed, Mar 2, 2016 at 2:39 PM, Joe Bowser <bowserj@gmail.com> wrote:

>
>
> On Wed, Mar 2, 2016 at 2:34 PM, Carlos Santana <csantana23@gmail.com>
> wrote:
>
>> What do you mean by a manual step to set the architecture?
>>
>> meaning that "cordova build" will build one apk by default
>>
>>
> Yes, right now if I set the version code to 1 and do a crosswalk build, I
> would get the following version codes and APKs:
> android-armv6-release.apk - Version Code 12
> android-x86-release.apk - Version Code 14
>
>
>> But if they want a specific architecture or multiple built they can do via
>> extra argument to "cordova build"
>>
>> Like cordova build -- --x86 --arm
>>
>>
> I don't think we should do multiple at all.  I think we should build just
> one.
>
> So, if you do this cordova build release --arch=arm
>
> You get only
>
> android-armv6-release.apk - Version Code 1
>
> And then to get the other one you have change the version code to 2 and do
> this:
>
> cordova build release --arch=x86
>
> android-x86-release.apk - Version Code 2
>
>
>
>> This is similar for windows platform where user control targets and build
>> via extra flags to build command, or not even related?
>>
>>
> Yes, this issue is open because we're copying how Windows does things.  I
> don't know why we're doing a multiple APK build, except that Crosswalk is
> an Intel thing, maybe?
>
>
>>
>>
>>
>> On Wed, Mar 2, 2016 at 5:17 PM Joe Bowser <bowserj@gmail.com> wrote:
>>
>> > On Wed, Mar 2, 2016 at 2:02 PM, Carlos Santana <csantana23@gmail.com>
>> > wrote:
>> >
>> > > Avoiding a large APK is kind of a good feature to have, to build small
>> > apk
>> > > targeted to specific architecture.
>> > >
>> > > What's your proposal ? Maybe I missed it
>> > >
>> > >
>> > Step 1. Remove the code that changes version codes but has nothing to do
>> > with architecture and get users to specify the Android Version Code in
>> the
>> > config.xml like so:
>> > <widget android-versionCode="19" id="ca.dontflyhere.app" version="0.0.1"
>> > xmlns="http://www.w3.org/ns/widgets" xmlns:cdv="
>> > http://cordova.apache.org/ns/1.0">
>> >
>> >
>> > > You said to remove multiple apk generation or have multiple apk
>> > generation
>> > > being don in a different way to handle the versionCode per
>> architecture?
>> > >
>> > >
>> > Yeah, for the short term, I think multiplying by 10, and reserving the
>> last
>> > spot to denote x86 or arm isn't an awful solution, but it's far from
>> > ideal.  If we can turn off multiple APK generation and add the ability
>> to
>> > set an architecture, then this would turn into a manual step for the
>> > developer to take advantage of, and they can decide if version 11 is arm
>> > and version 12 is x86, but I'm not sure if developers are able to handle
>> > that or want it abstracted, which is why I'm asking.
>> >
>> >
>> > >
>> > > On Wed, Mar 2, 2016 at 4:41 PM Joe Bowser <bowserj@gmail.com> wrote:
>> > >
>> > > > On Wed, Mar 2, 2016 at 1:26 PM, Carlos Santana <
>> csantana23@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > If it's not well documented how this multiple APKs suppose to
work
>> > and
>> > > > use.
>> > > > > then I would say the impact is low
>> > > > >
>> > > >
>> > > > I disagree, since people using Crosswalk are expecting that
>> behaviour
>> > by
>> > > > default right now.  We don't have to built multiple APKs with
>> Crosswalk
>> > > > but bundling both the X86 and the ARM libraries makes the APK 48 MB.
>> > > >
>> > > >
>> > > > > If it's not part of the build.json in --buildConfig spec [1]
 then
>> > also
>> > > > low
>> > > > > impact.
>> > > > >
>> > > > >
>> > > > I would agree if build.json was universally adopted as the way to
do
>> > > > things, and there wasn't multiple ways people were building
>> production
>> > > > apps.  Right now, it's more likely that someone would store a
>> > > > settings.gradle file pointing to the keystore instead, especially
>> since
>> > > it
>> > > > doesn't prompt for a password like build.json does.
>> > > >
>> > > >
>> > > >
>> > > > > It would be good to get some of those answers to the questions
you
>> > have
>> > > > > about apk requiring different version code on store
>> > > > >
>> > > > >
>> > > > I just tried to deploy multiple APKs with different architectures
on
>> > the
>> > > > play store, you can't do it.  If you try, you replace your ARM apk
>> with
>> > > an
>> > > > x86 APK.  You have to have a different version code for each of
>> them.
>> > > >
>> > > >
>> > > >
>> > > > > Maybe it make sense to remove it from builde.gradle and move
it to
>> > > > > build.json if it's something that is something that comes into
>> play
>> > > when
>> > > > > releasing instead of being normal dev cycle.
>> > > > >
>> > > > > [1]:
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://cordova.apache.org/docs/en/dev/guide/platforms/android/#signing-an-app
>> > > > >
>> > > > >
>> > > > > On Wed, Mar 2, 2016 at 4:12 PM Joe Bowser <bowserj@gmail.com>
>> wrote:
>> > > > >
>> > > > > > On Wed, Mar 2, 2016 at 1:07 PM, Carlos Santana <
>> > csantana23@gmail.com
>> > > >
>> > > > > > wrote:
>> > > > > >
>> > > > > > > First sorry for my stupid questions :-)
>> > > > > > >
>> > > > > > > Why do we need to mess with this versionCode?
>> > > > > > >
>> > > > > > >
>> > > > > > Short Answer: We shouldn't have to.
>> > > > > >
>> > > > > > Long Answer: We might need it for Crosswalk only.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > > How a native developer creating a new Android App today
using
>> > > Android
>> > > > > > > Studio and gradle handle this?
>> > > > > > >
>> > > > > >
>> > > > > > They set it in the Android Manifest like they're supposed
to.
>> This
>> > > > > hasn't
>> > > > > > changed AFAIK.  Apparently having multiple APKs in the store
>> means
>> > > that
>> > > > > you
>> > > > > > have to have different version codes, although I haven't
tested
>> > this
>> > > > yet.
>> > > > > >
>> > > > > >
>> > > > > > > Should that help us determined how it should work for
Cordova
>> > Apps?
>> > > > > > >
>> > > > > >
>> > > > > > You'd think, but then we wouldn't have this weird system
in
>> place
>> > > right
>> > > > > > now.  I wish we talked about this more, but this seems to
have
>> > mostly
>> > > > > flown
>> > > > > > in under the radar when we were getting Cordova 4.0 out.
>> > > > > >
>> > > > > >
>> > > > > > >
>> > > > > > > Can we come with a similar system, or no system, or
it's user
>> > space
>> > > > > where
>> > > > > > > they can put a version code they want to use in config.xml
in
>> > > > > conjunction
>> > > > > > > with of the version string (i.e. 1.0.0) that they are
already
>> > using
>> > > > in.
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > I believe that config.xml already does this, but we then
munge
>> it
>> > all
>> > > > up
>> > > > > > because someone thought that we might want to have many
APKs
>> > instead
>> > > of
>> > > > > > just one APK for a version of Android.  This is something
that's
>> > > pissed
>> > > > > off
>> > > > > > various developers over the past year, and the reason I'm
>> asking is
>> > > > > because
>> > > > > > I want to see it deleted, but don't want to break anyone
who
>> relies
>> > > on
>> > > > > it.
>> > > > > >
>> > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > On Wed, Mar 2, 2016 at 3:58 PM Joe Bowser <bowserj@gmail.com>
>> > > wrote:
>> > > > > > >
>> > > > > > > > OK, so, I'm dealing with this code, which pisses
me off to
>> no
>> > > end:
>> > > > > > > >
>> > > > > > > >     if (Boolean.valueOf(cdvBuildMultipleApks))
{
>> > > > > > > >         productFlavors {
>> > > > > > > >             armv7 {
>> > > > > > > >                 versionCode defaultConfig.versionCode
+ 2
>> > > > > > > >                 ndk {
>> > > > > > > >                     abiFilters "armeabi-v7a",
""
>> > > > > > > >                 }
>> > > > > > > >             }
>> > > > > > > >             x86 {
>> > > > > > > >                 versionCode defaultConfig.versionCode
+ 4
>> > > > > > > >                 ndk {
>> > > > > > > >                     abiFilters "x86", ""
>> > > > > > > >                 }
>> > > > > > > >             }
>> > > > > > > >             all {
>> > > > > > > >                 ndk {
>> > > > > > > >                     abiFilters "all", ""
>> > > > > > > >                 }
>> > > > > > > >             }
>> > > > > > > >         }
>> > > > > > > >     } else if (!cdvVersionCode) {
>> > > > > > > >       def minSdkVersion = cdvMinSdkVersion ?:
>> > > > > > > > privateHelpers.extractIntFromManifest("minSdkVersion")
>> > > > > > > >       // Vary versionCode by the two most common
API levels:
>> > > > > > > >       // 14 is ICS, which is the lowest API level
for many
>> > apps.
>> > > > > > > >       // 20 is Lollipop, which is the lowest API
level for
>> the
>> > > > > > updatable
>> > > > > > > > system webview.
>> > > > > > > >       if (minSdkVersion >= 20) {
>> > > > > > > >         defaultConfig.versionCode += 9
>> > > > > > > >       } else if (minSdkVersion >= 14) {
>> > > > > > > >         defaultConfig.versionCode += 8
>> > > > > > > >       }
>> > > > > > > >     }
>> > > > > > > >
>> > > > > > > > So, right now if you're not using Crosswalk at
all, your
>> > default
>> > > > > > version
>> > > > > > > > code will be 18 instead of 1, and 28 for the second
version
>> if
>> > > you
>> > > > > > aren't
>> > > > > > > > using Crosswalk.  I can see why people would build
multiple
>> > APKs
>> > > > per
>> > > > > > > > architectures, but if you're building multiple
APKs for
>> > different
>> > > > > > > versions
>> > > > > > > > of Android, we've all done something wrong and
we never
>> asked
>> > for
>> > > > > this
>> > > > > > > > feature to be added to Cordova.  The whole point
of Cordova
>> is
>> > to
>> > > > > work
>> > > > > > > > across multiple platforms, and that does include
multiple
>> > > versions
>> > > > of
>> > > > > > > > Android.
>> > > > > > > >
>> > > > > > > > However, since this stupid code was added back
in 4.0.x, I'm
>> > > > > wondering
>> > > > > > if
>> > > > > > > > anyone is relying on this code before I rip it
out and have
>> > > version
>> > > > > > codes
>> > > > > > > > mean exactly what they're supposed to mean.  That
means that
>> > when
>> > > > you
>> > > > > > > build
>> > > > > > > > and release your first app without using Crosswalk,
your
>> > > > application
>> > > > > > > > version code will be 1.  Not 18, not 19, but 1.
 Then when
>> you
>> > > > build
>> > > > > > > > another version, that version will be 2, and so
on.
>> > > > > > > >
>> > > > > > > > What do people think of this code going away?
 Crosswalk
>> will
>> > > > > probably
>> > > > > > > have
>> > > > > > > > to have the different version codes, since I think
us
>> defining
>> > a
>> > > > > system
>> > > > > > > > could work better than leaving this up to the
user and
>> having
>> > > > things
>> > > > > go
>> > > > > > > > horribly sideways when people are trying to keep
track of
>> > whether
>> > > > > they
>> > > > > > > > released an arm or x86 binary, since we already
decided to
>> take
>> > > > > > > > responsibility for this.
>> > > > > > > >
>> > > > > > > > So, feedback on this would be good.
>> > > > > > > >
>> > > > > > > > On Thu, Feb 18, 2016 at 11:09 AM, Darryl Pogue
<
>> > darryl@dpogue.ca
>> > > >
>> > > > > > wrote:
>> > > > > > > >
>> > > > > > > > > Not intentionally on my end, but when I add
the CrossWalk
>> > > plugin
>> > > > I
>> > > > > > > > > seem to get two APKs as output (one for armv7,
one for
>> x86).
>> > > > > > > > >
>> > > > > > > > > On 18 February 2016 at 11:05, Joe Bowser
<
>> bowserj@gmail.com>
>> > > > > wrote:
>> > > > > > > > > >
>> > > > > > > > > > Hey
>> > > > > > > > > >
>> > > > > > > > > > Based on the feedback on those two issues,
and other
>> > places,
>> > > I
>> > > > > > think
>> > > > > > > > that
>> > > > > > > > > > most hated change from Cordova-Android
4.0 that we
>> didn't
>> > fix
>> > > > in
>> > > > > > > > > > Cordova-Android 5.0 was the fact that
we have an
>> > undocumented
>> > > > way
>> > > > > > of
>> > > > > > > > > > generating an arbitrary build number
that makes
>> absolutely
>> > no
>> > > > > > sense.
>> > > > > > > > > > Furthermore, this screws up people's
automated builds,
>> and
>> > > can
>> > > > > > cause
>> > > > > > > > the
>> > > > > > > > > > version code to reach MAX_INT.
>> > > > > > > > > >
>> > > > > > > > > > If you want to know why nobody has touched
it until now,
>> > it's
>> > > > > > because
>> > > > > > > > > > everyone hates working with Gradle.
 I can say the exact
>> > same
>> > > > > thing
>> > > > > > > > about
>> > > > > > > > > > why we're not using ProGuard.
>> > > > > > > > > >
>> > > > > > > > > > Now, I'm starting on my flensing of
the gradle files
>> that
>> > we
>> > > > have
>> > > > > > in
>> > > > > > > > > here,
>> > > > > > > > > > trying to figure out what we can rip
out and I'm
>> wondering
>> > if
>> > > > > > anyone
>> > > > > > > is
>> > > > > > > > > > actually using the multiple APK generation
before I
>> remove
>> > > it.
>> > > > If
>> > > > > > > > people
>> > > > > > > > > > are, I'm going to have to figure out
another way for
>> this
>> > to
>> > > > > > happen,
>> > > > > > > > > > because this is definitely breaking
people's
>> applications,
>> > > and
>> > > > > > using
>> > > > > > > > > random
>> > > > > > > > > > hooks isn't a good answer.
>> > > > > > > > > >
>> > > > > > > > > > So, is anyone using this, or can this
feature die!
>> > > > > > > > > >
>> > > > > > > > > > Joe
>> > > > > > > > >
>> > > > > > > > >
>> > > > >
>> ---------------------------------------------------------------------
>> > > > > > > > > To unsubscribe, e-mail:
>> dev-unsubscribe@cordova.apache.org
>> > > > > > > > > For additional commands, e-mail:
>> dev-help@cordova.apache.org
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message