cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: android target level
Date Wed, 27 Nov 2013 21:54:55 GMT
It seems that all the platform scripts do something subtly different.
Some of them do support custom platform paths, others don't, etc.  It seems
like something we could easily consolidate.


On Wed, Nov 27, 2013 at 4:51 PM, Michal Mocny <mmocny@chromium.org> wrote:

> https://reviews.apache.org/r/15889/
>
>
> On Wed, Nov 27, 2013 at 4:38 PM, Michal Mocny <mmocny@chromium.org> wrote:
>
>> But the file warns that its auto-generated and shouldn't be edited ;)
>>
>> I've got a patch for this.  Seems of the other platforms were already
>> doing it right.  Reviewboard incoming since I don't much with CLI often.
>>
>>
>> On Wed, Nov 27, 2013 at 3:03 PM, Joe Bowser <bowserj@gmail.com> wrote:
>>
>>> I'm bumping it to 19 now.  You just change project.properties to do
>>> this on Android. :)
>>>
>>> On Wed, Nov 27, 2013 at 11:59 AM, Michal Mocny <mmocny@chromium.org>
>>> wrote:
>>> > Ah, indeed.  CLI has hard coded req on 17 in
>>> > module.exports.check_requirements in android_parser.js.  That needs to
>>> > change especially quickly now since the platform SDK dependency was
>>> bumped
>>> > to 18 in our 3.2 release (so CLI and platform workflows have atm
>>> different
>>> > requirements).
>>> >
>>> >
>>> > On Wed, Nov 27, 2013 at 2:49 PM, Joe Bowser <bowserj@gmail.com> wrote:
>>> >>
>>> >> The problem is that we should never be relying on the CLI for this
>>> >> info, and that the platforms should be doing it.  That's why I edited
>>> >> the bug in the first place.  This is also a problem with iOS, although
>>> >> less of a problem due to >=.
>>> >>
>>> >> On Wed, Nov 27, 2013 at 11:43 AM, Michal Mocny <mmocny@chromium.org>
>>> >> wrote:
>>> >> > Would be nice to change scripts to check for >= target-level
>>> instead of
>>> >> > exactly ==.  I currently just re-installed my android SDK locally
>>> with
>>> >> > only
>>> >> > 4.4 (API 19), and now fail to create a project with CLI since it
>>> isnt
>>> >> > exactly the version we look for.
>>> >> >
>>> >> > Since there won't be another android release for a while I'm sure
>>> this
>>> >> > issue
>>> >> > won't come up after the cordova 3.3 release version bump.. so maybe
>>> its
>>> >> > low
>>> >> > priority.
>>> >> >
>>> >> > In the mean time, now that we've shipped 3.2, shall we bump the
>>> version
>>> >> > on
>>> >> > master?
>>> >> >
>>> >> >
>>> >> > On Thu, Nov 7, 2013 at 10:55 AM, Braden Shepherdson
>>> >> > <braden@chromium.org>
>>> >> > wrote:
>>> >> >>
>>> >> >> I think some people are confused about this number and backward
>>> >> >> compatibility.
>>> >> >>
>>> >> >> There are *two* version constraints on Android. The one we're
>>> >> >> discussing
>>> >> >> here is which API we're compiling against, which should generally
>>> be
>>> >> >> set
>>> >> >> at
>>> >> >> the latest stable version (+1 to 3.2 targeting API 18 (Android
>>> 4.3)).
>>> >> >>
>>> >> >> There's another, separate value for the *minimum* API version.
Your
>>> >> >> project
>>> >> >> cannot use any methods or classes introduced after that API
>>> version.
>>> >> >> For
>>> >> >> Cordova, we are currently setting that to API 10 (2.3.3). So
we
>>> should
>>> >> >> support devices running 10, and 14-18. We don't officially
support
>>> >> >> 11-13,
>>> >> >> because no one cares about Honeycomb, but they mostly work
anyway.
>>> >> >>
>>> >> >> Braden
>>> >> >>
>>> >> >>
>>> >> >> On Thu, Nov 7, 2013 at 10:17 AM, Carlos Santana
>>> >> >> <csantana23@gmail.com>wrote:
>>> >> >>
>>> >> >> > We are also in the works on getting a Nexus 5, probably
on
>>> Friday we
>>> >> >> > want
>>> >> >> > to get unlocked
>>> >> >> >
>>> >> >> >
>>> >> >> > On Thu, Nov 7, 2013 at 9:38 AM, Joe Bowser <bowserj@gmail.com>
>>> wrote:
>>> >> >> >
>>> >> >> > > That's correct. I only have an old Nexus 7 with an
AOSP build I
>>> >> >> > > made
>>> >> >> > > yesterday to test things on 4.4 while I wait for
the Nexus 5
>>> or the
>>> >> >> > > official updates, and since I have no camera drivers
working.
>>> >> >> > >
>>> >> >> > > BTW: We still have a gallery, but I think the Camera
plugin
>>> may be
>>> >> >> > > broken
>>> >> >> > > in 4.4.
>>> >> >> > >  On Nov 7, 2013 6:27 AM, "Carlos Santana" <
>>> csantana23@gmail.com>
>>> >> >> > > wrote:
>>> >> >> > >
>>> >> >> > > > To be clear the goal for Cordova 3.2 is to set
target 18
>>> (Android
>>> >> >> > > > 4.3)
>>> >> >> > > and
>>> >> >> > > > for Cordova 3.3 target 19 (Android 4.4) ?
>>> >> >> > > >
>>> >> >> > > > We are about to release 3.2 so I want to be
sure.
>>> >> >> > > >
>>> >> >> > > > I vote to set target 19/4.4 (KitKat) for Cordova
3.3 (Allows
>>> time
>>> >> >> > > > to
>>> >> >> > > > investigate, test, integrate, and document)
>>> >> >> > > >
>>> >> >> > > >
>>> >> >> > > >
>>> >> >> > > > On Thu, Nov 7, 2013 at 8:19 AM, Gorkem Ercan
>>> >> >> > > > <gorkem.ercan@gmail.com>
>>> >> >> > > > wrote:
>>> >> >> > > >
>>> >> >> > > > > Joe is right on the money. If the target
is older than 13
>>> it
>>> >> >> > > > > will
>>> >> >> > fail
>>> >> >> > > to
>>> >> >> > > > > compile which was detected elsewhere [1].
>>> >> >> > > > >
>>> >> >> > > > > Also as detected on the other thread CLI
is not actually
>>> [2]
>>> >> >> > > > > [3]
>>> >> >> > > > delegating
>>> >> >> > > > > the requirement checks to platform scripts
for
>>> >> >> > > > > Android and iOS. After this issue is resolved
it will
>>> depend on
>>> >> >> > > > > the
>>> >> >> > > value
>>> >> >> > > > > on the project.properties. Hopefully that
is more likely
>>> to be
>>> >> >> > updated
>>> >> >> > > > > and we will not end up forcing level 17
when 18 and 19 was
>>> out.
>>> >> >> > > > >
>>> >> >> > > > > I am not happy about the fixed target versions
overall
>>> though.
>>> >> >> > > > > On
>>> >> >> > JBoss
>>> >> >> > > > > tools we decided to look for the newest
target that exists
>>> and
>>> >> >> > > > > use
>>> >> >> > that
>>> >> >> > > > as
>>> >> >> > > > > long as it
>>> >> >> > > > > is newer that minimum (which is 17 at this
time). This way
>>> we
>>> >> >> > > > > would
>>> >> >> > not
>>> >> >> > > > > disappoint a developer who gets the latest
and greatest SDK
>>> >> >> > > > > update.
>>> >> >> > > > >
>>> >> >> > > > > [1] https://issues.jboss.org/browse/JBIDE-15885
>>> >> >> > > > > [2] https://issues.apache.org/jira/browse/CB-5298
>>> >> >> > > > > [3] https://issues.apache.org/jira/browse/CB-5297
>>> >> >> > > > >
>>> >> >> > > > > --
>>> >> >> > > > > Gorkem
>>> >> >> > > > >
>>> >> >> > > > >
>>> >> >> > > > > On Thu, Nov 7, 2013 at 7:51 AM, Brian LeRoux
<b@brian.io>
>>> >> >> > > > > wrote:
>>> >> >> > > > >
>>> >> >> > > > > > Axel: you are correct that we want
as many devices as
>>> >> >> > > > > > possible.
>>> >> >> > This
>>> >> >> > > is
>>> >> >> > > > > why
>>> >> >> > > > > > we've always set to the highest level.
If you set to the
>>> >> >> > > > > > highest
>>> >> >> > > level
>>> >> >> > > > it
>>> >> >> > > > > > is inclusive to all platforms before
it (that we decide
>>> to
>>> >> >> > support).
>>> >> >> > > > > >
>>> >> >> > > > > >
>>> >> >> > > > > > On Thu, Nov 7, 2013 at 12:00 PM, Axel
Nennker <
>>> >> >> > ignisvulpis@gmail.com
>>> >> >> > > >
>>> >> >> > > > > > wrote:
>>> >> >> > > > > >
>>> >> >> > > > > > > I think the highest level is
not what developers need.
>>> >> >> > > > > > > When you create a product/app
you want your app to run
>>> on
>>> >> >> > > > > > > as
>>> >> >> > > > > > > many
>>> >> >> > > > > devices
>>> >> >> > > > > > > as possible and not only the
latest.
>>> >> >> > > > > > > Am 07.11.2013 11:36 schrieb "Brian
LeRoux" <b@brian.io
>>> >:
>>> >> >> > > > > > >
>>> >> >> > > > > > > > Apologies I think there
is another thread about this
>>> but
>>> >> >> > > > > > > > I'd
>>> >> >> > like
>>> >> >> > > > to
>>> >> >> > > > > > > > understand more about what
we're thinking here.
>>> There's
>>> >> >> > > > > > > > been
>>> >> >> > > > > discussion
>>> >> >> > > > > > > > that we should make this
configurable. I disagree. I
>>> >> >> > > > > > > > think
>>> >> >> > > > > > > > we
>>> >> >> > > need
>>> >> >> > > > to
>>> >> >> > > > > > > > target highest available
level possible, as we always
>>> >> >> > > > > > > > have
>>> >> >> > > > > > > > in
>>> >> >> > the
>>> >> >> > > > > past,
>>> >> >> > > > > > > and
>>> >> >> > > > > > > > take backwards compat on.
That means we need to
>>> update
>>> >> >> > > > > > > > [1].
>>> >> >> > > > > > > >
>>> >> >> > > > > > > > Thoughts?
>>> >> >> > > > > > > >
>>> >> >> > > > > > > > [1]
>>> >> >> > > > > > > >
>>> >> >> > > > > > > >
>>> >> >> > > > > > >
>>> >> >> > > > > >
>>> >> >> > > > >
>>> >> >> > > >
>>> >> >> > >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> https://github.com/apache/cordova-cli/blob/master/src/metadata/android_parser.js#L56
>>> >> >> > > > > > > >
>>> >> >> > > > > > >
>>> >> >> > > > > >
>>> >> >> > > > >
>>> >> >> > > >
>>> >> >> > > >
>>> >> >> > > >
>>> >> >> > > > --
>>> >> >> > > > Carlos Santana
>>> >> >> > > > <csantana23@gmail.com>
>>> >> >> > > >
>>> >> >> > >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > --
>>> >> >> > Carlos Santana
>>> >> >> > <csantana23@gmail.com>
>>> >> >> >
>>> >> >
>>> >> >
>>> >
>>> >
>>>
>>
>>
>

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