You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cordova.apache.org by Joe Bowser <bo...@gmail.com> on 2015/09/21 23:13:59 UTC

[Android] 5.0.x release branch?

Hey

In the next two weeks, Marshmallow will most likely getting released with
the brand new Nexus 6P being released from Huawei.  Given that most of the
Nexus devices will be getting this release, we should probably release the
5.0.x branch of Android soon, and get the new plugins updated.

It should be noted that the latest plugins will not be compatible with
older versions of Cordova, which is a big deal.  This is due to the use of
various compatibility checks to make sure they support Marshmallow and
older versions of Android.

So, if everyone can look over the smores branches of my GitHub before I
create the 5.0.x branch and pull the changes into it, that would be awesome.

https://github.com/infil00p/cordova-android/tree/smores
https://github.com/infil00p/cordova-plugin-geolocation/tree/smores
https://github.com/infil00p/cordova-plugin-camera/tree/smores
https://github.com/infil00p/cordova-plugin-contacts/tree/smores

Work on audio is still outstanding, BUT for some reason Audio broke
recently on both Lollipop and Marshmallow.  I didn't test it out on KitKat
or Jellybean yet, but I'm wondering whether we should keep maintaining this
or support the standard HTML5 audio and deal with the asset issue somehow
(which isn't straight forward).

I hopefully want to get a 5.0.x branch happening this week if we can.

What do people think?

Joe

Re: [Android] 5.0.x release branch?

Posted by Joe Bowser <bo...@gmail.com>.

On Tue, Sep 22, 2015 at 1:30 PM, Karen Tran <kt...@gmail.com> wrote:

> Hi Joe,
>
> I tested your geolocation plugin changes with mobilespec and the app
> crashes when you click "Deny" permission and when you click "Accept"
> permission for the first time. When you go back to the app after accepting,
> you can get location data.
>


I'm not getting that behaviour with the latest version of the smores branch
and the latest plugin.  I noticed that the watch commands aren't working as
they should, which is bad.  Try pulling down the latest on the smores repo.
  Also, please update the issue on JIRA.

https://issues.apache.org/jira/browse/CB-9105


>
> I agree with having a 5.0.x branch soon since I know some people are
> already asking about using API 23 and needing to test it asap.
>
>
Yeah, it's easier to get people to test off that than some random topic
branch on Github.



>
> On Mon, Sep 21, 2015 at 9:32 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> > On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal <
> nikhilkh@microsoft.com>
> > wrote:
> >
> > > Can you explain why latest plugins will not be compatible with older
> > > versions of Cordova?
> >
> >
> > They won't be compatible because Cordova-Android compiles against API 22,
> > and these plugins will require API 23 so that they can detect permissions
> > and support Marshmellow.
> >
> >
> > > Can this be avoided by any means?
> >
> >
> > Only with a lot of Java reflection, and I'd rather not subject plugin
> > developers to that, or try to hide it under the hood in some awful
> utility
> > class that everyone will want to see die.  I'm very much a fan of if
> > statements because they work, and they're easy to read and debug, unlike
> > when bad things happen to things you reflect into.  Plugins that require
> > API 23 will only work with Cordova-Android 5.0 and up.  This only impacts
> > five of our core plugins, but any plugin that requires permissions from
> the
> > Android Manifest will have to be updated.  If we can avoid using advanced
> > language tricks to make the APKs compatible, we should do that.
> >
> > When you mean they would not be compatible - will it result in a build or
> > > runtime failure?
> > >
> > >
> > This will be a build failure, since API 22 does not have these
> permissions,
> > nor does it have the code required for API 23.
> >
> >
> > > For marshmallow, what is the guidance that we need to issue to the
> larger
> > > Cordova plugin ecosystem? Joe you are ahead of the curve here compared
> to
> > > most other plugin developers - a blot post explaining what are known
> > > gotchas would be great. I really hope we can use our Cordova blog to
> > > communicate these changes actively to the plugin ecosystem. This
> mailing
> > > list only gets 400+ subscribers.
> > >
> > >
> > There will be a blog post once 5.0 is released.  We're not forcing people
> > to upgrade to 5.0, and we will be supporting the 4.x branch for six
> > months.  This does mean we're stuck supporting 3.x, 4.x and 5.x for a
> brief
> > window, but I have no control over when Marshmallow is released, only
> > whether we want to support it or not.  I think we do, but I could be
> wrong.
> >
> > At least this should be easier than the jump from 3.x to 4.x for most
> > people, but the alternative is that your plugin just doesn't work at all
> on
> > Marshmallow.  We need to at least give plugin developers this option,
> since
> > it'll roll out on all the Nexus devices in the next two weeks, and we'll
> > hear more about it.
> >
> >
> > > Can you re-base your cordova-android over the current master? It's hard
> > to
> > > see a diff in the current form:
> > >
> >
> https://github.com/apache/cordova-android/compare/master...infil00p:smores
> > >
> > >
> > I had to do a merge commit to get this to happen (boo), but it should be
> > mostly cleaned up now.  It seems some style cleanup creeped into the most
> > recent changes, but this should be a bit more readable.
> >
> >
> > > -Nikhil
> > >
> > > -----Original Message-----
> > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > Sent: Monday, September 21, 2015 2:14 PM
> > > To: dev <de...@cordova.apache.org>
> > > Subject: [Android] 5.0.x release branch?
> > >
> > > Hey
> > >
> > > In the next two weeks, Marshmallow will most likely getting released
> with
> > > the brand new Nexus 6P being released from Huawei.  Given that most of
> > the
> > > Nexus devices will be getting this release, we should probably release
> > the
> > > 5.0.x branch of Android soon, and get the new plugins updated.
> > >
> > > It should be noted that the latest plugins will not be compatible with
> > > older versions of Cordova, which is a big deal.  This is due to the use
> > of
> > > various compatibility checks to make sure they support Marshmallow and
> > > older versions of Android.
> > >
> > > So, if everyone can look over the smores branches of my GitHub before I
> > > create the 5.0.x branch and pull the changes into it, that would be
> > awesome.
> > >
> > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%2bve4PVcCE%3d
> > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv6pc5qbeY%2bdUxiP4bc%3d
> > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCGRb4zWC8maWpE%3d
> > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2feEmqLOdU%2fwua2TbLU%3d
> > >
> > > Work on audio is still outstanding, BUT for some reason Audio broke
> > > recently on both Lollipop and Marshmallow.  I didn't test it out on
> > KitKat
> > > or Jellybean yet, but I'm wondering whether we should keep maintaining
> > this
> > > or support the standard HTML5 audio and deal with the asset issue
> somehow
> > > (which isn't straight forward).
> > >
> > > I hopefully want to get a 5.0.x branch happening this week if we can.
> > >
> > > What do people think?
> > >
> > > Joe
> > >
> >
>

Re: [Android] 5.0.x release branch?

Posted by Karen Tran <kt...@gmail.com>.

Hi Joe,

I tested your geolocation plugin changes with mobilespec and the app
crashes when you click "Deny" permission and when you click "Accept"
permission for the first time. When you go back to the app after accepting,
you can get location data.

I agree with having a 5.0.x branch soon since I know some people are
already asking about using API 23 and needing to test it asap.


On Mon, Sep 21, 2015 at 9:32 PM, Joe Bowser <bo...@gmail.com> wrote:

> On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal <ni...@microsoft.com>
> wrote:
>
> > Can you explain why latest plugins will not be compatible with older
> > versions of Cordova?
>
>
> They won't be compatible because Cordova-Android compiles against API 22,
> and these plugins will require API 23 so that they can detect permissions
> and support Marshmellow.
>
>
> > Can this be avoided by any means?
>
>
> Only with a lot of Java reflection, and I'd rather not subject plugin
> developers to that, or try to hide it under the hood in some awful utility
> class that everyone will want to see die.  I'm very much a fan of if
> statements because they work, and they're easy to read and debug, unlike
> when bad things happen to things you reflect into.  Plugins that require
> API 23 will only work with Cordova-Android 5.0 and up.  This only impacts
> five of our core plugins, but any plugin that requires permissions from the
> Android Manifest will have to be updated.  If we can avoid using advanced
> language tricks to make the APKs compatible, we should do that.
>
> When you mean they would not be compatible - will it result in a build or
> > runtime failure?
> >
> >
> This will be a build failure, since API 22 does not have these permissions,
> nor does it have the code required for API 23.
>
>
> > For marshmallow, what is the guidance that we need to issue to the larger
> > Cordova plugin ecosystem? Joe you are ahead of the curve here compared to
> > most other plugin developers - a blot post explaining what are known
> > gotchas would be great. I really hope we can use our Cordova blog to
> > communicate these changes actively to the plugin ecosystem. This mailing
> > list only gets 400+ subscribers.
> >
> >
> There will be a blog post once 5.0 is released.  We're not forcing people
> to upgrade to 5.0, and we will be supporting the 4.x branch for six
> months.  This does mean we're stuck supporting 3.x, 4.x and 5.x for a brief
> window, but I have no control over when Marshmallow is released, only
> whether we want to support it or not.  I think we do, but I could be wrong.
>
> At least this should be easier than the jump from 3.x to 4.x for most
> people, but the alternative is that your plugin just doesn't work at all on
> Marshmallow.  We need to at least give plugin developers this option, since
> it'll roll out on all the Nexus devices in the next two weeks, and we'll
> hear more about it.
>
>
> > Can you re-base your cordova-android over the current master? It's hard
> to
> > see a diff in the current form:
> >
> https://github.com/apache/cordova-android/compare/master...infil00p:smores
> >
> >
> I had to do a merge commit to get this to happen (boo), but it should be
> mostly cleaned up now.  It seems some style cleanup creeped into the most
> recent changes, but this should be a bit more readable.
>
>
> > -Nikhil
> >
> > -----Original Message-----
> > From: Joe Bowser [mailto:bowserj@gmail.com]
> > Sent: Monday, September 21, 2015 2:14 PM
> > To: dev <de...@cordova.apache.org>
> > Subject: [Android] 5.0.x release branch?
> >
> > Hey
> >
> > In the next two weeks, Marshmallow will most likely getting released with
> > the brand new Nexus 6P being released from Huawei.  Given that most of
> the
> > Nexus devices will be getting this release, we should probably release
> the
> > 5.0.x branch of Android soon, and get the new plugins updated.
> >
> > It should be noted that the latest plugins will not be compatible with
> > older versions of Cordova, which is a big deal.  This is due to the use
> of
> > various compatibility checks to make sure they support Marshmallow and
> > older versions of Android.
> >
> > So, if everyone can look over the smores branches of my GitHub before I
> > create the 5.0.x branch and pull the changes into it, that would be
> awesome.
> >
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%2bve4PVcCE%3d
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv6pc5qbeY%2bdUxiP4bc%3d
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCGRb4zWC8maWpE%3d
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2feEmqLOdU%2fwua2TbLU%3d
> >
> > Work on audio is still outstanding, BUT for some reason Audio broke
> > recently on both Lollipop and Marshmallow.  I didn't test it out on
> KitKat
> > or Jellybean yet, but I'm wondering whether we should keep maintaining
> this
> > or support the standard HTML5 audio and deal with the asset issue somehow
> > (which isn't straight forward).
> >
> > I hopefully want to get a 5.0.x branch happening this week if we can.
> >
> > What do people think?
> >
> > Joe
> >
>

Re: [Android] 5.0.x release branch?

Posted by Frederico Galvão <fr...@pontoget.com.br>.

>
> > Based on [1] I think we're overthinking here...
> >
> > I might have missed something, but as far as I understood it all, the
> only
> > thing preventing new plugin versions from working on older
> cordova-android
> > based projects is the POSSIBLE FACT that these projects will still
> > have android:targetSdkVersion="N < 23". It's not a sure bet, it's a
> > possibility. My project, for example, will already
> > have android:targetSdkVersion="23" when I upgrade to cordova-android 5.x
> > with all the plugins upgraded too, so even if I only upgraded the plugins
> > it would still work.
> >
> >
> If you only upgrade the plugins, it won't compile because the new plugins
> now call methods in Cordova 5.0.x to handle the permissions in
> Marshmellow.  We didn't remove any API calls, we just added new ones to
> deal with the API changes on Android to deal with the permissions system
> they're rolling out.  That's why this major version exists at all,
> otherwise you would be right, and this would be a non-issue.


That's why I mentioned [1], which you proved incomplete just now.

They won't be compatible because Cordova-Android compiles against API 22,
> and these plugins will require API 23 so that they can detect permissions
> and support Marshmellow.


The reason they won't be compatible is not only because the compilation
target, but also because the new plugins need new methods from
cordova-android@5.

I then take my post back, it was the product of misinformation. I also hope
we don't go the reflection way then :)

2015-09-23 18:36 GMT-03:00 Steven Gill <st...@gmail.com>:

> so plugins that require cordova-android 5.0 + should definitely be adding
> an engine tag specifying that.
>
> We could look into some way for cordova-cli possibly fetching older
> versions if cordova plugin add fails but I imagine this code being ugly and
> easily breakable.
>
> it would be nice to start moving engine tag type stuff out of plugin.xml
> and into package.json. We probably want to update our tools to consume that
> info from package.json instead of plugin.xml. Something we should make a
> proposal for to see how it would look. Adding that info to searching would
> be very beneficial. This is for a separate discussion (possibly f2f)
>
>
>
>
>
> On Wed, Sep 23, 2015 at 2:19 PM, Joe Bowser <bo...@gmail.com> wrote:
>
> > On Wed, Sep 23, 2015 at 2:05 PM, Frederico Galvão <
> > frederico.galvao@pontoget.com.br> wrote:
> >
> > > Based on [1] I think we're overthinking here...
> > >
> > > I might have missed something, but as far as I understood it all, the
> > only
> > > thing preventing new plugin versions from working on older
> > cordova-android
> > > based projects is the POSSIBLE FACT that these projects will still
> > > have android:targetSdkVersion="N < 23". It's not a sure bet, it's a
> > > possibility. My project, for example, will already
> > > have android:targetSdkVersion="23" when I upgrade to cordova-android
> 5.x
> > > with all the plugins upgraded too, so even if I only upgraded the
> plugins
> > > it would still work.
> > >
> > >
> > If you only upgrade the plugins, it won't compile because the new plugins
> > now call methods in Cordova 5.0.x to handle the permissions in
> > Marshmellow.  We didn't remove any API calls, we just added new ones to
> > deal with the API changes on Android to deal with the permissions system
> > they're rolling out.  That's why this major version exists at all,
> > otherwise you would be right, and this would be a non-issue.
> >
> >
> > > It's common sense for android developers to bump the targetSdkVersion
> to
> > > the latest once a new one comes out, the android APIs are always
> > backwards
> > > compatible, even if it means for the google team to code migration or
> > > compatibility code (which they have always done afaik). If an app
> > developer
> > > is upgrading his plugins on an existing app, there is no obvious reason
> > for
> > > him not to also bump the targetSdkVersion. An app developer will always
> > > want to support the largest and newest devices, it's a larger audience
> > for
> > > them anyway.
> > >
> >
> > Upgrading to 5.0 bumps this automatically.
> >
> >
> > > With that said, I don't think any of the mentioned complexity is needed
> > > (package.json metadata, plugman version tryouts, engine tags in
> > plugin.xml
> > > or reflection). We just need to add hooks to the plugins that check the
> > > targetSdkVersions on plugin_install, and warn the user about this if
> it's
> > > bellow 23.
> > >
> > >
> > It's needed for plugins that use permissions.  Most plugins aren't
> affected
> > by this, such as plugins for ad networks.
> >
> > BTW: INTERNET permission isn't one that is prompted.  You can't revoke an
> > app's ability to go online.  I think that's dumb, but whatever.
> >
> >
> >
> > > [1]
> > > > They won't be compatible because Cordova-Android compiles against API
> > 22,
> > > and these plugins will require API 23 so that they can detect
> permissions
> > > and support Marshmellow.
> > >
> > > 2015-09-23 15:33 GMT-03:00 Joe Bowser <bo...@gmail.com>:
> > >
> > > > On Wed, Sep 23, 2015 at 11:30 AM, Joe Bowser <bo...@gmail.com>
> > wrote:
> > > >
> > > > >
> > > > > On Wed, Sep 23, 2015 at 11:22 AM, Homer, Tony <
> tony.homer@intel.com>
> > > > > wrote:
> > > > >
> > > > >> Joe-
> > > > >>
> > > > >> As far as I can tell, the API 23 calls are currently unguarded so
> > > smores
> > > > >> will only work on M Preview.
> > > > >> I know your smores branch is a POC, but I was wondering about
> > > backwards
> > > > >> compatibility.
> > > > >> Do you anticipate adding Build.VERSION.SDK_INT >=
> > > Build.VERSION_CODES.M
> > > > >> guard clauses for backwards compatibility?
> > > > >>
> > > > >>
> > > > > This already exists in each of the plugins when they do the
> > permissions
> > > > > check, and smores works perfectly fine on Lollipop so far.  Right
> > now,
> > > if
> > > > > you aren't running M, you don't do the permissions check, and you
> > don't
> > > > > call the methods.  I haven't tested it on earlier versions of
> > Android,
> > > > but
> > > > > I expect it to work on Kitkat and Jellybean the same way.
> > > > >
> > > > >
> > > > >
> > > >
> > > > And yes, we can probably create a utility method, that said, most
> > plugins
> > > > aren't directly affected by this, only the ones that require extra
> > > > permissions.  It'd be good if we had an idea of what third party
> > plugins
> > > > people are actually using that would run afowl of this and see where
> > they
> > > > would fail.  But I already have more than enough work currently, and
> > > > adopting other people's plugins is not something I want to get in the
> > > habit
> > > > of doing.
> > > >
> > > >
> > > >
> > > > > Tony
> > > > >>
> > > > >> On 9/23/15, 1:56 PM, "Joe Bowser" <bo...@gmail.com> wrote:
> > > > >>
> > > > >> >On Wed, Sep 23, 2015 at 9:36 AM, Carlos Santana <
> > > csantana23@gmail.com>
> > > > >> >wrote:
> > > > >> >
> > > > >> >> No need to major version change for the Plugins, the API of the
> > > > didn't
> > > > >> >> change.
> > > > >> >> Web developer still uses the same JS API to use the plugin.
> > > > >> >>
> > > > >> >>
> > > > >> >I would do a major version bump on Geolocation.  The API itself
> > > didn't
> > > > >> >change but the behaviour certainly did.  On Marshmallow we have
> to
> > > add
> > > > >> >this
> > > > >> >extra shim that asks for permission, which means that there's now
> > > code
> > > > >> >attached to Android Geolocation that didn't exist before.  All
> the
> > > > other
> > > > >> >plugins should still be fine.
> > > > >> >
> > > > >> >
> > > > >> >> Yes I did some thinking around the plugin search website. I
> think
> > > is
> > > > a
> > > > >> >>good
> > > > >> >> topic for the F2F.
> > > > >> >> Now that IBM is using Cordova Plugin more heavily to package
> our
> > > > mobile
> > > > >> >> SDKs using Cordova Plugins, I think is beneficial to expose
> more
> > > info
> > > > >> >>about
> > > > >> >> the plugin including engine tags
> > > > >> >>
> > > > >> >> I would not go and build our own backend and have our own
> > registry
> > > > with
> > > > >> >> cordova metadata.
> > > > >> >>
> > > > >> >> I think the solution is to put the metadata of plugin.xml into
> > > > >> >> package.json. We can show fast results in main search, but then
> > > user
> > > > >> can
> > > > >> >> drill into the plugin details, and we can have a view with more
> > > > >> >>information
> > > > >> >> and allow the user to select a specific version like we have
> > today
> > > in
> > > > >> >>our
> > > > >> >> plugin website search using the cordova registry.
> > > > >> >>
> > > > >> >> The website can fetch the package.json and it will have the
> > > > information
> > > > >> >>to
> > > > >> >> display to the user.
> > > > >> >>
> > > > >> >> So what I think we need to do is document and automate the
> > > > information
> > > > >> >>from
> > > > >> >> plugin.xml including engine tags into the package.json.
> > > > >> >>
> > > > >> >> Today we have some sort of duplicate information between the
> > > > "cordova"
> > > > >> >>and
> > > > >> >> "keywords", I think it would be a good time to clean it up and
> > add
> > > an
> > > > >> >>array
> > > > >> >> in cordova.engines
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> On Wed, Sep 23, 2015 at 12:19 PM Nikhil Khandelwal
> > > > >> >><nikhilkh@microsoft.com
> > > > >> >> >
> > > > >> >> wrote:
> > > > >> >>
> > > > >> >> > Merging threads. I was no aware of any security implications
> of
> > > > using
> > > > >> >> > reflection - Perhaps if the reflection target can be
> controlled
> > > > >> >>through
> > > > >> >> > external data. In any case, I understand your hesitation with
> > use
> > > > of
> > > > >> >> > reflection. I would love to have longer discussions on the
> F2F
> > on
> > > > >> what
> > > > >> >> > approaches we could use to make this easier for Cordova
> > > developers.
> > > > >> >> >
> > > > >> >> > Joe: Could you add the appropriate engine tags in any case?
> > > That's
> > > > >> how
> > > > >> >> > Cordova currently handles versioning between plugins &
> > platforms.
> > > > >> >>Also,
> > > > >> >> > does this imply that the plugins should have a major version
> > bump
> > > > as
> > > > >> >>it
> > > > >> >> is
> > > > >> >> > a breaking change? Please create the 5.x branches and if you
> > > could
> > > > >> >> submit a
> > > > >> >> > PR - I had other minor code review comments on the diffs
> below.
> > > > >> >> >
> > > > >> >> > Carlos: I understand in the extreme case it can be a fairly
> > > > >> >>complicated
> > > > >> >> > implementation with lots of criteria to use to determine the
> > > ideal
> > > > >> >>plugin
> > > > >> >> > that might work given a set of platforms. However, trying a
> > > couple
> > > > of
> > > > >> >> > previous versions of the plugins might work 80% of the time
> and
> > > > that
> > > > >> >> might
> > > > >> >> > be good enough. This requires more thought as there are
> quite a
> > > few
> > > > >> >> > scenarios here.
> > > > >> >> >
> > > > >> >> > As for plugin search website helping you find the correct
> > engine
> > > > tags
> > > > >> >>- I
> > > > >> >> > like the idea. But this might requires us maintaining a
> backend
> > > for
> > > > >> >> plugin
> > > > >> >> > search as this is specified in plugin.xml (and not
> > package.json -
> > > > or
> > > > >> >>did
> > > > >> >> we
> > > > >> >> > finally move this?).
> > > > >> >> >
> > > > >> >> > Thanks,
> > > > >> >> > Nikhil
> > > > >> >> >
> > > > >> >> > -----Original Message-----
> > > > >> >> > From: Carlos Santana [mailto:csantana23@gmail.com]
> > > > >> >> > Sent: Tuesday, September 22, 2015 6:14 PM
> > > > >> >> > To: dev@cordova.apache.org
> > > > >> >> > Subject: Re: [Android] 5.0.x release branch?
> > > > >> >> >
> > > > >> >> > +1 we should always use the engine tag to mark the minimum
> > > > compatible
> > > > >> >> > +version at least
> > > > >> >> >
> > > > >> >> > -1 for cordova CLI to automagically to install an older
> > version.
> > > It
> > > > >> >>will
> > > > >> >> > be a pain to get this implemented right, we would need to
> > > download
> > > > >> all
> > > > >> >> the
> > > > >> >> > package.json for multiple versions of the plugin and pick the
> > > > lowest
> > > > >> >> common
> > > > >> >> > denominator based on engine tags and remember that one plugin
> > > > support
> > > > >> >> > multiple engine tags across different platform versions and
> > > > >> >>CLI/plugman.
> > > > >> >> >
> > > > >> >> > This brings an interesting feature to implement In the plugin
> > > > search
> > > > >> >> > website, to display the engine tags for a specific plugin
> > > version.
> > > > >> >> Allowing
> > > > >> >> > a developer to search for a compatible plugin for their
> current
> > > > app.
> > > > >> >> >
> > > > >> >> > - Carlos
> > > > >> >> > Sent from my iPhone
> > > > >> >> >
> > > > >> >> >
> > > > >> >> > -----Original Message-----
> > > > >> >> > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > > >> >> > Sent: Tuesday, September 22, 2015 6:17 PM
> > > > >> >> > To: dev@cordova.apache.org
> > > > >> >> > Subject: Re: [Android] 5.0.x release branch?
> > > > >> >> >
> > > > >> >> > I'm completely against using reflection for this purpose.
> > > Version
> > > > >> >>codes
> > > > >> >> > were invented for a reason and we don't have any mechanism in
> > > place
> > > > >> to
> > > > >> >> unit
> > > > >> >> > test any Android code (or any other native code on any of the
> > > > >> >>platforms).
> > > > >> >> >
> > > > >> >> > I will vote against any release that includes reflection for
> > this
> > > > >> >>purpose
> > > > >> >> > since reflection has only brought us security issues and
> > extreme
> > > > >> >>WebView
> > > > >> >> > breakage when used (Simon can tell you the tales of the HTC
> > > > >> >>console.log
> > > > >> >> > reflection code.).  Reflection is a worst-case scenario tool
> > like
> > > > >> >>when a
> > > > >> >> > method in WebView marked as deprecated completely disappears,
> > not
> > > > >> >> something
> > > > >> >> > we should make a habit of using often.  If we open the door
> for
> > > > this,
> > > > >> >> we'll
> > > > >> >> > get reflection creeping elsewhere, like the Plugins API.
> > > > >> >> >
> > > > >> >> > Just say no to reflection.
> > > > >> >> >
> > > > >> >> >
> > > > >> >> > On Tue, Sep 22, 2015, 5:57 PM Nikhil Khandelwal
> > > > >> >><ni...@microsoft.com>
> > > > >> >> > wrote:
> > > > >> >> >
> > > > >> >> > > Thanks, Joe for the detailed explanation. I understand why
> > > we've
> > > > >> >>taken
> > > > >> >> > > this route. It's good that this is only a build failure.
> One
> > of
> > > > the
> > > > >> >> > > complaints we commonly hear from Cordova developers is that
> > "I
> > > > have
> > > > >> >>a
> > > > >> >> > > cordova project with a certain version of the platform, I
> > need
> > > to
> > > > >> >>find
> > > > >> >> > > the plugin that will work with it". Our CLI always defaults
> > to
> > > > add
> > > > >> >>the
> > > > >> >> > > latest released version of the plugin.
> > > > >> >> > >
> > > > >> >> > > After this breaking change, an existing cordova project
> with
> > > > >> >> > > cordova-android < 5.x, cannot build with the latest version
> > of
> > > > the
> > > > >> >> > > following plugins:
> > > > >> >> > >                 - camera
> > > > >> >> > >                - geolocation
> > > > >> >> > >                - contacts.
> > > > >> >> > > These are some of the most popular plugins in cordova
> plugin
> > > > >> >>ecosystem
> > > > >> >> > [1].
> > > > >> >> > >
> > > > >> >> > > I propose that we should do our best to avoid disruptive
> > > breaking
> > > > >> >> > > changes here. Some ideas that come to mind:
> > > > >> >> > > - As Joe mentioned below - reflection. It has the downsides
> > > that
> > > > >> Joe
> > > > >> >> > > mentioned. No one likes to write code like this it but
> > results
> > > in
> > > > >> >> > > least grief for Cordova users. Some pain here for plugin
> > > > developers
> > > > >> >> > > will simplify the experience for large number of corodva JS
> > > > >> >> > > developers. I know we are doing some of this in cordova-ios
> > [2]
> > > > and
> > > > >> >> > > would love to find ways on how to make this manageable and
> > not
> > > > >> super
> > > > >> >> > ugly.
> > > > >> >> > > - Add an  '<engine name="cordova-android" version=">=5.0.0"
> > />
> > > '
> > > > >> to
> > > > >> >> > > the plugins - failure happens at plugin add in this
> scenario.
> > > > >> >> > > Cordova-lib could be more intelligent to detect this error
> > and
> > > > >> >>resort
> > > > >> >> > > to using an older version of the plugin. The downside of
> this
> > > is
> > > > >> >>that
> > > > >> >> > > these projects cannot use the latest and greatest of these
> > > > plugins.
> > > > >> >> > >
> > > > >> >> > > Thanks,
> > > > >> >> > > Nikhil
> > > > >> >> > >
> > > > >> >> > > [1]
> > > > >> >> > >
> > > > >> >>
> > > >
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordov
> > > > >> >> > >
> > > > >> >>a.apache.org
> > > > %2fuse-the-force-luke%2fplugins%2f%3fsortBy%3dDownloads&da
> > > > >> >> > >
> > > > >> >>ta=01%7c01%7cnikhilkh%40microsoft.com
> > > > %7c5d1a100510734c0605f508d2c3b4b9
> > > > >> >> > >
> > > > >>
> > >
> >>c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7apFzmhrtn%2bKulHrNn46
> > > > >> >> > > kkRG%2bZp3KarDUTf2y0i7P5I%3d
> > > > >> >> > > [2]
> > > > >> >> > >
> > > > >> >>
> > > >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> > > > >> >> > >
> > > > >> >>b.com
> > > > %2fapache%2fcordova-plugin-camera%2fblob%2fmaster%2fsrc%2fios%2fC
> > > > >> >> > >
> > > > >> >>DVCamera.m%23L44&data=01%7c01%7cnikhilkh%40microsoft.com
> > > > %7c5d1a1005107
> > > > >> >> > >
> > > > >>
> > >
> >>34c0605f508d2c3b4b9c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CkH
> > > > >> >> > > zeZ9uQUfYPDdAGlO2PJ9xJz89sZI5bdMRSlQtrMo%3d
> > > > >> >> > >
> > > > >> >> > > Thanks,
> > > > >> >> > > Nikhil
> > > > >> >> > >
> > > > >> >> > >
> > > > >> >> > > -----Original Message-----
> > > > >> >> > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > > >> >> > > Sent: Monday, September 21, 2015 6:32 PM
> > > > >> >> > > To: dev@cordova.apache.org
> > > > >> >> > > Subject: Re: [Android] 5.0.x release branch?
> > > > >> >> > >
> > > > >> >> > > On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal
> > > > >> >> > > <ni...@microsoft.com>
> > > > >> >> > > wrote:
> > > > >> >> > >
> > > > >> >> > > > Can you explain why latest plugins will not be compatible
> > > with
> > > > >> >>older
> > > > >> >> > > > versions of Cordova?
> > > > >> >> > >
> > > > >> >> > >
> > > > >> >> > > They won't be compatible because Cordova-Android compiles
> > > against
> > > > >> >>API
> > > > >> >> > > 22, and these plugins will require API 23 so that they can
> > > detect
> > > > >> >> > > permissions and support Marshmellow.
> > > > >> >> > >
> > > > >> >> > >
> > > > >> >> > > > Can this be avoided by any means?
> > > > >> >> > >
> > > > >> >> > >
> > > > >> >> > > Only with a lot of Java reflection, and I'd rather not
> > subject
> > > > >> >>plugin
> > > > >> >> > > developers to that, or try to hide it under the hood in
> some
> > > > awful
> > > > >> >> > > utility class that everyone will want to see die.  I'm very
> > > much
> > > > a
> > > > >> >>fan
> > > > >> >> > > of if statements because they work, and they're easy to
> read
> > > and
> > > > >> >> > > debug, unlike when bad things happen to things you reflect
> > > into.
> > > > >> >> > > Plugins that require API 23 will only work with
> > Cordova-Android
> > > > 5.0
> > > > >> >> > > and up.  This only impacts five of our core plugins, but
> any
> > > > plugin
> > > > >> >> > > that requires permissions from the Android Manifest will
> have
> > > to
> > > > be
> > > > >> >> > > updated.  If we can avoid using advanced language tricks to
> > > make
> > > > >> the
> > > > >> >> > APKs compatible, we should do that.
> > > > >> >> > >
> > > > >> >> > > When you mean they would not be compatible - will it result
> > in
> > > a
> > > > >> >>build
> > > > >> >> > > or
> > > > >> >> > > > runtime failure?
> > > > >> >> > > >
> > > > >> >> > > >
> > > > >> >> > > This will be a build failure, since API 22 does not have
> > these
> > > > >> >> > > permissions, nor does it have the code required for API 23.
> > > > >> >> > >
> > > > >> >> > >
> > > > >> >> > > > For marshmallow, what is the guidance that we need to
> issue
> > > to
> > > > >> the
> > > > >> >> > > > larger Cordova plugin ecosystem? Joe you are ahead of the
> > > curve
> > > > >> >>here
> > > > >> >> > > > compared to most other plugin developers - a blot post
> > > > explaining
> > > > >> >> > > > what are known gotchas would be great. I really hope we
> can
> > > use
> > > > >> >>our
> > > > >> >> > > > Cordova blog to communicate these changes actively to the
> > > > plugin
> > > > >> >> > ecosystem.
> > > > >> >> > > > This mailing list only gets 400+ subscribers.
> > > > >> >> > > >
> > > > >> >> > > >
> > > > >> >> > > There will be a blog post once 5.0 is released.  We're not
> > > > forcing
> > > > >> >> > > people to upgrade to 5.0, and we will be supporting the 4.x
> > > > branch
> > > > >> >>for
> > > > >> >> > > six months.  This does mean we're stuck supporting 3.x, 4.x
> > and
> > > > 5.x
> > > > >> >> > > for a brief window, but I have no control over when
> > Marshmallow
> > > > is
> > > > >> >> > > released, only whether we want to support it or not.  I
> think
> > > we
> > > > >> do,
> > > > >> >> but
> > > > >> >> > I could be wrong.
> > > > >> >> > >
> > > > >> >> > > At least this should be easier than the jump from 3.x to
> 4.x
> > > for
> > > > >> >>most
> > > > >> >> > > people, but the alternative is that your plugin just
> doesn't
> > > work
> > > > >> at
> > > > >> >> > > all on Marshmallow.  We need to at least give plugin
> > developers
> > > > >> this
> > > > >> >> > > option, since it'll roll out on all the Nexus devices in
> the
> > > next
> > > > >> >>two
> > > > >> >> > > weeks, and we'll hear more about it.
> > > > >> >> > >
> > > > >> >> > >
> > > > >> >> > > > Can you re-base your cordova-android over the current
> > master?
> > > > >> It's
> > > > >> >> > > > hard to see a diff in the current form:
> > > > >> >> > > >
> > > > >> >>
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > > >> >> > > > hu
> > > > >> >> > > >
> > > > >> >>b.com
> > > %2fapache%2fcordova-android%2fcompare%2fmaster...infil00p%3asmo
> > > > >> >> > > > re
> > > > >> >> > > >
> > > > >> >>s&data=01%7c01%7cnikhilkh%40microsoft.com
> > > %7cb451a04dccc64fabdb9608d2
> > > > >> >> > > > c2
> > > > >> >> > > >
> > > > >>
> > >>edb23c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j0bxz39itXdtylHJ
> > > > >> >> > > > lv
> > > > >> >> > > > PYoJpZqXMhFjyTV35I9X5Yxzs%3d
> > > > >> >> > > >
> > > > >> >> > > >
> > > > >> >> > > I had to do a merge commit to get this to happen (boo), but
> > it
> > > > >> >>should
> > > > >> >> > > be mostly cleaned up now.  It seems some style cleanup
> > creeped
> > > > into
> > > > >> >> > > the most recent changes, but this should be a bit more
> > > readable.
> > > > >> >> > >
> > > > >> >> > >
> > > > >> >> > > > -Nikhil
> > > > >> >> > > >
> > > > >> >> > > > -----Original Message-----
> > > > >> >> > > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > > >> >> > > > Sent: Monday, September 21, 2015 2:14 PM
> > > > >> >> > > > To: dev <de...@cordova.apache.org>
> > > > >> >> > > > Subject: [Android] 5.0.x release branch?
> > > > >> >> > > >
> > > > >> >> > > > Hey
> > > > >> >> > > >
> > > > >> >> > > > In the next two weeks, Marshmallow will most likely
> getting
> > > > >> >>released
> > > > >> >> > > > with the brand new Nexus 6P being released from Huawei.
> > > Given
> > > > >> >>that
> > > > >> >> > > > most of the Nexus devices will be getting this release,
> we
> > > > should
> > > > >> >> > > > probably release the 5.0.x branch of Android soon, and
> get
> > > the
> > > > >> new
> > > > >> >> > > plugins updated.
> > > > >> >> > > >
> > > > >> >> > > > It should be noted that the latest plugins will not be
> > > > compatible
> > > > >> >> > > > with older versions of Cordova, which is a big deal.
> This
> > is
> > > > due
> > > > >> >>to
> > > > >> >> > > > the use of various compatibility checks to make sure they
> > > > support
> > > > >> >> > > > Marshmallow and older versions of Android.
> > > > >> >> > > >
> > > > >> >> > > > So, if everyone can look over the smores branches of my
> > > GitHub
> > > > >> >> > > > before I create the 5.0.x branch and pull the changes
> into
> > > it,
> > > > >> >>that
> > > > >> >> > > > would be
> > > > >> >> > > awesome.
> > > > >> >> > > >
> > > > >> >> > > >
> > > > >> >> > > >
> > > > >> >>
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > > >> >> > > > hu
> > > > >> >> > > >
> > > > >> >>b.com
> > > %2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cni
> > > > >> >> > > > kh
> > > > >> >> > > >
> > > > >> >>ilkh%40microsoft.com
> > > %7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86
> > > > >> >> > > > f1
> > > > >> >> > > >
> > > > >>
> > >>41af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%
> > > > >> >> > > > 2b
> > > > >> >> > > > ve4PVcCE%3d
> > > > >> >> > > >
> > > > >> >> > > >
> > > > >> >>
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > > >> >> > > > hu
> > > > >> >> > > >
> > > > >> >>b.com
> > > %2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=0
> > > > >> >> > > > 1%
> > > > >> >> > > >
> > > > >> >>7c01%7cnikhilkh%40microsoft.com
> > > %7c1785194b1f82494fc2d908d2c2c99f36%7
> > > > >> >> > > > c7
> > > > >> >> > > >
> > > > >>
> > >>2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv
> > > > >> >> > > > 6p
> > > > >> >> > > > c5qbeY%2bdUxiP4bc%3d
> > > > >> >> > > >
> > > > >> >> > > >
> > > > >> >>
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > > >> >> > > > hu
> > > > >> >> > > >
> > > > >> >>b.com
> > > %2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c0
> > > > >> >> > > > 1%
> > > > >> >> > > >
> > > > >> >>7cnikhilkh%40microsoft.com
> > > %7c1785194b1f82494fc2d908d2c2c99f36%7c72f9
> > > > >> >> > > > 88
> > > > >> >> > > >
> > > > >>
> > >>bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCG
> > > > >> >> > > > Rb
> > > > >> >> > > > 4zWC8maWpE%3d
> > > > >> >> > > >
> > > > >> >> > > >
> > > > >> >>
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > > >> >> > > > hu
> > > > >> >> > > >
> > > > >> >>b.com
> > > %2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7
> > > > >> >> > > > c0
> > > > >> >> > > >
> > > > >> >>1%7cnikhilkh%40microsoft.com
> > > %7c1785194b1f82494fc2d908d2c2c99f36%7c72
> > > > >> >> > > > f9
> > > > >> >> > > >
> > > > >>
> > >>88bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2
> > > > >> >> > > > fe
> > > > >> >> > > > EmqLOdU%2fwua2TbLU%3d
> > > > >> >> > > >
> > > > >> >> > > > Work on audio is still outstanding, BUT for some reason
> > Audio
> > > > >> >>broke
> > > > >> >> > > > recently on both Lollipop and Marshmallow.  I didn't test
> > it
> > > > out
> > > > >> >>on
> > > > >> >> > > > KitKat or Jellybean yet, but I'm wondering whether we
> > should
> > > > keep
> > > > >> >> > > > maintaining this or support the standard HTML5 audio and
> > deal
> > > > >> with
> > > > >> >> > > > the asset issue somehow (which isn't straight forward).
> > > > >> >> > > >
> > > > >> >> > > > I hopefully want to get a 5.0.x branch happening this
> week
> > if
> > > > we
> > > > >> >>can.
> > > > >> >> > > >
> > > > >> >> > > > What do people think?
> > > > >> >> > > >
> > > > >> >> > > > Joe
> > > > >> >> > > >
> > > > >> >> > >
> > > > >> >> >
> > > > >> >>
> > > > >>
> > > > >>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > > >>
> > > > >>
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > *Frederico Galvão*
> > >
> > > Diretor de Tecnologia
> > >
> > > PontoGet Inovação Web
> > >
> > >
> > > ( +55(62) 8131-5720
> > >
> > > * www.pontoget.com.br <http://www.pontoget.com/>
> > >
> >
>



-- 

*Frederico Galvão*

Diretor de Tecnologia

PontoGet Inovação Web


( +55(62) 8131-5720

* www.pontoget.com.br <http://www.pontoget.com/>

Re: [Android] 5.0.x release branch?

Posted by Steven Gill <st...@gmail.com>.

so plugins that require cordova-android 5.0 + should definitely be adding
an engine tag specifying that.

We could look into some way for cordova-cli possibly fetching older
versions if cordova plugin add fails but I imagine this code being ugly and
easily breakable.

it would be nice to start moving engine tag type stuff out of plugin.xml
and into package.json. We probably want to update our tools to consume that
info from package.json instead of plugin.xml. Something we should make a
proposal for to see how it would look. Adding that info to searching would
be very beneficial. This is for a separate discussion (possibly f2f)





On Wed, Sep 23, 2015 at 2:19 PM, Joe Bowser <bo...@gmail.com> wrote:

> On Wed, Sep 23, 2015 at 2:05 PM, Frederico Galvão <
> frederico.galvao@pontoget.com.br> wrote:
>
> > Based on [1] I think we're overthinking here...
> >
> > I might have missed something, but as far as I understood it all, the
> only
> > thing preventing new plugin versions from working on older
> cordova-android
> > based projects is the POSSIBLE FACT that these projects will still
> > have android:targetSdkVersion="N < 23". It's not a sure bet, it's a
> > possibility. My project, for example, will already
> > have android:targetSdkVersion="23" when I upgrade to cordova-android 5.x
> > with all the plugins upgraded too, so even if I only upgraded the plugins
> > it would still work.
> >
> >
> If you only upgrade the plugins, it won't compile because the new plugins
> now call methods in Cordova 5.0.x to handle the permissions in
> Marshmellow.  We didn't remove any API calls, we just added new ones to
> deal with the API changes on Android to deal with the permissions system
> they're rolling out.  That's why this major version exists at all,
> otherwise you would be right, and this would be a non-issue.
>
>
> > It's common sense for android developers to bump the targetSdkVersion to
> > the latest once a new one comes out, the android APIs are always
> backwards
> > compatible, even if it means for the google team to code migration or
> > compatibility code (which they have always done afaik). If an app
> developer
> > is upgrading his plugins on an existing app, there is no obvious reason
> for
> > him not to also bump the targetSdkVersion. An app developer will always
> > want to support the largest and newest devices, it's a larger audience
> for
> > them anyway.
> >
>
> Upgrading to 5.0 bumps this automatically.
>
>
> > With that said, I don't think any of the mentioned complexity is needed
> > (package.json metadata, plugman version tryouts, engine tags in
> plugin.xml
> > or reflection). We just need to add hooks to the plugins that check the
> > targetSdkVersions on plugin_install, and warn the user about this if it's
> > bellow 23.
> >
> >
> It's needed for plugins that use permissions.  Most plugins aren't affected
> by this, such as plugins for ad networks.
>
> BTW: INTERNET permission isn't one that is prompted.  You can't revoke an
> app's ability to go online.  I think that's dumb, but whatever.
>
>
>
> > [1]
> > > They won't be compatible because Cordova-Android compiles against API
> 22,
> > and these plugins will require API 23 so that they can detect permissions
> > and support Marshmellow.
> >
> > 2015-09-23 15:33 GMT-03:00 Joe Bowser <bo...@gmail.com>:
> >
> > > On Wed, Sep 23, 2015 at 11:30 AM, Joe Bowser <bo...@gmail.com>
> wrote:
> > >
> > > >
> > > > On Wed, Sep 23, 2015 at 11:22 AM, Homer, Tony <to...@intel.com>
> > > > wrote:
> > > >
> > > >> Joe-
> > > >>
> > > >> As far as I can tell, the API 23 calls are currently unguarded so
> > smores
> > > >> will only work on M Preview.
> > > >> I know your smores branch is a POC, but I was wondering about
> > backwards
> > > >> compatibility.
> > > >> Do you anticipate adding Build.VERSION.SDK_INT >=
> > Build.VERSION_CODES.M
> > > >> guard clauses for backwards compatibility?
> > > >>
> > > >>
> > > > This already exists in each of the plugins when they do the
> permissions
> > > > check, and smores works perfectly fine on Lollipop so far.  Right
> now,
> > if
> > > > you aren't running M, you don't do the permissions check, and you
> don't
> > > > call the methods.  I haven't tested it on earlier versions of
> Android,
> > > but
> > > > I expect it to work on Kitkat and Jellybean the same way.
> > > >
> > > >
> > > >
> > >
> > > And yes, we can probably create a utility method, that said, most
> plugins
> > > aren't directly affected by this, only the ones that require extra
> > > permissions.  It'd be good if we had an idea of what third party
> plugins
> > > people are actually using that would run afowl of this and see where
> they
> > > would fail.  But I already have more than enough work currently, and
> > > adopting other people's plugins is not something I want to get in the
> > habit
> > > of doing.
> > >
> > >
> > >
> > > > Tony
> > > >>
> > > >> On 9/23/15, 1:56 PM, "Joe Bowser" <bo...@gmail.com> wrote:
> > > >>
> > > >> >On Wed, Sep 23, 2015 at 9:36 AM, Carlos Santana <
> > csantana23@gmail.com>
> > > >> >wrote:
> > > >> >
> > > >> >> No need to major version change for the Plugins, the API of the
> > > didn't
> > > >> >> change.
> > > >> >> Web developer still uses the same JS API to use the plugin.
> > > >> >>
> > > >> >>
> > > >> >I would do a major version bump on Geolocation.  The API itself
> > didn't
> > > >> >change but the behaviour certainly did.  On Marshmallow we have to
> > add
> > > >> >this
> > > >> >extra shim that asks for permission, which means that there's now
> > code
> > > >> >attached to Android Geolocation that didn't exist before.  All the
> > > other
> > > >> >plugins should still be fine.
> > > >> >
> > > >> >
> > > >> >> Yes I did some thinking around the plugin search website. I think
> > is
> > > a
> > > >> >>good
> > > >> >> topic for the F2F.
> > > >> >> Now that IBM is using Cordova Plugin more heavily to package our
> > > mobile
> > > >> >> SDKs using Cordova Plugins, I think is beneficial to expose more
> > info
> > > >> >>about
> > > >> >> the plugin including engine tags
> > > >> >>
> > > >> >> I would not go and build our own backend and have our own
> registry
> > > with
> > > >> >> cordova metadata.
> > > >> >>
> > > >> >> I think the solution is to put the metadata of plugin.xml into
> > > >> >> package.json. We can show fast results in main search, but then
> > user
> > > >> can
> > > >> >> drill into the plugin details, and we can have a view with more
> > > >> >>information
> > > >> >> and allow the user to select a specific version like we have
> today
> > in
> > > >> >>our
> > > >> >> plugin website search using the cordova registry.
> > > >> >>
> > > >> >> The website can fetch the package.json and it will have the
> > > information
> > > >> >>to
> > > >> >> display to the user.
> > > >> >>
> > > >> >> So what I think we need to do is document and automate the
> > > information
> > > >> >>from
> > > >> >> plugin.xml including engine tags into the package.json.
> > > >> >>
> > > >> >> Today we have some sort of duplicate information between the
> > > "cordova"
> > > >> >>and
> > > >> >> "keywords", I think it would be a good time to clean it up and
> add
> > an
> > > >> >>array
> > > >> >> in cordova.engines
> > > >> >>
> > > >> >>
> > > >> >>
> > > >> >> On Wed, Sep 23, 2015 at 12:19 PM Nikhil Khandelwal
> > > >> >><nikhilkh@microsoft.com
> > > >> >> >
> > > >> >> wrote:
> > > >> >>
> > > >> >> > Merging threads. I was no aware of any security implications of
> > > using
> > > >> >> > reflection - Perhaps if the reflection target can be controlled
> > > >> >>through
> > > >> >> > external data. In any case, I understand your hesitation with
> use
> > > of
> > > >> >> > reflection. I would love to have longer discussions on the F2F
> on
> > > >> what
> > > >> >> > approaches we could use to make this easier for Cordova
> > developers.
> > > >> >> >
> > > >> >> > Joe: Could you add the appropriate engine tags in any case?
> > That's
> > > >> how
> > > >> >> > Cordova currently handles versioning between plugins &
> platforms.
> > > >> >>Also,
> > > >> >> > does this imply that the plugins should have a major version
> bump
> > > as
> > > >> >>it
> > > >> >> is
> > > >> >> > a breaking change? Please create the 5.x branches and if you
> > could
> > > >> >> submit a
> > > >> >> > PR - I had other minor code review comments on the diffs below.
> > > >> >> >
> > > >> >> > Carlos: I understand in the extreme case it can be a fairly
> > > >> >>complicated
> > > >> >> > implementation with lots of criteria to use to determine the
> > ideal
> > > >> >>plugin
> > > >> >> > that might work given a set of platforms. However, trying a
> > couple
> > > of
> > > >> >> > previous versions of the plugins might work 80% of the time and
> > > that
> > > >> >> might
> > > >> >> > be good enough. This requires more thought as there are quite a
> > few
> > > >> >> > scenarios here.
> > > >> >> >
> > > >> >> > As for plugin search website helping you find the correct
> engine
> > > tags
> > > >> >>- I
> > > >> >> > like the idea. But this might requires us maintaining a backend
> > for
> > > >> >> plugin
> > > >> >> > search as this is specified in plugin.xml (and not
> package.json -
> > > or
> > > >> >>did
> > > >> >> we
> > > >> >> > finally move this?).
> > > >> >> >
> > > >> >> > Thanks,
> > > >> >> > Nikhil
> > > >> >> >
> > > >> >> > -----Original Message-----
> > > >> >> > From: Carlos Santana [mailto:csantana23@gmail.com]
> > > >> >> > Sent: Tuesday, September 22, 2015 6:14 PM
> > > >> >> > To: dev@cordova.apache.org
> > > >> >> > Subject: Re: [Android] 5.0.x release branch?
> > > >> >> >
> > > >> >> > +1 we should always use the engine tag to mark the minimum
> > > compatible
> > > >> >> > +version at least
> > > >> >> >
> > > >> >> > -1 for cordova CLI to automagically to install an older
> version.
> > It
> > > >> >>will
> > > >> >> > be a pain to get this implemented right, we would need to
> > download
> > > >> all
> > > >> >> the
> > > >> >> > package.json for multiple versions of the plugin and pick the
> > > lowest
> > > >> >> common
> > > >> >> > denominator based on engine tags and remember that one plugin
> > > support
> > > >> >> > multiple engine tags across different platform versions and
> > > >> >>CLI/plugman.
> > > >> >> >
> > > >> >> > This brings an interesting feature to implement In the plugin
> > > search
> > > >> >> > website, to display the engine tags for a specific plugin
> > version.
> > > >> >> Allowing
> > > >> >> > a developer to search for a compatible plugin for their current
> > > app.
> > > >> >> >
> > > >> >> > - Carlos
> > > >> >> > Sent from my iPhone
> > > >> >> >
> > > >> >> >
> > > >> >> > -----Original Message-----
> > > >> >> > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > >> >> > Sent: Tuesday, September 22, 2015 6:17 PM
> > > >> >> > To: dev@cordova.apache.org
> > > >> >> > Subject: Re: [Android] 5.0.x release branch?
> > > >> >> >
> > > >> >> > I'm completely against using reflection for this purpose.
> > Version
> > > >> >>codes
> > > >> >> > were invented for a reason and we don't have any mechanism in
> > place
> > > >> to
> > > >> >> unit
> > > >> >> > test any Android code (or any other native code on any of the
> > > >> >>platforms).
> > > >> >> >
> > > >> >> > I will vote against any release that includes reflection for
> this
> > > >> >>purpose
> > > >> >> > since reflection has only brought us security issues and
> extreme
> > > >> >>WebView
> > > >> >> > breakage when used (Simon can tell you the tales of the HTC
> > > >> >>console.log
> > > >> >> > reflection code.).  Reflection is a worst-case scenario tool
> like
> > > >> >>when a
> > > >> >> > method in WebView marked as deprecated completely disappears,
> not
> > > >> >> something
> > > >> >> > we should make a habit of using often.  If we open the door for
> > > this,
> > > >> >> we'll
> > > >> >> > get reflection creeping elsewhere, like the Plugins API.
> > > >> >> >
> > > >> >> > Just say no to reflection.
> > > >> >> >
> > > >> >> >
> > > >> >> > On Tue, Sep 22, 2015, 5:57 PM Nikhil Khandelwal
> > > >> >><ni...@microsoft.com>
> > > >> >> > wrote:
> > > >> >> >
> > > >> >> > > Thanks, Joe for the detailed explanation. I understand why
> > we've
> > > >> >>taken
> > > >> >> > > this route. It's good that this is only a build failure. One
> of
> > > the
> > > >> >> > > complaints we commonly hear from Cordova developers is that
> "I
> > > have
> > > >> >>a
> > > >> >> > > cordova project with a certain version of the platform, I
> need
> > to
> > > >> >>find
> > > >> >> > > the plugin that will work with it". Our CLI always defaults
> to
> > > add
> > > >> >>the
> > > >> >> > > latest released version of the plugin.
> > > >> >> > >
> > > >> >> > > After this breaking change, an existing cordova project with
> > > >> >> > > cordova-android < 5.x, cannot build with the latest version
> of
> > > the
> > > >> >> > > following plugins:
> > > >> >> > >                 - camera
> > > >> >> > >                - geolocation
> > > >> >> > >                - contacts.
> > > >> >> > > These are some of the most popular plugins in cordova plugin
> > > >> >>ecosystem
> > > >> >> > [1].
> > > >> >> > >
> > > >> >> > > I propose that we should do our best to avoid disruptive
> > breaking
> > > >> >> > > changes here. Some ideas that come to mind:
> > > >> >> > > - As Joe mentioned below - reflection. It has the downsides
> > that
> > > >> Joe
> > > >> >> > > mentioned. No one likes to write code like this it but
> results
> > in
> > > >> >> > > least grief for Cordova users. Some pain here for plugin
> > > developers
> > > >> >> > > will simplify the experience for large number of corodva JS
> > > >> >> > > developers. I know we are doing some of this in cordova-ios
> [2]
> > > and
> > > >> >> > > would love to find ways on how to make this manageable and
> not
> > > >> super
> > > >> >> > ugly.
> > > >> >> > > - Add an  '<engine name="cordova-android" version=">=5.0.0"
> />
> > '
> > > >> to
> > > >> >> > > the plugins - failure happens at plugin add in this scenario.
> > > >> >> > > Cordova-lib could be more intelligent to detect this error
> and
> > > >> >>resort
> > > >> >> > > to using an older version of the plugin. The downside of this
> > is
> > > >> >>that
> > > >> >> > > these projects cannot use the latest and greatest of these
> > > plugins.
> > > >> >> > >
> > > >> >> > > Thanks,
> > > >> >> > > Nikhil
> > > >> >> > >
> > > >> >> > > [1]
> > > >> >> > >
> > > >> >>
> > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordov
> > > >> >> > >
> > > >> >>a.apache.org
> > > %2fuse-the-force-luke%2fplugins%2f%3fsortBy%3dDownloads&da
> > > >> >> > >
> > > >> >>ta=01%7c01%7cnikhilkh%40microsoft.com
> > > %7c5d1a100510734c0605f508d2c3b4b9
> > > >> >> > >
> > > >>
> > >>c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7apFzmhrtn%2bKulHrNn46
> > > >> >> > > kkRG%2bZp3KarDUTf2y0i7P5I%3d
> > > >> >> > > [2]
> > > >> >> > >
> > > >> >>
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> > > >> >> > >
> > > >> >>b.com
> > > %2fapache%2fcordova-plugin-camera%2fblob%2fmaster%2fsrc%2fios%2fC
> > > >> >> > >
> > > >> >>DVCamera.m%23L44&data=01%7c01%7cnikhilkh%40microsoft.com
> > > %7c5d1a1005107
> > > >> >> > >
> > > >>
> > >>34c0605f508d2c3b4b9c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CkH
> > > >> >> > > zeZ9uQUfYPDdAGlO2PJ9xJz89sZI5bdMRSlQtrMo%3d
> > > >> >> > >
> > > >> >> > > Thanks,
> > > >> >> > > Nikhil
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > -----Original Message-----
> > > >> >> > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > >> >> > > Sent: Monday, September 21, 2015 6:32 PM
> > > >> >> > > To: dev@cordova.apache.org
> > > >> >> > > Subject: Re: [Android] 5.0.x release branch?
> > > >> >> > >
> > > >> >> > > On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal
> > > >> >> > > <ni...@microsoft.com>
> > > >> >> > > wrote:
> > > >> >> > >
> > > >> >> > > > Can you explain why latest plugins will not be compatible
> > with
> > > >> >>older
> > > >> >> > > > versions of Cordova?
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > They won't be compatible because Cordova-Android compiles
> > against
> > > >> >>API
> > > >> >> > > 22, and these plugins will require API 23 so that they can
> > detect
> > > >> >> > > permissions and support Marshmellow.
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > > Can this be avoided by any means?
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > Only with a lot of Java reflection, and I'd rather not
> subject
> > > >> >>plugin
> > > >> >> > > developers to that, or try to hide it under the hood in some
> > > awful
> > > >> >> > > utility class that everyone will want to see die.  I'm very
> > much
> > > a
> > > >> >>fan
> > > >> >> > > of if statements because they work, and they're easy to read
> > and
> > > >> >> > > debug, unlike when bad things happen to things you reflect
> > into.
> > > >> >> > > Plugins that require API 23 will only work with
> Cordova-Android
> > > 5.0
> > > >> >> > > and up.  This only impacts five of our core plugins, but any
> > > plugin
> > > >> >> > > that requires permissions from the Android Manifest will have
> > to
> > > be
> > > >> >> > > updated.  If we can avoid using advanced language tricks to
> > make
> > > >> the
> > > >> >> > APKs compatible, we should do that.
> > > >> >> > >
> > > >> >> > > When you mean they would not be compatible - will it result
> in
> > a
> > > >> >>build
> > > >> >> > > or
> > > >> >> > > > runtime failure?
> > > >> >> > > >
> > > >> >> > > >
> > > >> >> > > This will be a build failure, since API 22 does not have
> these
> > > >> >> > > permissions, nor does it have the code required for API 23.
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > > For marshmallow, what is the guidance that we need to issue
> > to
> > > >> the
> > > >> >> > > > larger Cordova plugin ecosystem? Joe you are ahead of the
> > curve
> > > >> >>here
> > > >> >> > > > compared to most other plugin developers - a blot post
> > > explaining
> > > >> >> > > > what are known gotchas would be great. I really hope we can
> > use
> > > >> >>our
> > > >> >> > > > Cordova blog to communicate these changes actively to the
> > > plugin
> > > >> >> > ecosystem.
> > > >> >> > > > This mailing list only gets 400+ subscribers.
> > > >> >> > > >
> > > >> >> > > >
> > > >> >> > > There will be a blog post once 5.0 is released.  We're not
> > > forcing
> > > >> >> > > people to upgrade to 5.0, and we will be supporting the 4.x
> > > branch
> > > >> >>for
> > > >> >> > > six months.  This does mean we're stuck supporting 3.x, 4.x
> and
> > > 5.x
> > > >> >> > > for a brief window, but I have no control over when
> Marshmallow
> > > is
> > > >> >> > > released, only whether we want to support it or not.  I think
> > we
> > > >> do,
> > > >> >> but
> > > >> >> > I could be wrong.
> > > >> >> > >
> > > >> >> > > At least this should be easier than the jump from 3.x to 4.x
> > for
> > > >> >>most
> > > >> >> > > people, but the alternative is that your plugin just doesn't
> > work
> > > >> at
> > > >> >> > > all on Marshmallow.  We need to at least give plugin
> developers
> > > >> this
> > > >> >> > > option, since it'll roll out on all the Nexus devices in the
> > next
> > > >> >>two
> > > >> >> > > weeks, and we'll hear more about it.
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > > Can you re-base your cordova-android over the current
> master?
> > > >> It's
> > > >> >> > > > hard to see a diff in the current form:
> > > >> >> > > >
> > > >> >>
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > >> >> > > > hu
> > > >> >> > > >
> > > >> >>b.com
> > %2fapache%2fcordova-android%2fcompare%2fmaster...infil00p%3asmo
> > > >> >> > > > re
> > > >> >> > > >
> > > >> >>s&data=01%7c01%7cnikhilkh%40microsoft.com
> > %7cb451a04dccc64fabdb9608d2
> > > >> >> > > > c2
> > > >> >> > > >
> > > >>
> >>edb23c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j0bxz39itXdtylHJ
> > > >> >> > > > lv
> > > >> >> > > > PYoJpZqXMhFjyTV35I9X5Yxzs%3d
> > > >> >> > > >
> > > >> >> > > >
> > > >> >> > > I had to do a merge commit to get this to happen (boo), but
> it
> > > >> >>should
> > > >> >> > > be mostly cleaned up now.  It seems some style cleanup
> creeped
> > > into
> > > >> >> > > the most recent changes, but this should be a bit more
> > readable.
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > > -Nikhil
> > > >> >> > > >
> > > >> >> > > > -----Original Message-----
> > > >> >> > > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > >> >> > > > Sent: Monday, September 21, 2015 2:14 PM
> > > >> >> > > > To: dev <de...@cordova.apache.org>
> > > >> >> > > > Subject: [Android] 5.0.x release branch?
> > > >> >> > > >
> > > >> >> > > > Hey
> > > >> >> > > >
> > > >> >> > > > In the next two weeks, Marshmallow will most likely getting
> > > >> >>released
> > > >> >> > > > with the brand new Nexus 6P being released from Huawei.
> > Given
> > > >> >>that
> > > >> >> > > > most of the Nexus devices will be getting this release, we
> > > should
> > > >> >> > > > probably release the 5.0.x branch of Android soon, and get
> > the
> > > >> new
> > > >> >> > > plugins updated.
> > > >> >> > > >
> > > >> >> > > > It should be noted that the latest plugins will not be
> > > compatible
> > > >> >> > > > with older versions of Cordova, which is a big deal.  This
> is
> > > due
> > > >> >>to
> > > >> >> > > > the use of various compatibility checks to make sure they
> > > support
> > > >> >> > > > Marshmallow and older versions of Android.
> > > >> >> > > >
> > > >> >> > > > So, if everyone can look over the smores branches of my
> > GitHub
> > > >> >> > > > before I create the 5.0.x branch and pull the changes into
> > it,
> > > >> >>that
> > > >> >> > > > would be
> > > >> >> > > awesome.
> > > >> >> > > >
> > > >> >> > > >
> > > >> >> > > >
> > > >> >>
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > >> >> > > > hu
> > > >> >> > > >
> > > >> >>b.com
> > %2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cni
> > > >> >> > > > kh
> > > >> >> > > >
> > > >> >>ilkh%40microsoft.com
> > %7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86
> > > >> >> > > > f1
> > > >> >> > > >
> > > >>
> >>41af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%
> > > >> >> > > > 2b
> > > >> >> > > > ve4PVcCE%3d
> > > >> >> > > >
> > > >> >> > > >
> > > >> >>
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > >> >> > > > hu
> > > >> >> > > >
> > > >> >>b.com
> > %2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=0
> > > >> >> > > > 1%
> > > >> >> > > >
> > > >> >>7c01%7cnikhilkh%40microsoft.com
> > %7c1785194b1f82494fc2d908d2c2c99f36%7
> > > >> >> > > > c7
> > > >> >> > > >
> > > >>
> >>2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv
> > > >> >> > > > 6p
> > > >> >> > > > c5qbeY%2bdUxiP4bc%3d
> > > >> >> > > >
> > > >> >> > > >
> > > >> >>
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > >> >> > > > hu
> > > >> >> > > >
> > > >> >>b.com
> > %2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c0
> > > >> >> > > > 1%
> > > >> >> > > >
> > > >> >>7cnikhilkh%40microsoft.com
> > %7c1785194b1f82494fc2d908d2c2c99f36%7c72f9
> > > >> >> > > > 88
> > > >> >> > > >
> > > >>
> >>bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCG
> > > >> >> > > > Rb
> > > >> >> > > > 4zWC8maWpE%3d
> > > >> >> > > >
> > > >> >> > > >
> > > >> >>
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > >> >> > > > hu
> > > >> >> > > >
> > > >> >>b.com
> > %2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7
> > > >> >> > > > c0
> > > >> >> > > >
> > > >> >>1%7cnikhilkh%40microsoft.com
> > %7c1785194b1f82494fc2d908d2c2c99f36%7c72
> > > >> >> > > > f9
> > > >> >> > > >
> > > >>
> >>88bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2
> > > >> >> > > > fe
> > > >> >> > > > EmqLOdU%2fwua2TbLU%3d
> > > >> >> > > >
> > > >> >> > > > Work on audio is still outstanding, BUT for some reason
> Audio
> > > >> >>broke
> > > >> >> > > > recently on both Lollipop and Marshmallow.  I didn't test
> it
> > > out
> > > >> >>on
> > > >> >> > > > KitKat or Jellybean yet, but I'm wondering whether we
> should
> > > keep
> > > >> >> > > > maintaining this or support the standard HTML5 audio and
> deal
> > > >> with
> > > >> >> > > > the asset issue somehow (which isn't straight forward).
> > > >> >> > > >
> > > >> >> > > > I hopefully want to get a 5.0.x branch happening this week
> if
> > > we
> > > >> >>can.
> > > >> >> > > >
> > > >> >> > > > What do people think?
> > > >> >> > > >
> > > >> >> > > > Joe
> > > >> >> > > >
> > > >> >> > >
> > > >> >> >
> > > >> >>
> > > >>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > >>
> > > >>
> > > >
> > >
> >
> >
> >
> > --
> >
> > *Frederico Galvão*
> >
> > Diretor de Tecnologia
> >
> > PontoGet Inovação Web
> >
> >
> > ( +55(62) 8131-5720
> >
> > * www.pontoget.com.br <http://www.pontoget.com/>
> >
>

Re: [Android] 5.0.x release branch?

Posted by Joe Bowser <bo...@gmail.com>.

On Wed, Sep 23, 2015 at 2:05 PM, Frederico Galvão <
frederico.galvao@pontoget.com.br> wrote:

> Based on [1] I think we're overthinking here...
>
> I might have missed something, but as far as I understood it all, the only
> thing preventing new plugin versions from working on older cordova-android
> based projects is the POSSIBLE FACT that these projects will still
> have android:targetSdkVersion="N < 23". It's not a sure bet, it's a
> possibility. My project, for example, will already
> have android:targetSdkVersion="23" when I upgrade to cordova-android 5.x
> with all the plugins upgraded too, so even if I only upgraded the plugins
> it would still work.
>
>
If you only upgrade the plugins, it won't compile because the new plugins
now call methods in Cordova 5.0.x to handle the permissions in
Marshmellow.  We didn't remove any API calls, we just added new ones to
deal with the API changes on Android to deal with the permissions system
they're rolling out.  That's why this major version exists at all,
otherwise you would be right, and this would be a non-issue.


> It's common sense for android developers to bump the targetSdkVersion to
> the latest once a new one comes out, the android APIs are always backwards
> compatible, even if it means for the google team to code migration or
> compatibility code (which they have always done afaik). If an app developer
> is upgrading his plugins on an existing app, there is no obvious reason for
> him not to also bump the targetSdkVersion. An app developer will always
> want to support the largest and newest devices, it's a larger audience for
> them anyway.
>

Upgrading to 5.0 bumps this automatically.


> With that said, I don't think any of the mentioned complexity is needed
> (package.json metadata, plugman version tryouts, engine tags in plugin.xml
> or reflection). We just need to add hooks to the plugins that check the
> targetSdkVersions on plugin_install, and warn the user about this if it's
> bellow 23.
>
>
It's needed for plugins that use permissions.  Most plugins aren't affected
by this, such as plugins for ad networks.

BTW: INTERNET permission isn't one that is prompted.  You can't revoke an
app's ability to go online.  I think that's dumb, but whatever.



> [1]
> > They won't be compatible because Cordova-Android compiles against API 22,
> and these plugins will require API 23 so that they can detect permissions
> and support Marshmellow.
>
> 2015-09-23 15:33 GMT-03:00 Joe Bowser <bo...@gmail.com>:
>
> > On Wed, Sep 23, 2015 at 11:30 AM, Joe Bowser <bo...@gmail.com> wrote:
> >
> > >
> > > On Wed, Sep 23, 2015 at 11:22 AM, Homer, Tony <to...@intel.com>
> > > wrote:
> > >
> > >> Joe-
> > >>
> > >> As far as I can tell, the API 23 calls are currently unguarded so
> smores
> > >> will only work on M Preview.
> > >> I know your smores branch is a POC, but I was wondering about
> backwards
> > >> compatibility.
> > >> Do you anticipate adding Build.VERSION.SDK_INT >=
> Build.VERSION_CODES.M
> > >> guard clauses for backwards compatibility?
> > >>
> > >>
> > > This already exists in each of the plugins when they do the permissions
> > > check, and smores works perfectly fine on Lollipop so far.  Right now,
> if
> > > you aren't running M, you don't do the permissions check, and you don't
> > > call the methods.  I haven't tested it on earlier versions of Android,
> > but
> > > I expect it to work on Kitkat and Jellybean the same way.
> > >
> > >
> > >
> >
> > And yes, we can probably create a utility method, that said, most plugins
> > aren't directly affected by this, only the ones that require extra
> > permissions.  It'd be good if we had an idea of what third party plugins
> > people are actually using that would run afowl of this and see where they
> > would fail.  But I already have more than enough work currently, and
> > adopting other people's plugins is not something I want to get in the
> habit
> > of doing.
> >
> >
> >
> > > Tony
> > >>
> > >> On 9/23/15, 1:56 PM, "Joe Bowser" <bo...@gmail.com> wrote:
> > >>
> > >> >On Wed, Sep 23, 2015 at 9:36 AM, Carlos Santana <
> csantana23@gmail.com>
> > >> >wrote:
> > >> >
> > >> >> No need to major version change for the Plugins, the API of the
> > didn't
> > >> >> change.
> > >> >> Web developer still uses the same JS API to use the plugin.
> > >> >>
> > >> >>
> > >> >I would do a major version bump on Geolocation.  The API itself
> didn't
> > >> >change but the behaviour certainly did.  On Marshmallow we have to
> add
> > >> >this
> > >> >extra shim that asks for permission, which means that there's now
> code
> > >> >attached to Android Geolocation that didn't exist before.  All the
> > other
> > >> >plugins should still be fine.
> > >> >
> > >> >
> > >> >> Yes I did some thinking around the plugin search website. I think
> is
> > a
> > >> >>good
> > >> >> topic for the F2F.
> > >> >> Now that IBM is using Cordova Plugin more heavily to package our
> > mobile
> > >> >> SDKs using Cordova Plugins, I think is beneficial to expose more
> info
> > >> >>about
> > >> >> the plugin including engine tags
> > >> >>
> > >> >> I would not go and build our own backend and have our own registry
> > with
> > >> >> cordova metadata.
> > >> >>
> > >> >> I think the solution is to put the metadata of plugin.xml into
> > >> >> package.json. We can show fast results in main search, but then
> user
> > >> can
> > >> >> drill into the plugin details, and we can have a view with more
> > >> >>information
> > >> >> and allow the user to select a specific version like we have today
> in
> > >> >>our
> > >> >> plugin website search using the cordova registry.
> > >> >>
> > >> >> The website can fetch the package.json and it will have the
> > information
> > >> >>to
> > >> >> display to the user.
> > >> >>
> > >> >> So what I think we need to do is document and automate the
> > information
> > >> >>from
> > >> >> plugin.xml including engine tags into the package.json.
> > >> >>
> > >> >> Today we have some sort of duplicate information between the
> > "cordova"
> > >> >>and
> > >> >> "keywords", I think it would be a good time to clean it up and add
> an
> > >> >>array
> > >> >> in cordova.engines
> > >> >>
> > >> >>
> > >> >>
> > >> >> On Wed, Sep 23, 2015 at 12:19 PM Nikhil Khandelwal
> > >> >><nikhilkh@microsoft.com
> > >> >> >
> > >> >> wrote:
> > >> >>
> > >> >> > Merging threads. I was no aware of any security implications of
> > using
> > >> >> > reflection - Perhaps if the reflection target can be controlled
> > >> >>through
> > >> >> > external data. In any case, I understand your hesitation with use
> > of
> > >> >> > reflection. I would love to have longer discussions on the F2F on
> > >> what
> > >> >> > approaches we could use to make this easier for Cordova
> developers.
> > >> >> >
> > >> >> > Joe: Could you add the appropriate engine tags in any case?
> That's
> > >> how
> > >> >> > Cordova currently handles versioning between plugins & platforms.
> > >> >>Also,
> > >> >> > does this imply that the plugins should have a major version bump
> > as
> > >> >>it
> > >> >> is
> > >> >> > a breaking change? Please create the 5.x branches and if you
> could
> > >> >> submit a
> > >> >> > PR - I had other minor code review comments on the diffs below.
> > >> >> >
> > >> >> > Carlos: I understand in the extreme case it can be a fairly
> > >> >>complicated
> > >> >> > implementation with lots of criteria to use to determine the
> ideal
> > >> >>plugin
> > >> >> > that might work given a set of platforms. However, trying a
> couple
> > of
> > >> >> > previous versions of the plugins might work 80% of the time and
> > that
> > >> >> might
> > >> >> > be good enough. This requires more thought as there are quite a
> few
> > >> >> > scenarios here.
> > >> >> >
> > >> >> > As for plugin search website helping you find the correct engine
> > tags
> > >> >>- I
> > >> >> > like the idea. But this might requires us maintaining a backend
> for
> > >> >> plugin
> > >> >> > search as this is specified in plugin.xml (and not package.json -
> > or
> > >> >>did
> > >> >> we
> > >> >> > finally move this?).
> > >> >> >
> > >> >> > Thanks,
> > >> >> > Nikhil
> > >> >> >
> > >> >> > -----Original Message-----
> > >> >> > From: Carlos Santana [mailto:csantana23@gmail.com]
> > >> >> > Sent: Tuesday, September 22, 2015 6:14 PM
> > >> >> > To: dev@cordova.apache.org
> > >> >> > Subject: Re: [Android] 5.0.x release branch?
> > >> >> >
> > >> >> > +1 we should always use the engine tag to mark the minimum
> > compatible
> > >> >> > +version at least
> > >> >> >
> > >> >> > -1 for cordova CLI to automagically to install an older version.
> It
> > >> >>will
> > >> >> > be a pain to get this implemented right, we would need to
> download
> > >> all
> > >> >> the
> > >> >> > package.json for multiple versions of the plugin and pick the
> > lowest
> > >> >> common
> > >> >> > denominator based on engine tags and remember that one plugin
> > support
> > >> >> > multiple engine tags across different platform versions and
> > >> >>CLI/plugman.
> > >> >> >
> > >> >> > This brings an interesting feature to implement In the plugin
> > search
> > >> >> > website, to display the engine tags for a specific plugin
> version.
> > >> >> Allowing
> > >> >> > a developer to search for a compatible plugin for their current
> > app.
> > >> >> >
> > >> >> > - Carlos
> > >> >> > Sent from my iPhone
> > >> >> >
> > >> >> >
> > >> >> > -----Original Message-----
> > >> >> > From: Joe Bowser [mailto:bowserj@gmail.com]
> > >> >> > Sent: Tuesday, September 22, 2015 6:17 PM
> > >> >> > To: dev@cordova.apache.org
> > >> >> > Subject: Re: [Android] 5.0.x release branch?
> > >> >> >
> > >> >> > I'm completely against using reflection for this purpose.
> Version
> > >> >>codes
> > >> >> > were invented for a reason and we don't have any mechanism in
> place
> > >> to
> > >> >> unit
> > >> >> > test any Android code (or any other native code on any of the
> > >> >>platforms).
> > >> >> >
> > >> >> > I will vote against any release that includes reflection for this
> > >> >>purpose
> > >> >> > since reflection has only brought us security issues and extreme
> > >> >>WebView
> > >> >> > breakage when used (Simon can tell you the tales of the HTC
> > >> >>console.log
> > >> >> > reflection code.).  Reflection is a worst-case scenario tool like
> > >> >>when a
> > >> >> > method in WebView marked as deprecated completely disappears, not
> > >> >> something
> > >> >> > we should make a habit of using often.  If we open the door for
> > this,
> > >> >> we'll
> > >> >> > get reflection creeping elsewhere, like the Plugins API.
> > >> >> >
> > >> >> > Just say no to reflection.
> > >> >> >
> > >> >> >
> > >> >> > On Tue, Sep 22, 2015, 5:57 PM Nikhil Khandelwal
> > >> >><ni...@microsoft.com>
> > >> >> > wrote:
> > >> >> >
> > >> >> > > Thanks, Joe for the detailed explanation. I understand why
> we've
> > >> >>taken
> > >> >> > > this route. It's good that this is only a build failure. One of
> > the
> > >> >> > > complaints we commonly hear from Cordova developers is that "I
> > have
> > >> >>a
> > >> >> > > cordova project with a certain version of the platform, I need
> to
> > >> >>find
> > >> >> > > the plugin that will work with it". Our CLI always defaults to
> > add
> > >> >>the
> > >> >> > > latest released version of the plugin.
> > >> >> > >
> > >> >> > > After this breaking change, an existing cordova project with
> > >> >> > > cordova-android < 5.x, cannot build with the latest version of
> > the
> > >> >> > > following plugins:
> > >> >> > >                 - camera
> > >> >> > >                - geolocation
> > >> >> > >                - contacts.
> > >> >> > > These are some of the most popular plugins in cordova plugin
> > >> >>ecosystem
> > >> >> > [1].
> > >> >> > >
> > >> >> > > I propose that we should do our best to avoid disruptive
> breaking
> > >> >> > > changes here. Some ideas that come to mind:
> > >> >> > > - As Joe mentioned below - reflection. It has the downsides
> that
> > >> Joe
> > >> >> > > mentioned. No one likes to write code like this it but results
> in
> > >> >> > > least grief for Cordova users. Some pain here for plugin
> > developers
> > >> >> > > will simplify the experience for large number of corodva JS
> > >> >> > > developers. I know we are doing some of this in cordova-ios [2]
> > and
> > >> >> > > would love to find ways on how to make this manageable and not
> > >> super
> > >> >> > ugly.
> > >> >> > > - Add an  '<engine name="cordova-android" version=">=5.0.0" />
> '
> > >> to
> > >> >> > > the plugins - failure happens at plugin add in this scenario.
> > >> >> > > Cordova-lib could be more intelligent to detect this error and
> > >> >>resort
> > >> >> > > to using an older version of the plugin. The downside of this
> is
> > >> >>that
> > >> >> > > these projects cannot use the latest and greatest of these
> > plugins.
> > >> >> > >
> > >> >> > > Thanks,
> > >> >> > > Nikhil
> > >> >> > >
> > >> >> > > [1]
> > >> >> > >
> > >> >>
> > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordov
> > >> >> > >
> > >> >>a.apache.org
> > %2fuse-the-force-luke%2fplugins%2f%3fsortBy%3dDownloads&da
> > >> >> > >
> > >> >>ta=01%7c01%7cnikhilkh%40microsoft.com
> > %7c5d1a100510734c0605f508d2c3b4b9
> > >> >> > >
> > >>
> >>c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7apFzmhrtn%2bKulHrNn46
> > >> >> > > kkRG%2bZp3KarDUTf2y0i7P5I%3d
> > >> >> > > [2]
> > >> >> > >
> > >> >>
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> > >> >> > >
> > >> >>b.com
> > %2fapache%2fcordova-plugin-camera%2fblob%2fmaster%2fsrc%2fios%2fC
> > >> >> > >
> > >> >>DVCamera.m%23L44&data=01%7c01%7cnikhilkh%40microsoft.com
> > %7c5d1a1005107
> > >> >> > >
> > >>
> >>34c0605f508d2c3b4b9c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CkH
> > >> >> > > zeZ9uQUfYPDdAGlO2PJ9xJz89sZI5bdMRSlQtrMo%3d
> > >> >> > >
> > >> >> > > Thanks,
> > >> >> > > Nikhil
> > >> >> > >
> > >> >> > >
> > >> >> > > -----Original Message-----
> > >> >> > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > >> >> > > Sent: Monday, September 21, 2015 6:32 PM
> > >> >> > > To: dev@cordova.apache.org
> > >> >> > > Subject: Re: [Android] 5.0.x release branch?
> > >> >> > >
> > >> >> > > On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal
> > >> >> > > <ni...@microsoft.com>
> > >> >> > > wrote:
> > >> >> > >
> > >> >> > > > Can you explain why latest plugins will not be compatible
> with
> > >> >>older
> > >> >> > > > versions of Cordova?
> > >> >> > >
> > >> >> > >
> > >> >> > > They won't be compatible because Cordova-Android compiles
> against
> > >> >>API
> > >> >> > > 22, and these plugins will require API 23 so that they can
> detect
> > >> >> > > permissions and support Marshmellow.
> > >> >> > >
> > >> >> > >
> > >> >> > > > Can this be avoided by any means?
> > >> >> > >
> > >> >> > >
> > >> >> > > Only with a lot of Java reflection, and I'd rather not subject
> > >> >>plugin
> > >> >> > > developers to that, or try to hide it under the hood in some
> > awful
> > >> >> > > utility class that everyone will want to see die.  I'm very
> much
> > a
> > >> >>fan
> > >> >> > > of if statements because they work, and they're easy to read
> and
> > >> >> > > debug, unlike when bad things happen to things you reflect
> into.
> > >> >> > > Plugins that require API 23 will only work with Cordova-Android
> > 5.0
> > >> >> > > and up.  This only impacts five of our core plugins, but any
> > plugin
> > >> >> > > that requires permissions from the Android Manifest will have
> to
> > be
> > >> >> > > updated.  If we can avoid using advanced language tricks to
> make
> > >> the
> > >> >> > APKs compatible, we should do that.
> > >> >> > >
> > >> >> > > When you mean they would not be compatible - will it result in
> a
> > >> >>build
> > >> >> > > or
> > >> >> > > > runtime failure?
> > >> >> > > >
> > >> >> > > >
> > >> >> > > This will be a build failure, since API 22 does not have these
> > >> >> > > permissions, nor does it have the code required for API 23.
> > >> >> > >
> > >> >> > >
> > >> >> > > > For marshmallow, what is the guidance that we need to issue
> to
> > >> the
> > >> >> > > > larger Cordova plugin ecosystem? Joe you are ahead of the
> curve
> > >> >>here
> > >> >> > > > compared to most other plugin developers - a blot post
> > explaining
> > >> >> > > > what are known gotchas would be great. I really hope we can
> use
> > >> >>our
> > >> >> > > > Cordova blog to communicate these changes actively to the
> > plugin
> > >> >> > ecosystem.
> > >> >> > > > This mailing list only gets 400+ subscribers.
> > >> >> > > >
> > >> >> > > >
> > >> >> > > There will be a blog post once 5.0 is released.  We're not
> > forcing
> > >> >> > > people to upgrade to 5.0, and we will be supporting the 4.x
> > branch
> > >> >>for
> > >> >> > > six months.  This does mean we're stuck supporting 3.x, 4.x and
> > 5.x
> > >> >> > > for a brief window, but I have no control over when Marshmallow
> > is
> > >> >> > > released, only whether we want to support it or not.  I think
> we
> > >> do,
> > >> >> but
> > >> >> > I could be wrong.
> > >> >> > >
> > >> >> > > At least this should be easier than the jump from 3.x to 4.x
> for
> > >> >>most
> > >> >> > > people, but the alternative is that your plugin just doesn't
> work
> > >> at
> > >> >> > > all on Marshmallow.  We need to at least give plugin developers
> > >> this
> > >> >> > > option, since it'll roll out on all the Nexus devices in the
> next
> > >> >>two
> > >> >> > > weeks, and we'll hear more about it.
> > >> >> > >
> > >> >> > >
> > >> >> > > > Can you re-base your cordova-android over the current master?
> > >> It's
> > >> >> > > > hard to see a diff in the current form:
> > >> >> > > >
> > >> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > >> >> > > > hu
> > >> >> > > >
> > >> >>b.com
> %2fapache%2fcordova-android%2fcompare%2fmaster...infil00p%3asmo
> > >> >> > > > re
> > >> >> > > >
> > >> >>s&data=01%7c01%7cnikhilkh%40microsoft.com
> %7cb451a04dccc64fabdb9608d2
> > >> >> > > > c2
> > >> >> > > >
> > >> >>edb23c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j0bxz39itXdtylHJ
> > >> >> > > > lv
> > >> >> > > > PYoJpZqXMhFjyTV35I9X5Yxzs%3d
> > >> >> > > >
> > >> >> > > >
> > >> >> > > I had to do a merge commit to get this to happen (boo), but it
> > >> >>should
> > >> >> > > be mostly cleaned up now.  It seems some style cleanup creeped
> > into
> > >> >> > > the most recent changes, but this should be a bit more
> readable.
> > >> >> > >
> > >> >> > >
> > >> >> > > > -Nikhil
> > >> >> > > >
> > >> >> > > > -----Original Message-----
> > >> >> > > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > >> >> > > > Sent: Monday, September 21, 2015 2:14 PM
> > >> >> > > > To: dev <de...@cordova.apache.org>
> > >> >> > > > Subject: [Android] 5.0.x release branch?
> > >> >> > > >
> > >> >> > > > Hey
> > >> >> > > >
> > >> >> > > > In the next two weeks, Marshmallow will most likely getting
> > >> >>released
> > >> >> > > > with the brand new Nexus 6P being released from Huawei.
> Given
> > >> >>that
> > >> >> > > > most of the Nexus devices will be getting this release, we
> > should
> > >> >> > > > probably release the 5.0.x branch of Android soon, and get
> the
> > >> new
> > >> >> > > plugins updated.
> > >> >> > > >
> > >> >> > > > It should be noted that the latest plugins will not be
> > compatible
> > >> >> > > > with older versions of Cordova, which is a big deal.  This is
> > due
> > >> >>to
> > >> >> > > > the use of various compatibility checks to make sure they
> > support
> > >> >> > > > Marshmallow and older versions of Android.
> > >> >> > > >
> > >> >> > > > So, if everyone can look over the smores branches of my
> GitHub
> > >> >> > > > before I create the 5.0.x branch and pull the changes into
> it,
> > >> >>that
> > >> >> > > > would be
> > >> >> > > awesome.
> > >> >> > > >
> > >> >> > > >
> > >> >> > > >
> > >> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > >> >> > > > hu
> > >> >> > > >
> > >> >>b.com
> %2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cni
> > >> >> > > > kh
> > >> >> > > >
> > >> >>ilkh%40microsoft.com
> %7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86
> > >> >> > > > f1
> > >> >> > > >
> > >> >>41af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%
> > >> >> > > > 2b
> > >> >> > > > ve4PVcCE%3d
> > >> >> > > >
> > >> >> > > >
> > >> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > >> >> > > > hu
> > >> >> > > >
> > >> >>b.com
> %2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=0
> > >> >> > > > 1%
> > >> >> > > >
> > >> >>7c01%7cnikhilkh%40microsoft.com
> %7c1785194b1f82494fc2d908d2c2c99f36%7
> > >> >> > > > c7
> > >> >> > > >
> > >> >>2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv
> > >> >> > > > 6p
> > >> >> > > > c5qbeY%2bdUxiP4bc%3d
> > >> >> > > >
> > >> >> > > >
> > >> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > >> >> > > > hu
> > >> >> > > >
> > >> >>b.com
> %2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c0
> > >> >> > > > 1%
> > >> >> > > >
> > >> >>7cnikhilkh%40microsoft.com
> %7c1785194b1f82494fc2d908d2c2c99f36%7c72f9
> > >> >> > > > 88
> > >> >> > > >
> > >> >>bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCG
> > >> >> > > > Rb
> > >> >> > > > 4zWC8maWpE%3d
> > >> >> > > >
> > >> >> > > >
> > >> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > >> >> > > > hu
> > >> >> > > >
> > >> >>b.com
> %2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7
> > >> >> > > > c0
> > >> >> > > >
> > >> >>1%7cnikhilkh%40microsoft.com
> %7c1785194b1f82494fc2d908d2c2c99f36%7c72
> > >> >> > > > f9
> > >> >> > > >
> > >> >>88bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2
> > >> >> > > > fe
> > >> >> > > > EmqLOdU%2fwua2TbLU%3d
> > >> >> > > >
> > >> >> > > > Work on audio is still outstanding, BUT for some reason Audio
> > >> >>broke
> > >> >> > > > recently on both Lollipop and Marshmallow.  I didn't test it
> > out
> > >> >>on
> > >> >> > > > KitKat or Jellybean yet, but I'm wondering whether we should
> > keep
> > >> >> > > > maintaining this or support the standard HTML5 audio and deal
> > >> with
> > >> >> > > > the asset issue somehow (which isn't straight forward).
> > >> >> > > >
> > >> >> > > > I hopefully want to get a 5.0.x branch happening this week if
> > we
> > >> >>can.
> > >> >> > > >
> > >> >> > > > What do people think?
> > >> >> > > >
> > >> >> > > > Joe
> > >> >> > > >
> > >> >> > >
> > >> >> >
> > >> >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >>
> > >
> >
>
>
>
> --
>
> *Frederico Galvão*
>
> Diretor de Tecnologia
>
> PontoGet Inovação Web
>
>
> ( +55(62) 8131-5720
>
> * www.pontoget.com.br <http://www.pontoget.com/>
>

Re: [Android] 5.0.x release branch?

Posted by Frederico Galvão <fr...@pontoget.com.br>.

Based on [1] I think we're overthinking here...

I might have missed something, but as far as I understood it all, the only
thing preventing new plugin versions from working on older cordova-android
based projects is the POSSIBLE FACT that these projects will still
have android:targetSdkVersion="N < 23". It's not a sure bet, it's a
possibility. My project, for example, will already
have android:targetSdkVersion="23" when I upgrade to cordova-android 5.x
with all the plugins upgraded too, so even if I only upgraded the plugins
it would still work.

It's common sense for android developers to bump the targetSdkVersion to
the latest once a new one comes out, the android APIs are always backwards
compatible, even if it means for the google team to code migration or
compatibility code (which they have always done afaik). If an app developer
is upgrading his plugins on an existing app, there is no obvious reason for
him not to also bump the targetSdkVersion. An app developer will always
want to support the largest and newest devices, it's a larger audience for
them anyway.

With that said, I don't think any of the mentioned complexity is needed
(package.json metadata, plugman version tryouts, engine tags in plugin.xml
or reflection). We just need to add hooks to the plugins that check the
targetSdkVersions on plugin_install, and warn the user about this if it's
bellow 23.

[1]
> They won't be compatible because Cordova-Android compiles against API 22,
and these plugins will require API 23 so that they can detect permissions
and support Marshmellow.

2015-09-23 15:33 GMT-03:00 Joe Bowser <bo...@gmail.com>:

> On Wed, Sep 23, 2015 at 11:30 AM, Joe Bowser <bo...@gmail.com> wrote:
>
> >
> > On Wed, Sep 23, 2015 at 11:22 AM, Homer, Tony <to...@intel.com>
> > wrote:
> >
> >> Joe-
> >>
> >> As far as I can tell, the API 23 calls are currently unguarded so smores
> >> will only work on M Preview.
> >> I know your smores branch is a POC, but I was wondering about backwards
> >> compatibility.
> >> Do you anticipate adding Build.VERSION.SDK_INT >= Build.VERSION_CODES.M
> >> guard clauses for backwards compatibility?
> >>
> >>
> > This already exists in each of the plugins when they do the permissions
> > check, and smores works perfectly fine on Lollipop so far.  Right now, if
> > you aren't running M, you don't do the permissions check, and you don't
> > call the methods.  I haven't tested it on earlier versions of Android,
> but
> > I expect it to work on Kitkat and Jellybean the same way.
> >
> >
> >
>
> And yes, we can probably create a utility method, that said, most plugins
> aren't directly affected by this, only the ones that require extra
> permissions.  It'd be good if we had an idea of what third party plugins
> people are actually using that would run afowl of this and see where they
> would fail.  But I already have more than enough work currently, and
> adopting other people's plugins is not something I want to get in the habit
> of doing.
>
>
>
> > Tony
> >>
> >> On 9/23/15, 1:56 PM, "Joe Bowser" <bo...@gmail.com> wrote:
> >>
> >> >On Wed, Sep 23, 2015 at 9:36 AM, Carlos Santana <cs...@gmail.com>
> >> >wrote:
> >> >
> >> >> No need to major version change for the Plugins, the API of the
> didn't
> >> >> change.
> >> >> Web developer still uses the same JS API to use the plugin.
> >> >>
> >> >>
> >> >I would do a major version bump on Geolocation.  The API itself didn't
> >> >change but the behaviour certainly did.  On Marshmallow we have to add
> >> >this
> >> >extra shim that asks for permission, which means that there's now code
> >> >attached to Android Geolocation that didn't exist before.  All the
> other
> >> >plugins should still be fine.
> >> >
> >> >
> >> >> Yes I did some thinking around the plugin search website. I think is
> a
> >> >>good
> >> >> topic for the F2F.
> >> >> Now that IBM is using Cordova Plugin more heavily to package our
> mobile
> >> >> SDKs using Cordova Plugins, I think is beneficial to expose more info
> >> >>about
> >> >> the plugin including engine tags
> >> >>
> >> >> I would not go and build our own backend and have our own registry
> with
> >> >> cordova metadata.
> >> >>
> >> >> I think the solution is to put the metadata of plugin.xml into
> >> >> package.json. We can show fast results in main search, but then user
> >> can
> >> >> drill into the plugin details, and we can have a view with more
> >> >>information
> >> >> and allow the user to select a specific version like we have today in
> >> >>our
> >> >> plugin website search using the cordova registry.
> >> >>
> >> >> The website can fetch the package.json and it will have the
> information
> >> >>to
> >> >> display to the user.
> >> >>
> >> >> So what I think we need to do is document and automate the
> information
> >> >>from
> >> >> plugin.xml including engine tags into the package.json.
> >> >>
> >> >> Today we have some sort of duplicate information between the
> "cordova"
> >> >>and
> >> >> "keywords", I think it would be a good time to clean it up and add an
> >> >>array
> >> >> in cordova.engines
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Sep 23, 2015 at 12:19 PM Nikhil Khandelwal
> >> >><nikhilkh@microsoft.com
> >> >> >
> >> >> wrote:
> >> >>
> >> >> > Merging threads. I was no aware of any security implications of
> using
> >> >> > reflection - Perhaps if the reflection target can be controlled
> >> >>through
> >> >> > external data. In any case, I understand your hesitation with use
> of
> >> >> > reflection. I would love to have longer discussions on the F2F on
> >> what
> >> >> > approaches we could use to make this easier for Cordova developers.
> >> >> >
> >> >> > Joe: Could you add the appropriate engine tags in any case? That's
> >> how
> >> >> > Cordova currently handles versioning between plugins & platforms.
> >> >>Also,
> >> >> > does this imply that the plugins should have a major version bump
> as
> >> >>it
> >> >> is
> >> >> > a breaking change? Please create the 5.x branches and if you could
> >> >> submit a
> >> >> > PR - I had other minor code review comments on the diffs below.
> >> >> >
> >> >> > Carlos: I understand in the extreme case it can be a fairly
> >> >>complicated
> >> >> > implementation with lots of criteria to use to determine the ideal
> >> >>plugin
> >> >> > that might work given a set of platforms. However, trying a couple
> of
> >> >> > previous versions of the plugins might work 80% of the time and
> that
> >> >> might
> >> >> > be good enough. This requires more thought as there are quite a few
> >> >> > scenarios here.
> >> >> >
> >> >> > As for plugin search website helping you find the correct engine
> tags
> >> >>- I
> >> >> > like the idea. But this might requires us maintaining a backend for
> >> >> plugin
> >> >> > search as this is specified in plugin.xml (and not package.json -
> or
> >> >>did
> >> >> we
> >> >> > finally move this?).
> >> >> >
> >> >> > Thanks,
> >> >> > Nikhil
> >> >> >
> >> >> > -----Original Message-----
> >> >> > From: Carlos Santana [mailto:csantana23@gmail.com]
> >> >> > Sent: Tuesday, September 22, 2015 6:14 PM
> >> >> > To: dev@cordova.apache.org
> >> >> > Subject: Re: [Android] 5.0.x release branch?
> >> >> >
> >> >> > +1 we should always use the engine tag to mark the minimum
> compatible
> >> >> > +version at least
> >> >> >
> >> >> > -1 for cordova CLI to automagically to install an older version. It
> >> >>will
> >> >> > be a pain to get this implemented right, we would need to download
> >> all
> >> >> the
> >> >> > package.json for multiple versions of the plugin and pick the
> lowest
> >> >> common
> >> >> > denominator based on engine tags and remember that one plugin
> support
> >> >> > multiple engine tags across different platform versions and
> >> >>CLI/plugman.
> >> >> >
> >> >> > This brings an interesting feature to implement In the plugin
> search
> >> >> > website, to display the engine tags for a specific plugin version.
> >> >> Allowing
> >> >> > a developer to search for a compatible plugin for their current
> app.
> >> >> >
> >> >> > - Carlos
> >> >> > Sent from my iPhone
> >> >> >
> >> >> >
> >> >> > -----Original Message-----
> >> >> > From: Joe Bowser [mailto:bowserj@gmail.com]
> >> >> > Sent: Tuesday, September 22, 2015 6:17 PM
> >> >> > To: dev@cordova.apache.org
> >> >> > Subject: Re: [Android] 5.0.x release branch?
> >> >> >
> >> >> > I'm completely against using reflection for this purpose.  Version
> >> >>codes
> >> >> > were invented for a reason and we don't have any mechanism in place
> >> to
> >> >> unit
> >> >> > test any Android code (or any other native code on any of the
> >> >>platforms).
> >> >> >
> >> >> > I will vote against any release that includes reflection for this
> >> >>purpose
> >> >> > since reflection has only brought us security issues and extreme
> >> >>WebView
> >> >> > breakage when used (Simon can tell you the tales of the HTC
> >> >>console.log
> >> >> > reflection code.).  Reflection is a worst-case scenario tool like
> >> >>when a
> >> >> > method in WebView marked as deprecated completely disappears, not
> >> >> something
> >> >> > we should make a habit of using often.  If we open the door for
> this,
> >> >> we'll
> >> >> > get reflection creeping elsewhere, like the Plugins API.
> >> >> >
> >> >> > Just say no to reflection.
> >> >> >
> >> >> >
> >> >> > On Tue, Sep 22, 2015, 5:57 PM Nikhil Khandelwal
> >> >><ni...@microsoft.com>
> >> >> > wrote:
> >> >> >
> >> >> > > Thanks, Joe for the detailed explanation. I understand why we've
> >> >>taken
> >> >> > > this route. It's good that this is only a build failure. One of
> the
> >> >> > > complaints we commonly hear from Cordova developers is that "I
> have
> >> >>a
> >> >> > > cordova project with a certain version of the platform, I need to
> >> >>find
> >> >> > > the plugin that will work with it". Our CLI always defaults to
> add
> >> >>the
> >> >> > > latest released version of the plugin.
> >> >> > >
> >> >> > > After this breaking change, an existing cordova project with
> >> >> > > cordova-android < 5.x, cannot build with the latest version of
> the
> >> >> > > following plugins:
> >> >> > >                 - camera
> >> >> > >                - geolocation
> >> >> > >                - contacts.
> >> >> > > These are some of the most popular plugins in cordova plugin
> >> >>ecosystem
> >> >> > [1].
> >> >> > >
> >> >> > > I propose that we should do our best to avoid disruptive breaking
> >> >> > > changes here. Some ideas that come to mind:
> >> >> > > - As Joe mentioned below - reflection. It has the downsides that
> >> Joe
> >> >> > > mentioned. No one likes to write code like this it but results in
> >> >> > > least grief for Cordova users. Some pain here for plugin
> developers
> >> >> > > will simplify the experience for large number of corodva JS
> >> >> > > developers. I know we are doing some of this in cordova-ios [2]
> and
> >> >> > > would love to find ways on how to make this manageable and not
> >> super
> >> >> > ugly.
> >> >> > > - Add an  '<engine name="cordova-android" version=">=5.0.0" /> '
> >> to
> >> >> > > the plugins - failure happens at plugin add in this scenario.
> >> >> > > Cordova-lib could be more intelligent to detect this error and
> >> >>resort
> >> >> > > to using an older version of the plugin. The downside of this is
> >> >>that
> >> >> > > these projects cannot use the latest and greatest of these
> plugins.
> >> >> > >
> >> >> > > Thanks,
> >> >> > > Nikhil
> >> >> > >
> >> >> > > [1]
> >> >> > >
> >> >>
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordov
> >> >> > >
> >> >>a.apache.org
> %2fuse-the-force-luke%2fplugins%2f%3fsortBy%3dDownloads&da
> >> >> > >
> >> >>ta=01%7c01%7cnikhilkh%40microsoft.com
> %7c5d1a100510734c0605f508d2c3b4b9
> >> >> > >
> >> >>c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7apFzmhrtn%2bKulHrNn46
> >> >> > > kkRG%2bZp3KarDUTf2y0i7P5I%3d
> >> >> > > [2]
> >> >> > >
> >> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> >> >> > >
> >> >>b.com
> %2fapache%2fcordova-plugin-camera%2fblob%2fmaster%2fsrc%2fios%2fC
> >> >> > >
> >> >>DVCamera.m%23L44&data=01%7c01%7cnikhilkh%40microsoft.com
> %7c5d1a1005107
> >> >> > >
> >> >>34c0605f508d2c3b4b9c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CkH
> >> >> > > zeZ9uQUfYPDdAGlO2PJ9xJz89sZI5bdMRSlQtrMo%3d
> >> >> > >
> >> >> > > Thanks,
> >> >> > > Nikhil
> >> >> > >
> >> >> > >
> >> >> > > -----Original Message-----
> >> >> > > From: Joe Bowser [mailto:bowserj@gmail.com]
> >> >> > > Sent: Monday, September 21, 2015 6:32 PM
> >> >> > > To: dev@cordova.apache.org
> >> >> > > Subject: Re: [Android] 5.0.x release branch?
> >> >> > >
> >> >> > > On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal
> >> >> > > <ni...@microsoft.com>
> >> >> > > wrote:
> >> >> > >
> >> >> > > > Can you explain why latest plugins will not be compatible with
> >> >>older
> >> >> > > > versions of Cordova?
> >> >> > >
> >> >> > >
> >> >> > > They won't be compatible because Cordova-Android compiles against
> >> >>API
> >> >> > > 22, and these plugins will require API 23 so that they can detect
> >> >> > > permissions and support Marshmellow.
> >> >> > >
> >> >> > >
> >> >> > > > Can this be avoided by any means?
> >> >> > >
> >> >> > >
> >> >> > > Only with a lot of Java reflection, and I'd rather not subject
> >> >>plugin
> >> >> > > developers to that, or try to hide it under the hood in some
> awful
> >> >> > > utility class that everyone will want to see die.  I'm very much
> a
> >> >>fan
> >> >> > > of if statements because they work, and they're easy to read and
> >> >> > > debug, unlike when bad things happen to things you reflect into.
> >> >> > > Plugins that require API 23 will only work with Cordova-Android
> 5.0
> >> >> > > and up.  This only impacts five of our core plugins, but any
> plugin
> >> >> > > that requires permissions from the Android Manifest will have to
> be
> >> >> > > updated.  If we can avoid using advanced language tricks to make
> >> the
> >> >> > APKs compatible, we should do that.
> >> >> > >
> >> >> > > When you mean they would not be compatible - will it result in a
> >> >>build
> >> >> > > or
> >> >> > > > runtime failure?
> >> >> > > >
> >> >> > > >
> >> >> > > This will be a build failure, since API 22 does not have these
> >> >> > > permissions, nor does it have the code required for API 23.
> >> >> > >
> >> >> > >
> >> >> > > > For marshmallow, what is the guidance that we need to issue to
> >> the
> >> >> > > > larger Cordova plugin ecosystem? Joe you are ahead of the curve
> >> >>here
> >> >> > > > compared to most other plugin developers - a blot post
> explaining
> >> >> > > > what are known gotchas would be great. I really hope we can use
> >> >>our
> >> >> > > > Cordova blog to communicate these changes actively to the
> plugin
> >> >> > ecosystem.
> >> >> > > > This mailing list only gets 400+ subscribers.
> >> >> > > >
> >> >> > > >
> >> >> > > There will be a blog post once 5.0 is released.  We're not
> forcing
> >> >> > > people to upgrade to 5.0, and we will be supporting the 4.x
> branch
> >> >>for
> >> >> > > six months.  This does mean we're stuck supporting 3.x, 4.x and
> 5.x
> >> >> > > for a brief window, but I have no control over when Marshmallow
> is
> >> >> > > released, only whether we want to support it or not.  I think we
> >> do,
> >> >> but
> >> >> > I could be wrong.
> >> >> > >
> >> >> > > At least this should be easier than the jump from 3.x to 4.x for
> >> >>most
> >> >> > > people, but the alternative is that your plugin just doesn't work
> >> at
> >> >> > > all on Marshmallow.  We need to at least give plugin developers
> >> this
> >> >> > > option, since it'll roll out on all the Nexus devices in the next
> >> >>two
> >> >> > > weeks, and we'll hear more about it.
> >> >> > >
> >> >> > >
> >> >> > > > Can you re-base your cordova-android over the current master?
> >> It's
> >> >> > > > hard to see a diff in the current form:
> >> >> > > >
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> >> >> > > > hu
> >> >> > > >
> >> >>b.com%2fapache%2fcordova-android%2fcompare%2fmaster...infil00p%3asmo
> >> >> > > > re
> >> >> > > >
> >> >>s&data=01%7c01%7cnikhilkh%40microsoft.com%7cb451a04dccc64fabdb9608d2
> >> >> > > > c2
> >> >> > > >
> >> >>edb23c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j0bxz39itXdtylHJ
> >> >> > > > lv
> >> >> > > > PYoJpZqXMhFjyTV35I9X5Yxzs%3d
> >> >> > > >
> >> >> > > >
> >> >> > > I had to do a merge commit to get this to happen (boo), but it
> >> >>should
> >> >> > > be mostly cleaned up now.  It seems some style cleanup creeped
> into
> >> >> > > the most recent changes, but this should be a bit more readable.
> >> >> > >
> >> >> > >
> >> >> > > > -Nikhil
> >> >> > > >
> >> >> > > > -----Original Message-----
> >> >> > > > From: Joe Bowser [mailto:bowserj@gmail.com]
> >> >> > > > Sent: Monday, September 21, 2015 2:14 PM
> >> >> > > > To: dev <de...@cordova.apache.org>
> >> >> > > > Subject: [Android] 5.0.x release branch?
> >> >> > > >
> >> >> > > > Hey
> >> >> > > >
> >> >> > > > In the next two weeks, Marshmallow will most likely getting
> >> >>released
> >> >> > > > with the brand new Nexus 6P being released from Huawei.  Given
> >> >>that
> >> >> > > > most of the Nexus devices will be getting this release, we
> should
> >> >> > > > probably release the 5.0.x branch of Android soon, and get the
> >> new
> >> >> > > plugins updated.
> >> >> > > >
> >> >> > > > It should be noted that the latest plugins will not be
> compatible
> >> >> > > > with older versions of Cordova, which is a big deal.  This is
> due
> >> >>to
> >> >> > > > the use of various compatibility checks to make sure they
> support
> >> >> > > > Marshmallow and older versions of Android.
> >> >> > > >
> >> >> > > > So, if everyone can look over the smores branches of my GitHub
> >> >> > > > before I create the 5.0.x branch and pull the changes into it,
> >> >>that
> >> >> > > > would be
> >> >> > > awesome.
> >> >> > > >
> >> >> > > >
> >> >> > > >
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> >> >> > > > hu
> >> >> > > >
> >> >>b.com%2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cni
> >> >> > > > kh
> >> >> > > >
> >> >>ilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86
> >> >> > > > f1
> >> >> > > >
> >> >>41af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%
> >> >> > > > 2b
> >> >> > > > ve4PVcCE%3d
> >> >> > > >
> >> >> > > >
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> >> >> > > > hu
> >> >> > > >
> >> >>b.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=0
> >> >> > > > 1%
> >> >> > > >
> >> >>7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7
> >> >> > > > c7
> >> >> > > >
> >> >>2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv
> >> >> > > > 6p
> >> >> > > > c5qbeY%2bdUxiP4bc%3d
> >> >> > > >
> >> >> > > >
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> >> >> > > > hu
> >> >> > > >
> >> >>b.com%2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c0
> >> >> > > > 1%
> >> >> > > >
> >> >>7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f9
> >> >> > > > 88
> >> >> > > >
> >> >>bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCG
> >> >> > > > Rb
> >> >> > > > 4zWC8maWpE%3d
> >> >> > > >
> >> >> > > >
> >> >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> >> >> > > > hu
> >> >> > > >
> >> >>b.com%2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7
> >> >> > > > c0
> >> >> > > >
> >> >>1%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72
> >> >> > > > f9
> >> >> > > >
> >> >>88bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2
> >> >> > > > fe
> >> >> > > > EmqLOdU%2fwua2TbLU%3d
> >> >> > > >
> >> >> > > > Work on audio is still outstanding, BUT for some reason Audio
> >> >>broke
> >> >> > > > recently on both Lollipop and Marshmallow.  I didn't test it
> out
> >> >>on
> >> >> > > > KitKat or Jellybean yet, but I'm wondering whether we should
> keep
> >> >> > > > maintaining this or support the standard HTML5 audio and deal
> >> with
> >> >> > > > the asset issue somehow (which isn't straight forward).
> >> >> > > >
> >> >> > > > I hopefully want to get a 5.0.x branch happening this week if
> we
> >> >>can.
> >> >> > > >
> >> >> > > > What do people think?
> >> >> > > >
> >> >> > > > Joe
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >>
> >
>



-- 

*Frederico Galvão*

Diretor de Tecnologia

PontoGet Inovação Web


( +55(62) 8131-5720

* www.pontoget.com.br <http://www.pontoget.com/>

Re: [Android] 5.0.x release branch?

Posted by Joe Bowser <bo...@gmail.com>.

On Wed, Sep 23, 2015 at 11:30 AM, Joe Bowser <bo...@gmail.com> wrote:

>
> On Wed, Sep 23, 2015 at 11:22 AM, Homer, Tony <to...@intel.com>
> wrote:
>
>> Joe-
>>
>> As far as I can tell, the API 23 calls are currently unguarded so smores
>> will only work on M Preview.
>> I know your smores branch is a POC, but I was wondering about backwards
>> compatibility.
>> Do you anticipate adding Build.VERSION.SDK_INT >= Build.VERSION_CODES.M
>> guard clauses for backwards compatibility?
>>
>>
> This already exists in each of the plugins when they do the permissions
> check, and smores works perfectly fine on Lollipop so far.  Right now, if
> you aren't running M, you don't do the permissions check, and you don't
> call the methods.  I haven't tested it on earlier versions of Android, but
> I expect it to work on Kitkat and Jellybean the same way.
>
>
>

And yes, we can probably create a utility method, that said, most plugins
aren't directly affected by this, only the ones that require extra
permissions.  It'd be good if we had an idea of what third party plugins
people are actually using that would run afowl of this and see where they
would fail.  But I already have more than enough work currently, and
adopting other people's plugins is not something I want to get in the habit
of doing.



> Tony
>>
>> On 9/23/15, 1:56 PM, "Joe Bowser" <bo...@gmail.com> wrote:
>>
>> >On Wed, Sep 23, 2015 at 9:36 AM, Carlos Santana <cs...@gmail.com>
>> >wrote:
>> >
>> >> No need to major version change for the Plugins, the API of the didn't
>> >> change.
>> >> Web developer still uses the same JS API to use the plugin.
>> >>
>> >>
>> >I would do a major version bump on Geolocation.  The API itself didn't
>> >change but the behaviour certainly did.  On Marshmallow we have to add
>> >this
>> >extra shim that asks for permission, which means that there's now code
>> >attached to Android Geolocation that didn't exist before.  All the other
>> >plugins should still be fine.
>> >
>> >
>> >> Yes I did some thinking around the plugin search website. I think is a
>> >>good
>> >> topic for the F2F.
>> >> Now that IBM is using Cordova Plugin more heavily to package our mobile
>> >> SDKs using Cordova Plugins, I think is beneficial to expose more info
>> >>about
>> >> the plugin including engine tags
>> >>
>> >> I would not go and build our own backend and have our own registry with
>> >> cordova metadata.
>> >>
>> >> I think the solution is to put the metadata of plugin.xml into
>> >> package.json. We can show fast results in main search, but then user
>> can
>> >> drill into the plugin details, and we can have a view with more
>> >>information
>> >> and allow the user to select a specific version like we have today in
>> >>our
>> >> plugin website search using the cordova registry.
>> >>
>> >> The website can fetch the package.json and it will have the information
>> >>to
>> >> display to the user.
>> >>
>> >> So what I think we need to do is document and automate the information
>> >>from
>> >> plugin.xml including engine tags into the package.json.
>> >>
>> >> Today we have some sort of duplicate information between the "cordova"
>> >>and
>> >> "keywords", I think it would be a good time to clean it up and add an
>> >>array
>> >> in cordova.engines
>> >>
>> >>
>> >>
>> >> On Wed, Sep 23, 2015 at 12:19 PM Nikhil Khandelwal
>> >><nikhilkh@microsoft.com
>> >> >
>> >> wrote:
>> >>
>> >> > Merging threads. I was no aware of any security implications of using
>> >> > reflection - Perhaps if the reflection target can be controlled
>> >>through
>> >> > external data. In any case, I understand your hesitation with use of
>> >> > reflection. I would love to have longer discussions on the F2F on
>> what
>> >> > approaches we could use to make this easier for Cordova developers.
>> >> >
>> >> > Joe: Could you add the appropriate engine tags in any case? That's
>> how
>> >> > Cordova currently handles versioning between plugins & platforms.
>> >>Also,
>> >> > does this imply that the plugins should have a major version bump as
>> >>it
>> >> is
>> >> > a breaking change? Please create the 5.x branches and if you could
>> >> submit a
>> >> > PR - I had other minor code review comments on the diffs below.
>> >> >
>> >> > Carlos: I understand in the extreme case it can be a fairly
>> >>complicated
>> >> > implementation with lots of criteria to use to determine the ideal
>> >>plugin
>> >> > that might work given a set of platforms. However, trying a couple of
>> >> > previous versions of the plugins might work 80% of the time and that
>> >> might
>> >> > be good enough. This requires more thought as there are quite a few
>> >> > scenarios here.
>> >> >
>> >> > As for plugin search website helping you find the correct engine tags
>> >>- I
>> >> > like the idea. But this might requires us maintaining a backend for
>> >> plugin
>> >> > search as this is specified in plugin.xml (and not package.json - or
>> >>did
>> >> we
>> >> > finally move this?).
>> >> >
>> >> > Thanks,
>> >> > Nikhil
>> >> >
>> >> > -----Original Message-----
>> >> > From: Carlos Santana [mailto:csantana23@gmail.com]
>> >> > Sent: Tuesday, September 22, 2015 6:14 PM
>> >> > To: dev@cordova.apache.org
>> >> > Subject: Re: [Android] 5.0.x release branch?
>> >> >
>> >> > +1 we should always use the engine tag to mark the minimum compatible
>> >> > +version at least
>> >> >
>> >> > -1 for cordova CLI to automagically to install an older version. It
>> >>will
>> >> > be a pain to get this implemented right, we would need to download
>> all
>> >> the
>> >> > package.json for multiple versions of the plugin and pick the lowest
>> >> common
>> >> > denominator based on engine tags and remember that one plugin support
>> >> > multiple engine tags across different platform versions and
>> >>CLI/plugman.
>> >> >
>> >> > This brings an interesting feature to implement In the plugin search
>> >> > website, to display the engine tags for a specific plugin version.
>> >> Allowing
>> >> > a developer to search for a compatible plugin for their current app.
>> >> >
>> >> > - Carlos
>> >> > Sent from my iPhone
>> >> >
>> >> >
>> >> > -----Original Message-----
>> >> > From: Joe Bowser [mailto:bowserj@gmail.com]
>> >> > Sent: Tuesday, September 22, 2015 6:17 PM
>> >> > To: dev@cordova.apache.org
>> >> > Subject: Re: [Android] 5.0.x release branch?
>> >> >
>> >> > I'm completely against using reflection for this purpose.  Version
>> >>codes
>> >> > were invented for a reason and we don't have any mechanism in place
>> to
>> >> unit
>> >> > test any Android code (or any other native code on any of the
>> >>platforms).
>> >> >
>> >> > I will vote against any release that includes reflection for this
>> >>purpose
>> >> > since reflection has only brought us security issues and extreme
>> >>WebView
>> >> > breakage when used (Simon can tell you the tales of the HTC
>> >>console.log
>> >> > reflection code.).  Reflection is a worst-case scenario tool like
>> >>when a
>> >> > method in WebView marked as deprecated completely disappears, not
>> >> something
>> >> > we should make a habit of using often.  If we open the door for this,
>> >> we'll
>> >> > get reflection creeping elsewhere, like the Plugins API.
>> >> >
>> >> > Just say no to reflection.
>> >> >
>> >> >
>> >> > On Tue, Sep 22, 2015, 5:57 PM Nikhil Khandelwal
>> >><ni...@microsoft.com>
>> >> > wrote:
>> >> >
>> >> > > Thanks, Joe for the detailed explanation. I understand why we've
>> >>taken
>> >> > > this route. It's good that this is only a build failure. One of the
>> >> > > complaints we commonly hear from Cordova developers is that "I have
>> >>a
>> >> > > cordova project with a certain version of the platform, I need to
>> >>find
>> >> > > the plugin that will work with it". Our CLI always defaults to add
>> >>the
>> >> > > latest released version of the plugin.
>> >> > >
>> >> > > After this breaking change, an existing cordova project with
>> >> > > cordova-android < 5.x, cannot build with the latest version of the
>> >> > > following plugins:
>> >> > >                 - camera
>> >> > >                - geolocation
>> >> > >                - contacts.
>> >> > > These are some of the most popular plugins in cordova plugin
>> >>ecosystem
>> >> > [1].
>> >> > >
>> >> > > I propose that we should do our best to avoid disruptive breaking
>> >> > > changes here. Some ideas that come to mind:
>> >> > > - As Joe mentioned below - reflection. It has the downsides that
>> Joe
>> >> > > mentioned. No one likes to write code like this it but results in
>> >> > > least grief for Cordova users. Some pain here for plugin developers
>> >> > > will simplify the experience for large number of corodva JS
>> >> > > developers. I know we are doing some of this in cordova-ios [2] and
>> >> > > would love to find ways on how to make this manageable and not
>> super
>> >> > ugly.
>> >> > > - Add an  '<engine name="cordova-android" version=">=5.0.0" /> '
>> to
>> >> > > the plugins - failure happens at plugin add in this scenario.
>> >> > > Cordova-lib could be more intelligent to detect this error and
>> >>resort
>> >> > > to using an older version of the plugin. The downside of this is
>> >>that
>> >> > > these projects cannot use the latest and greatest of these plugins.
>> >> > >
>> >> > > Thanks,
>> >> > > Nikhil
>> >> > >
>> >> > > [1]
>> >> > >
>> >>https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordov
>> >> > >
>> >>a.apache.org%2fuse-the-force-luke%2fplugins%2f%3fsortBy%3dDownloads&da
>> >> > >
>> >>ta=01%7c01%7cnikhilkh%40microsoft.com%7c5d1a100510734c0605f508d2c3b4b9
>> >> > >
>> >>c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7apFzmhrtn%2bKulHrNn46
>> >> > > kkRG%2bZp3KarDUTf2y0i7P5I%3d
>> >> > > [2]
>> >> > >
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
>> >> > >
>> >>b.com%2fapache%2fcordova-plugin-camera%2fblob%2fmaster%2fsrc%2fios%2fC
>> >> > >
>> >>DVCamera.m%23L44&data=01%7c01%7cnikhilkh%40microsoft.com%7c5d1a1005107
>> >> > >
>> >>34c0605f508d2c3b4b9c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CkH
>> >> > > zeZ9uQUfYPDdAGlO2PJ9xJz89sZI5bdMRSlQtrMo%3d
>> >> > >
>> >> > > Thanks,
>> >> > > Nikhil
>> >> > >
>> >> > >
>> >> > > -----Original Message-----
>> >> > > From: Joe Bowser [mailto:bowserj@gmail.com]
>> >> > > Sent: Monday, September 21, 2015 6:32 PM
>> >> > > To: dev@cordova.apache.org
>> >> > > Subject: Re: [Android] 5.0.x release branch?
>> >> > >
>> >> > > On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal
>> >> > > <ni...@microsoft.com>
>> >> > > wrote:
>> >> > >
>> >> > > > Can you explain why latest plugins will not be compatible with
>> >>older
>> >> > > > versions of Cordova?
>> >> > >
>> >> > >
>> >> > > They won't be compatible because Cordova-Android compiles against
>> >>API
>> >> > > 22, and these plugins will require API 23 so that they can detect
>> >> > > permissions and support Marshmellow.
>> >> > >
>> >> > >
>> >> > > > Can this be avoided by any means?
>> >> > >
>> >> > >
>> >> > > Only with a lot of Java reflection, and I'd rather not subject
>> >>plugin
>> >> > > developers to that, or try to hide it under the hood in some awful
>> >> > > utility class that everyone will want to see die.  I'm very much a
>> >>fan
>> >> > > of if statements because they work, and they're easy to read and
>> >> > > debug, unlike when bad things happen to things you reflect into.
>> >> > > Plugins that require API 23 will only work with Cordova-Android 5.0
>> >> > > and up.  This only impacts five of our core plugins, but any plugin
>> >> > > that requires permissions from the Android Manifest will have to be
>> >> > > updated.  If we can avoid using advanced language tricks to make
>> the
>> >> > APKs compatible, we should do that.
>> >> > >
>> >> > > When you mean they would not be compatible - will it result in a
>> >>build
>> >> > > or
>> >> > > > runtime failure?
>> >> > > >
>> >> > > >
>> >> > > This will be a build failure, since API 22 does not have these
>> >> > > permissions, nor does it have the code required for API 23.
>> >> > >
>> >> > >
>> >> > > > For marshmallow, what is the guidance that we need to issue to
>> the
>> >> > > > larger Cordova plugin ecosystem? Joe you are ahead of the curve
>> >>here
>> >> > > > compared to most other plugin developers - a blot post explaining
>> >> > > > what are known gotchas would be great. I really hope we can use
>> >>our
>> >> > > > Cordova blog to communicate these changes actively to the plugin
>> >> > ecosystem.
>> >> > > > This mailing list only gets 400+ subscribers.
>> >> > > >
>> >> > > >
>> >> > > There will be a blog post once 5.0 is released.  We're not forcing
>> >> > > people to upgrade to 5.0, and we will be supporting the 4.x branch
>> >>for
>> >> > > six months.  This does mean we're stuck supporting 3.x, 4.x and 5.x
>> >> > > for a brief window, but I have no control over when Marshmallow is
>> >> > > released, only whether we want to support it or not.  I think we
>> do,
>> >> but
>> >> > I could be wrong.
>> >> > >
>> >> > > At least this should be easier than the jump from 3.x to 4.x for
>> >>most
>> >> > > people, but the alternative is that your plugin just doesn't work
>> at
>> >> > > all on Marshmallow.  We need to at least give plugin developers
>> this
>> >> > > option, since it'll roll out on all the Nexus devices in the next
>> >>two
>> >> > > weeks, and we'll hear more about it.
>> >> > >
>> >> > >
>> >> > > > Can you re-base your cordova-android over the current master?
>> It's
>> >> > > > hard to see a diff in the current form:
>> >> > > >
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
>> >> > > > hu
>> >> > > >
>> >>b.com%2fapache%2fcordova-android%2fcompare%2fmaster...infil00p%3asmo
>> >> > > > re
>> >> > > >
>> >>s&data=01%7c01%7cnikhilkh%40microsoft.com%7cb451a04dccc64fabdb9608d2
>> >> > > > c2
>> >> > > >
>> >>edb23c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j0bxz39itXdtylHJ
>> >> > > > lv
>> >> > > > PYoJpZqXMhFjyTV35I9X5Yxzs%3d
>> >> > > >
>> >> > > >
>> >> > > I had to do a merge commit to get this to happen (boo), but it
>> >>should
>> >> > > be mostly cleaned up now.  It seems some style cleanup creeped into
>> >> > > the most recent changes, but this should be a bit more readable.
>> >> > >
>> >> > >
>> >> > > > -Nikhil
>> >> > > >
>> >> > > > -----Original Message-----
>> >> > > > From: Joe Bowser [mailto:bowserj@gmail.com]
>> >> > > > Sent: Monday, September 21, 2015 2:14 PM
>> >> > > > To: dev <de...@cordova.apache.org>
>> >> > > > Subject: [Android] 5.0.x release branch?
>> >> > > >
>> >> > > > Hey
>> >> > > >
>> >> > > > In the next two weeks, Marshmallow will most likely getting
>> >>released
>> >> > > > with the brand new Nexus 6P being released from Huawei.  Given
>> >>that
>> >> > > > most of the Nexus devices will be getting this release, we should
>> >> > > > probably release the 5.0.x branch of Android soon, and get the
>> new
>> >> > > plugins updated.
>> >> > > >
>> >> > > > It should be noted that the latest plugins will not be compatible
>> >> > > > with older versions of Cordova, which is a big deal.  This is due
>> >>to
>> >> > > > the use of various compatibility checks to make sure they support
>> >> > > > Marshmallow and older versions of Android.
>> >> > > >
>> >> > > > So, if everyone can look over the smores branches of my GitHub
>> >> > > > before I create the 5.0.x branch and pull the changes into it,
>> >>that
>> >> > > > would be
>> >> > > awesome.
>> >> > > >
>> >> > > >
>> >> > > >
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
>> >> > > > hu
>> >> > > >
>> >>b.com%2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cni
>> >> > > > kh
>> >> > > >
>> >>ilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86
>> >> > > > f1
>> >> > > >
>> >>41af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%
>> >> > > > 2b
>> >> > > > ve4PVcCE%3d
>> >> > > >
>> >> > > >
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
>> >> > > > hu
>> >> > > >
>> >>b.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=0
>> >> > > > 1%
>> >> > > >
>> >>7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7
>> >> > > > c7
>> >> > > >
>> >>2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv
>> >> > > > 6p
>> >> > > > c5qbeY%2bdUxiP4bc%3d
>> >> > > >
>> >> > > >
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
>> >> > > > hu
>> >> > > >
>> >>b.com%2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c0
>> >> > > > 1%
>> >> > > >
>> >>7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f9
>> >> > > > 88
>> >> > > >
>> >>bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCG
>> >> > > > Rb
>> >> > > > 4zWC8maWpE%3d
>> >> > > >
>> >> > > >
>> >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
>> >> > > > hu
>> >> > > >
>> >>b.com%2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7
>> >> > > > c0
>> >> > > >
>> >>1%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72
>> >> > > > f9
>> >> > > >
>> >>88bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2
>> >> > > > fe
>> >> > > > EmqLOdU%2fwua2TbLU%3d
>> >> > > >
>> >> > > > Work on audio is still outstanding, BUT for some reason Audio
>> >>broke
>> >> > > > recently on both Lollipop and Marshmallow.  I didn't test it out
>> >>on
>> >> > > > KitKat or Jellybean yet, but I'm wondering whether we should keep
>> >> > > > maintaining this or support the standard HTML5 audio and deal
>> with
>> >> > > > the asset issue somehow (which isn't straight forward).
>> >> > > >
>> >> > > > I hopefully want to get a 5.0.x branch happening this week if we
>> >>can.
>> >> > > >
>> >> > > > What do people think?
>> >> > > >
>> >> > > > Joe
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>
>

Re: [Android] 5.0.x release branch?

Posted by Joe Bowser <bo...@gmail.com>.

On Wed, Sep 23, 2015 at 11:22 AM, Homer, Tony <to...@intel.com> wrote:

> Joe-
>
> As far as I can tell, the API 23 calls are currently unguarded so smores
> will only work on M Preview.
> I know your smores branch is a POC, but I was wondering about backwards
> compatibility.
> Do you anticipate adding Build.VERSION.SDK_INT >= Build.VERSION_CODES.M
> guard clauses for backwards compatibility?
>
>
This already exists in each of the plugins when they do the permissions
check, and smores works perfectly fine on Lollipop so far.  Right now, if
you aren't running M, you don't do the permissions check, and you don't
call the methods.  I haven't tested it on earlier versions of Android, but
I expect it to work on Kitkat and Jellybean the same way.



> Tony
>
> On 9/23/15, 1:56 PM, "Joe Bowser" <bo...@gmail.com> wrote:
>
> >On Wed, Sep 23, 2015 at 9:36 AM, Carlos Santana <cs...@gmail.com>
> >wrote:
> >
> >> No need to major version change for the Plugins, the API of the didn't
> >> change.
> >> Web developer still uses the same JS API to use the plugin.
> >>
> >>
> >I would do a major version bump on Geolocation.  The API itself didn't
> >change but the behaviour certainly did.  On Marshmallow we have to add
> >this
> >extra shim that asks for permission, which means that there's now code
> >attached to Android Geolocation that didn't exist before.  All the other
> >plugins should still be fine.
> >
> >
> >> Yes I did some thinking around the plugin search website. I think is a
> >>good
> >> topic for the F2F.
> >> Now that IBM is using Cordova Plugin more heavily to package our mobile
> >> SDKs using Cordova Plugins, I think is beneficial to expose more info
> >>about
> >> the plugin including engine tags
> >>
> >> I would not go and build our own backend and have our own registry with
> >> cordova metadata.
> >>
> >> I think the solution is to put the metadata of plugin.xml into
> >> package.json. We can show fast results in main search, but then user can
> >> drill into the plugin details, and we can have a view with more
> >>information
> >> and allow the user to select a specific version like we have today in
> >>our
> >> plugin website search using the cordova registry.
> >>
> >> The website can fetch the package.json and it will have the information
> >>to
> >> display to the user.
> >>
> >> So what I think we need to do is document and automate the information
> >>from
> >> plugin.xml including engine tags into the package.json.
> >>
> >> Today we have some sort of duplicate information between the "cordova"
> >>and
> >> "keywords", I think it would be a good time to clean it up and add an
> >>array
> >> in cordova.engines
> >>
> >>
> >>
> >> On Wed, Sep 23, 2015 at 12:19 PM Nikhil Khandelwal
> >><nikhilkh@microsoft.com
> >> >
> >> wrote:
> >>
> >> > Merging threads. I was no aware of any security implications of using
> >> > reflection - Perhaps if the reflection target can be controlled
> >>through
> >> > external data. In any case, I understand your hesitation with use of
> >> > reflection. I would love to have longer discussions on the F2F on what
> >> > approaches we could use to make this easier for Cordova developers.
> >> >
> >> > Joe: Could you add the appropriate engine tags in any case? That's how
> >> > Cordova currently handles versioning between plugins & platforms.
> >>Also,
> >> > does this imply that the plugins should have a major version bump as
> >>it
> >> is
> >> > a breaking change? Please create the 5.x branches and if you could
> >> submit a
> >> > PR - I had other minor code review comments on the diffs below.
> >> >
> >> > Carlos: I understand in the extreme case it can be a fairly
> >>complicated
> >> > implementation with lots of criteria to use to determine the ideal
> >>plugin
> >> > that might work given a set of platforms. However, trying a couple of
> >> > previous versions of the plugins might work 80% of the time and that
> >> might
> >> > be good enough. This requires more thought as there are quite a few
> >> > scenarios here.
> >> >
> >> > As for plugin search website helping you find the correct engine tags
> >>- I
> >> > like the idea. But this might requires us maintaining a backend for
> >> plugin
> >> > search as this is specified in plugin.xml (and not package.json - or
> >>did
> >> we
> >> > finally move this?).
> >> >
> >> > Thanks,
> >> > Nikhil
> >> >
> >> > -----Original Message-----
> >> > From: Carlos Santana [mailto:csantana23@gmail.com]
> >> > Sent: Tuesday, September 22, 2015 6:14 PM
> >> > To: dev@cordova.apache.org
> >> > Subject: Re: [Android] 5.0.x release branch?
> >> >
> >> > +1 we should always use the engine tag to mark the minimum compatible
> >> > +version at least
> >> >
> >> > -1 for cordova CLI to automagically to install an older version. It
> >>will
> >> > be a pain to get this implemented right, we would need to download all
> >> the
> >> > package.json for multiple versions of the plugin and pick the lowest
> >> common
> >> > denominator based on engine tags and remember that one plugin support
> >> > multiple engine tags across different platform versions and
> >>CLI/plugman.
> >> >
> >> > This brings an interesting feature to implement In the plugin search
> >> > website, to display the engine tags for a specific plugin version.
> >> Allowing
> >> > a developer to search for a compatible plugin for their current app.
> >> >
> >> > - Carlos
> >> > Sent from my iPhone
> >> >
> >> >
> >> > -----Original Message-----
> >> > From: Joe Bowser [mailto:bowserj@gmail.com]
> >> > Sent: Tuesday, September 22, 2015 6:17 PM
> >> > To: dev@cordova.apache.org
> >> > Subject: Re: [Android] 5.0.x release branch?
> >> >
> >> > I'm completely against using reflection for this purpose.  Version
> >>codes
> >> > were invented for a reason and we don't have any mechanism in place to
> >> unit
> >> > test any Android code (or any other native code on any of the
> >>platforms).
> >> >
> >> > I will vote against any release that includes reflection for this
> >>purpose
> >> > since reflection has only brought us security issues and extreme
> >>WebView
> >> > breakage when used (Simon can tell you the tales of the HTC
> >>console.log
> >> > reflection code.).  Reflection is a worst-case scenario tool like
> >>when a
> >> > method in WebView marked as deprecated completely disappears, not
> >> something
> >> > we should make a habit of using often.  If we open the door for this,
> >> we'll
> >> > get reflection creeping elsewhere, like the Plugins API.
> >> >
> >> > Just say no to reflection.
> >> >
> >> >
> >> > On Tue, Sep 22, 2015, 5:57 PM Nikhil Khandelwal
> >><ni...@microsoft.com>
> >> > wrote:
> >> >
> >> > > Thanks, Joe for the detailed explanation. I understand why we've
> >>taken
> >> > > this route. It's good that this is only a build failure. One of the
> >> > > complaints we commonly hear from Cordova developers is that "I have
> >>a
> >> > > cordova project with a certain version of the platform, I need to
> >>find
> >> > > the plugin that will work with it". Our CLI always defaults to add
> >>the
> >> > > latest released version of the plugin.
> >> > >
> >> > > After this breaking change, an existing cordova project with
> >> > > cordova-android < 5.x, cannot build with the latest version of the
> >> > > following plugins:
> >> > >                 - camera
> >> > >                - geolocation
> >> > >                - contacts.
> >> > > These are some of the most popular plugins in cordova plugin
> >>ecosystem
> >> > [1].
> >> > >
> >> > > I propose that we should do our best to avoid disruptive breaking
> >> > > changes here. Some ideas that come to mind:
> >> > > - As Joe mentioned below - reflection. It has the downsides that Joe
> >> > > mentioned. No one likes to write code like this it but results in
> >> > > least grief for Cordova users. Some pain here for plugin developers
> >> > > will simplify the experience for large number of corodva JS
> >> > > developers. I know we are doing some of this in cordova-ios [2] and
> >> > > would love to find ways on how to make this manageable and not super
> >> > ugly.
> >> > > - Add an  '<engine name="cordova-android" version=">=5.0.0" /> '  to
> >> > > the plugins - failure happens at plugin add in this scenario.
> >> > > Cordova-lib could be more intelligent to detect this error and
> >>resort
> >> > > to using an older version of the plugin. The downside of this is
> >>that
> >> > > these projects cannot use the latest and greatest of these plugins.
> >> > >
> >> > > Thanks,
> >> > > Nikhil
> >> > >
> >> > > [1]
> >> > >
> >>https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordov
> >> > >
> >>a.apache.org%2fuse-the-force-luke%2fplugins%2f%3fsortBy%3dDownloads&da
> >> > >
> >>ta=01%7c01%7cnikhilkh%40microsoft.com%7c5d1a100510734c0605f508d2c3b4b9
> >> > >
> >>c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7apFzmhrtn%2bKulHrNn46
> >> > > kkRG%2bZp3KarDUTf2y0i7P5I%3d
> >> > > [2]
> >> > >
> >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> >> > >
> >>b.com%2fapache%2fcordova-plugin-camera%2fblob%2fmaster%2fsrc%2fios%2fC
> >> > >
> >>DVCamera.m%23L44&data=01%7c01%7cnikhilkh%40microsoft.com%7c5d1a1005107
> >> > >
> >>34c0605f508d2c3b4b9c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CkH
> >> > > zeZ9uQUfYPDdAGlO2PJ9xJz89sZI5bdMRSlQtrMo%3d
> >> > >
> >> > > Thanks,
> >> > > Nikhil
> >> > >
> >> > >
> >> > > -----Original Message-----
> >> > > From: Joe Bowser [mailto:bowserj@gmail.com]
> >> > > Sent: Monday, September 21, 2015 6:32 PM
> >> > > To: dev@cordova.apache.org
> >> > > Subject: Re: [Android] 5.0.x release branch?
> >> > >
> >> > > On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal
> >> > > <ni...@microsoft.com>
> >> > > wrote:
> >> > >
> >> > > > Can you explain why latest plugins will not be compatible with
> >>older
> >> > > > versions of Cordova?
> >> > >
> >> > >
> >> > > They won't be compatible because Cordova-Android compiles against
> >>API
> >> > > 22, and these plugins will require API 23 so that they can detect
> >> > > permissions and support Marshmellow.
> >> > >
> >> > >
> >> > > > Can this be avoided by any means?
> >> > >
> >> > >
> >> > > Only with a lot of Java reflection, and I'd rather not subject
> >>plugin
> >> > > developers to that, or try to hide it under the hood in some awful
> >> > > utility class that everyone will want to see die.  I'm very much a
> >>fan
> >> > > of if statements because they work, and they're easy to read and
> >> > > debug, unlike when bad things happen to things you reflect into.
> >> > > Plugins that require API 23 will only work with Cordova-Android 5.0
> >> > > and up.  This only impacts five of our core plugins, but any plugin
> >> > > that requires permissions from the Android Manifest will have to be
> >> > > updated.  If we can avoid using advanced language tricks to make the
> >> > APKs compatible, we should do that.
> >> > >
> >> > > When you mean they would not be compatible - will it result in a
> >>build
> >> > > or
> >> > > > runtime failure?
> >> > > >
> >> > > >
> >> > > This will be a build failure, since API 22 does not have these
> >> > > permissions, nor does it have the code required for API 23.
> >> > >
> >> > >
> >> > > > For marshmallow, what is the guidance that we need to issue to the
> >> > > > larger Cordova plugin ecosystem? Joe you are ahead of the curve
> >>here
> >> > > > compared to most other plugin developers - a blot post explaining
> >> > > > what are known gotchas would be great. I really hope we can use
> >>our
> >> > > > Cordova blog to communicate these changes actively to the plugin
> >> > ecosystem.
> >> > > > This mailing list only gets 400+ subscribers.
> >> > > >
> >> > > >
> >> > > There will be a blog post once 5.0 is released.  We're not forcing
> >> > > people to upgrade to 5.0, and we will be supporting the 4.x branch
> >>for
> >> > > six months.  This does mean we're stuck supporting 3.x, 4.x and 5.x
> >> > > for a brief window, but I have no control over when Marshmallow is
> >> > > released, only whether we want to support it or not.  I think we do,
> >> but
> >> > I could be wrong.
> >> > >
> >> > > At least this should be easier than the jump from 3.x to 4.x for
> >>most
> >> > > people, but the alternative is that your plugin just doesn't work at
> >> > > all on Marshmallow.  We need to at least give plugin developers this
> >> > > option, since it'll roll out on all the Nexus devices in the next
> >>two
> >> > > weeks, and we'll hear more about it.
> >> > >
> >> > >
> >> > > > Can you re-base your cordova-android over the current master? It's
> >> > > > hard to see a diff in the current form:
> >> > > >
> >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> >> > > > hu
> >> > > >
> >>b.com%2fapache%2fcordova-android%2fcompare%2fmaster...infil00p%3asmo
> >> > > > re
> >> > > >
> >>s&data=01%7c01%7cnikhilkh%40microsoft.com%7cb451a04dccc64fabdb9608d2
> >> > > > c2
> >> > > >
> >>edb23c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j0bxz39itXdtylHJ
> >> > > > lv
> >> > > > PYoJpZqXMhFjyTV35I9X5Yxzs%3d
> >> > > >
> >> > > >
> >> > > I had to do a merge commit to get this to happen (boo), but it
> >>should
> >> > > be mostly cleaned up now.  It seems some style cleanup creeped into
> >> > > the most recent changes, but this should be a bit more readable.
> >> > >
> >> > >
> >> > > > -Nikhil
> >> > > >
> >> > > > -----Original Message-----
> >> > > > From: Joe Bowser [mailto:bowserj@gmail.com]
> >> > > > Sent: Monday, September 21, 2015 2:14 PM
> >> > > > To: dev <de...@cordova.apache.org>
> >> > > > Subject: [Android] 5.0.x release branch?
> >> > > >
> >> > > > Hey
> >> > > >
> >> > > > In the next two weeks, Marshmallow will most likely getting
> >>released
> >> > > > with the brand new Nexus 6P being released from Huawei.  Given
> >>that
> >> > > > most of the Nexus devices will be getting this release, we should
> >> > > > probably release the 5.0.x branch of Android soon, and get the new
> >> > > plugins updated.
> >> > > >
> >> > > > It should be noted that the latest plugins will not be compatible
> >> > > > with older versions of Cordova, which is a big deal.  This is due
> >>to
> >> > > > the use of various compatibility checks to make sure they support
> >> > > > Marshmallow and older versions of Android.
> >> > > >
> >> > > > So, if everyone can look over the smores branches of my GitHub
> >> > > > before I create the 5.0.x branch and pull the changes into it,
> >>that
> >> > > > would be
> >> > > awesome.
> >> > > >
> >> > > >
> >> > > >
> >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> >> > > > hu
> >> > > >
> >>b.com%2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cni
> >> > > > kh
> >> > > >
> >>ilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86
> >> > > > f1
> >> > > >
> >>41af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%
> >> > > > 2b
> >> > > > ve4PVcCE%3d
> >> > > >
> >> > > >
> >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> >> > > > hu
> >> > > >
> >>b.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=0
> >> > > > 1%
> >> > > >
> >>7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7
> >> > > > c7
> >> > > >
> >>2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv
> >> > > > 6p
> >> > > > c5qbeY%2bdUxiP4bc%3d
> >> > > >
> >> > > >
> >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> >> > > > hu
> >> > > >
> >>b.com%2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c0
> >> > > > 1%
> >> > > >
> >>7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f9
> >> > > > 88
> >> > > >
> >>bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCG
> >> > > > Rb
> >> > > > 4zWC8maWpE%3d
> >> > > >
> >> > > >
> >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> >> > > > hu
> >> > > >
> >>b.com%2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7
> >> > > > c0
> >> > > >
> >>1%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72
> >> > > > f9
> >> > > >
> >>88bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2
> >> > > > fe
> >> > > > EmqLOdU%2fwua2TbLU%3d
> >> > > >
> >> > > > Work on audio is still outstanding, BUT for some reason Audio
> >>broke
> >> > > > recently on both Lollipop and Marshmallow.  I didn't test it out
> >>on
> >> > > > KitKat or Jellybean yet, but I'm wondering whether we should keep
> >> > > > maintaining this or support the standard HTML5 audio and deal with
> >> > > > the asset issue somehow (which isn't straight forward).
> >> > > >
> >> > > > I hopefully want to get a 5.0.x branch happening this week if we
> >>can.
> >> > > >
> >> > > > What do people think?
> >> > > >
> >> > > > Joe
> >> > > >
> >> > >
> >> >
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>

Re: [Android] 5.0.x release branch?

Posted by "Homer, Tony" <to...@intel.com>.

Joe-

As far as I can tell, the API 23 calls are currently unguarded so smores
will only work on M Preview.
I know your smores branch is a POC, but I was wondering about backwards
compatibility.
Do you anticipate adding Build.VERSION.SDK_INT >= Build.VERSION_CODES.M
guard clauses for backwards compatibility?

Tony

On 9/23/15, 1:56 PM, "Joe Bowser" <bo...@gmail.com> wrote:

>On Wed, Sep 23, 2015 at 9:36 AM, Carlos Santana <cs...@gmail.com>
>wrote:
>
>> No need to major version change for the Plugins, the API of the didn't
>> change.
>> Web developer still uses the same JS API to use the plugin.
>>
>>
>I would do a major version bump on Geolocation.  The API itself didn't
>change but the behaviour certainly did.  On Marshmallow we have to add
>this
>extra shim that asks for permission, which means that there's now code
>attached to Android Geolocation that didn't exist before.  All the other
>plugins should still be fine.
>
>
>> Yes I did some thinking around the plugin search website. I think is a
>>good
>> topic for the F2F.
>> Now that IBM is using Cordova Plugin more heavily to package our mobile
>> SDKs using Cordova Plugins, I think is beneficial to expose more info
>>about
>> the plugin including engine tags
>>
>> I would not go and build our own backend and have our own registry with
>> cordova metadata.
>>
>> I think the solution is to put the metadata of plugin.xml into
>> package.json. We can show fast results in main search, but then user can
>> drill into the plugin details, and we can have a view with more
>>information
>> and allow the user to select a specific version like we have today in
>>our
>> plugin website search using the cordova registry.
>>
>> The website can fetch the package.json and it will have the information
>>to
>> display to the user.
>>
>> So what I think we need to do is document and automate the information
>>from
>> plugin.xml including engine tags into the package.json.
>>
>> Today we have some sort of duplicate information between the "cordova"
>>and
>> "keywords", I think it would be a good time to clean it up and add an
>>array
>> in cordova.engines
>>
>>
>>
>> On Wed, Sep 23, 2015 at 12:19 PM Nikhil Khandelwal
>><nikhilkh@microsoft.com
>> >
>> wrote:
>>
>> > Merging threads. I was no aware of any security implications of using
>> > reflection - Perhaps if the reflection target can be controlled
>>through
>> > external data. In any case, I understand your hesitation with use of
>> > reflection. I would love to have longer discussions on the F2F on what
>> > approaches we could use to make this easier for Cordova developers.
>> >
>> > Joe: Could you add the appropriate engine tags in any case? That's how
>> > Cordova currently handles versioning between plugins & platforms.
>>Also,
>> > does this imply that the plugins should have a major version bump as
>>it
>> is
>> > a breaking change? Please create the 5.x branches and if you could
>> submit a
>> > PR - I had other minor code review comments on the diffs below.
>> >
>> > Carlos: I understand in the extreme case it can be a fairly
>>complicated
>> > implementation with lots of criteria to use to determine the ideal
>>plugin
>> > that might work given a set of platforms. However, trying a couple of
>> > previous versions of the plugins might work 80% of the time and that
>> might
>> > be good enough. This requires more thought as there are quite a few
>> > scenarios here.
>> >
>> > As for plugin search website helping you find the correct engine tags
>>- I
>> > like the idea. But this might requires us maintaining a backend for
>> plugin
>> > search as this is specified in plugin.xml (and not package.json - or
>>did
>> we
>> > finally move this?).
>> >
>> > Thanks,
>> > Nikhil
>> >
>> > -----Original Message-----
>> > From: Carlos Santana [mailto:csantana23@gmail.com]
>> > Sent: Tuesday, September 22, 2015 6:14 PM
>> > To: dev@cordova.apache.org
>> > Subject: Re: [Android] 5.0.x release branch?
>> >
>> > +1 we should always use the engine tag to mark the minimum compatible
>> > +version at least
>> >
>> > -1 for cordova CLI to automagically to install an older version. It
>>will
>> > be a pain to get this implemented right, we would need to download all
>> the
>> > package.json for multiple versions of the plugin and pick the lowest
>> common
>> > denominator based on engine tags and remember that one plugin support
>> > multiple engine tags across different platform versions and
>>CLI/plugman.
>> >
>> > This brings an interesting feature to implement In the plugin search
>> > website, to display the engine tags for a specific plugin version.
>> Allowing
>> > a developer to search for a compatible plugin for their current app.
>> >
>> > - Carlos
>> > Sent from my iPhone
>> >
>> >
>> > -----Original Message-----
>> > From: Joe Bowser [mailto:bowserj@gmail.com]
>> > Sent: Tuesday, September 22, 2015 6:17 PM
>> > To: dev@cordova.apache.org
>> > Subject: Re: [Android] 5.0.x release branch?
>> >
>> > I'm completely against using reflection for this purpose.  Version
>>codes
>> > were invented for a reason and we don't have any mechanism in place to
>> unit
>> > test any Android code (or any other native code on any of the
>>platforms).
>> >
>> > I will vote against any release that includes reflection for this
>>purpose
>> > since reflection has only brought us security issues and extreme
>>WebView
>> > breakage when used (Simon can tell you the tales of the HTC
>>console.log
>> > reflection code.).  Reflection is a worst-case scenario tool like
>>when a
>> > method in WebView marked as deprecated completely disappears, not
>> something
>> > we should make a habit of using often.  If we open the door for this,
>> we'll
>> > get reflection creeping elsewhere, like the Plugins API.
>> >
>> > Just say no to reflection.
>> >
>> >
>> > On Tue, Sep 22, 2015, 5:57 PM Nikhil Khandelwal
>><ni...@microsoft.com>
>> > wrote:
>> >
>> > > Thanks, Joe for the detailed explanation. I understand why we've
>>taken
>> > > this route. It's good that this is only a build failure. One of the
>> > > complaints we commonly hear from Cordova developers is that "I have
>>a
>> > > cordova project with a certain version of the platform, I need to
>>find
>> > > the plugin that will work with it". Our CLI always defaults to add
>>the
>> > > latest released version of the plugin.
>> > >
>> > > After this breaking change, an existing cordova project with
>> > > cordova-android < 5.x, cannot build with the latest version of the
>> > > following plugins:
>> > >                 - camera
>> > >                - geolocation
>> > >                - contacts.
>> > > These are some of the most popular plugins in cordova plugin
>>ecosystem
>> > [1].
>> > >
>> > > I propose that we should do our best to avoid disruptive breaking
>> > > changes here. Some ideas that come to mind:
>> > > - As Joe mentioned below - reflection. It has the downsides that Joe
>> > > mentioned. No one likes to write code like this it but results in
>> > > least grief for Cordova users. Some pain here for plugin developers
>> > > will simplify the experience for large number of corodva JS
>> > > developers. I know we are doing some of this in cordova-ios [2] and
>> > > would love to find ways on how to make this manageable and not super
>> > ugly.
>> > > - Add an  '<engine name="cordova-android" version=">=5.0.0" /> '  to
>> > > the plugins - failure happens at plugin add in this scenario.
>> > > Cordova-lib could be more intelligent to detect this error and
>>resort
>> > > to using an older version of the plugin. The downside of this is
>>that
>> > > these projects cannot use the latest and greatest of these plugins.
>> > >
>> > > Thanks,
>> > > Nikhil
>> > >
>> > > [1]
>> > > 
>>https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordov
>> > > 
>>a.apache.org%2fuse-the-force-luke%2fplugins%2f%3fsortBy%3dDownloads&da
>> > > 
>>ta=01%7c01%7cnikhilkh%40microsoft.com%7c5d1a100510734c0605f508d2c3b4b9
>> > > 
>>c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7apFzmhrtn%2bKulHrNn46
>> > > kkRG%2bZp3KarDUTf2y0i7P5I%3d
>> > > [2]
>> > > 
>>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
>> > > 
>>b.com%2fapache%2fcordova-plugin-camera%2fblob%2fmaster%2fsrc%2fios%2fC
>> > > 
>>DVCamera.m%23L44&data=01%7c01%7cnikhilkh%40microsoft.com%7c5d1a1005107
>> > > 
>>34c0605f508d2c3b4b9c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CkH
>> > > zeZ9uQUfYPDdAGlO2PJ9xJz89sZI5bdMRSlQtrMo%3d
>> > >
>> > > Thanks,
>> > > Nikhil
>> > >
>> > >
>> > > -----Original Message-----
>> > > From: Joe Bowser [mailto:bowserj@gmail.com]
>> > > Sent: Monday, September 21, 2015 6:32 PM
>> > > To: dev@cordova.apache.org
>> > > Subject: Re: [Android] 5.0.x release branch?
>> > >
>> > > On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal
>> > > <ni...@microsoft.com>
>> > > wrote:
>> > >
>> > > > Can you explain why latest plugins will not be compatible with
>>older
>> > > > versions of Cordova?
>> > >
>> > >
>> > > They won't be compatible because Cordova-Android compiles against
>>API
>> > > 22, and these plugins will require API 23 so that they can detect
>> > > permissions and support Marshmellow.
>> > >
>> > >
>> > > > Can this be avoided by any means?
>> > >
>> > >
>> > > Only with a lot of Java reflection, and I'd rather not subject
>>plugin
>> > > developers to that, or try to hide it under the hood in some awful
>> > > utility class that everyone will want to see die.  I'm very much a
>>fan
>> > > of if statements because they work, and they're easy to read and
>> > > debug, unlike when bad things happen to things you reflect into.
>> > > Plugins that require API 23 will only work with Cordova-Android 5.0
>> > > and up.  This only impacts five of our core plugins, but any plugin
>> > > that requires permissions from the Android Manifest will have to be
>> > > updated.  If we can avoid using advanced language tricks to make the
>> > APKs compatible, we should do that.
>> > >
>> > > When you mean they would not be compatible - will it result in a
>>build
>> > > or
>> > > > runtime failure?
>> > > >
>> > > >
>> > > This will be a build failure, since API 22 does not have these
>> > > permissions, nor does it have the code required for API 23.
>> > >
>> > >
>> > > > For marshmallow, what is the guidance that we need to issue to the
>> > > > larger Cordova plugin ecosystem? Joe you are ahead of the curve
>>here
>> > > > compared to most other plugin developers - a blot post explaining
>> > > > what are known gotchas would be great. I really hope we can use
>>our
>> > > > Cordova blog to communicate these changes actively to the plugin
>> > ecosystem.
>> > > > This mailing list only gets 400+ subscribers.
>> > > >
>> > > >
>> > > There will be a blog post once 5.0 is released.  We're not forcing
>> > > people to upgrade to 5.0, and we will be supporting the 4.x branch
>>for
>> > > six months.  This does mean we're stuck supporting 3.x, 4.x and 5.x
>> > > for a brief window, but I have no control over when Marshmallow is
>> > > released, only whether we want to support it or not.  I think we do,
>> but
>> > I could be wrong.
>> > >
>> > > At least this should be easier than the jump from 3.x to 4.x for
>>most
>> > > people, but the alternative is that your plugin just doesn't work at
>> > > all on Marshmallow.  We need to at least give plugin developers this
>> > > option, since it'll roll out on all the Nexus devices in the next
>>two
>> > > weeks, and we'll hear more about it.
>> > >
>> > >
>> > > > Can you re-base your cordova-android over the current master? It's
>> > > > hard to see a diff in the current form:
>> > > > 
>>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
>> > > > hu
>> > > > 
>>b.com%2fapache%2fcordova-android%2fcompare%2fmaster...infil00p%3asmo
>> > > > re
>> > > > 
>>s&data=01%7c01%7cnikhilkh%40microsoft.com%7cb451a04dccc64fabdb9608d2
>> > > > c2
>> > > > 
>>edb23c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j0bxz39itXdtylHJ
>> > > > lv
>> > > > PYoJpZqXMhFjyTV35I9X5Yxzs%3d
>> > > >
>> > > >
>> > > I had to do a merge commit to get this to happen (boo), but it
>>should
>> > > be mostly cleaned up now.  It seems some style cleanup creeped into
>> > > the most recent changes, but this should be a bit more readable.
>> > >
>> > >
>> > > > -Nikhil
>> > > >
>> > > > -----Original Message-----
>> > > > From: Joe Bowser [mailto:bowserj@gmail.com]
>> > > > Sent: Monday, September 21, 2015 2:14 PM
>> > > > To: dev <de...@cordova.apache.org>
>> > > > Subject: [Android] 5.0.x release branch?
>> > > >
>> > > > Hey
>> > > >
>> > > > In the next two weeks, Marshmallow will most likely getting
>>released
>> > > > with the brand new Nexus 6P being released from Huawei.  Given
>>that
>> > > > most of the Nexus devices will be getting this release, we should
>> > > > probably release the 5.0.x branch of Android soon, and get the new
>> > > plugins updated.
>> > > >
>> > > > It should be noted that the latest plugins will not be compatible
>> > > > with older versions of Cordova, which is a big deal.  This is due
>>to
>> > > > the use of various compatibility checks to make sure they support
>> > > > Marshmallow and older versions of Android.
>> > > >
>> > > > So, if everyone can look over the smores branches of my GitHub
>> > > > before I create the 5.0.x branch and pull the changes into it,
>>that
>> > > > would be
>> > > awesome.
>> > > >
>> > > >
>> > > > 
>>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
>> > > > hu
>> > > > 
>>b.com%2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cni
>> > > > kh
>> > > > 
>>ilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86
>> > > > f1
>> > > > 
>>41af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%
>> > > > 2b
>> > > > ve4PVcCE%3d
>> > > >
>> > > > 
>>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
>> > > > hu
>> > > > 
>>b.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=0
>> > > > 1%
>> > > > 
>>7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7
>> > > > c7
>> > > > 
>>2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv
>> > > > 6p
>> > > > c5qbeY%2bdUxiP4bc%3d
>> > > >
>> > > > 
>>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
>> > > > hu
>> > > > 
>>b.com%2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c0
>> > > > 1%
>> > > > 
>>7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f9
>> > > > 88
>> > > > 
>>bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCG
>> > > > Rb
>> > > > 4zWC8maWpE%3d
>> > > >
>> > > > 
>>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
>> > > > hu
>> > > > 
>>b.com%2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7
>> > > > c0
>> > > > 
>>1%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72
>> > > > f9
>> > > > 
>>88bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2
>> > > > fe
>> > > > EmqLOdU%2fwua2TbLU%3d
>> > > >
>> > > > Work on audio is still outstanding, BUT for some reason Audio
>>broke
>> > > > recently on both Lollipop and Marshmallow.  I didn't test it out
>>on
>> > > > KitKat or Jellybean yet, but I'm wondering whether we should keep
>> > > > maintaining this or support the standard HTML5 audio and deal with
>> > > > the asset issue somehow (which isn't straight forward).
>> > > >
>> > > > I hopefully want to get a 5.0.x branch happening this week if we
>>can.
>> > > >
>> > > > What do people think?
>> > > >
>> > > > Joe
>> > > >
>> > >
>> >
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org

Re: [Android] 5.0.x release branch?

Posted by Joe Bowser <bo...@gmail.com>.

On Wed, Sep 23, 2015 at 9:36 AM, Carlos Santana <cs...@gmail.com>
wrote:

> No need to major version change for the Plugins, the API of the didn't
> change.
> Web developer still uses the same JS API to use the plugin.
>
>
I would do a major version bump on Geolocation.  The API itself didn't
change but the behaviour certainly did.  On Marshmallow we have to add this
extra shim that asks for permission, which means that there's now code
attached to Android Geolocation that didn't exist before.  All the other
plugins should still be fine.


> Yes I did some thinking around the plugin search website. I think is a good
> topic for the F2F.
> Now that IBM is using Cordova Plugin more heavily to package our mobile
> SDKs using Cordova Plugins, I think is beneficial to expose more info about
> the plugin including engine tags
>
> I would not go and build our own backend and have our own registry with
> cordova metadata.
>
> I think the solution is to put the metadata of plugin.xml into
> package.json. We can show fast results in main search, but then user can
> drill into the plugin details, and we can have a view with more information
> and allow the user to select a specific version like we have today in our
> plugin website search using the cordova registry.
>
> The website can fetch the package.json and it will have the information to
> display to the user.
>
> So what I think we need to do is document and automate the information from
> plugin.xml including engine tags into the package.json.
>
> Today we have some sort of duplicate information between the "cordova" and
> "keywords", I think it would be a good time to clean it up and add an array
> in cordova.engines
>
>
>
> On Wed, Sep 23, 2015 at 12:19 PM Nikhil Khandelwal <nikhilkh@microsoft.com
> >
> wrote:
>
> > Merging threads. I was no aware of any security implications of using
> > reflection - Perhaps if the reflection target can be controlled through
> > external data. In any case, I understand your hesitation with use of
> > reflection. I would love to have longer discussions on the F2F on what
> > approaches we could use to make this easier for Cordova developers.
> >
> > Joe: Could you add the appropriate engine tags in any case? That's how
> > Cordova currently handles versioning between plugins & platforms. Also,
> > does this imply that the plugins should have a major version bump as it
> is
> > a breaking change? Please create the 5.x branches and if you could
> submit a
> > PR - I had other minor code review comments on the diffs below.
> >
> > Carlos: I understand in the extreme case it can be a fairly complicated
> > implementation with lots of criteria to use to determine the ideal plugin
> > that might work given a set of platforms. However, trying a couple of
> > previous versions of the plugins might work 80% of the time and that
> might
> > be good enough. This requires more thought as there are quite a few
> > scenarios here.
> >
> > As for plugin search website helping you find the correct engine tags - I
> > like the idea. But this might requires us maintaining a backend for
> plugin
> > search as this is specified in plugin.xml (and not package.json - or did
> we
> > finally move this?).
> >
> > Thanks,
> > Nikhil
> >
> > -----Original Message-----
> > From: Carlos Santana [mailto:csantana23@gmail.com]
> > Sent: Tuesday, September 22, 2015 6:14 PM
> > To: dev@cordova.apache.org
> > Subject: Re: [Android] 5.0.x release branch?
> >
> > +1 we should always use the engine tag to mark the minimum compatible
> > +version at least
> >
> > -1 for cordova CLI to automagically to install an older version. It will
> > be a pain to get this implemented right, we would need to download all
> the
> > package.json for multiple versions of the plugin and pick the lowest
> common
> > denominator based on engine tags and remember that one plugin support
> > multiple engine tags across different platform versions and CLI/plugman.
> >
> > This brings an interesting feature to implement In the plugin search
> > website, to display the engine tags for a specific plugin version.
> Allowing
> > a developer to search for a compatible plugin for their current app.
> >
> > - Carlos
> > Sent from my iPhone
> >
> >
> > -----Original Message-----
> > From: Joe Bowser [mailto:bowserj@gmail.com]
> > Sent: Tuesday, September 22, 2015 6:17 PM
> > To: dev@cordova.apache.org
> > Subject: Re: [Android] 5.0.x release branch?
> >
> > I'm completely against using reflection for this purpose.  Version codes
> > were invented for a reason and we don't have any mechanism in place to
> unit
> > test any Android code (or any other native code on any of the platforms).
> >
> > I will vote against any release that includes reflection for this purpose
> > since reflection has only brought us security issues and extreme WebView
> > breakage when used (Simon can tell you the tales of the HTC console.log
> > reflection code.).  Reflection is a worst-case scenario tool like when a
> > method in WebView marked as deprecated completely disappears, not
> something
> > we should make a habit of using often.  If we open the door for this,
> we'll
> > get reflection creeping elsewhere, like the Plugins API.
> >
> > Just say no to reflection.
> >
> >
> > On Tue, Sep 22, 2015, 5:57 PM Nikhil Khandelwal <ni...@microsoft.com>
> > wrote:
> >
> > > Thanks, Joe for the detailed explanation. I understand why we've taken
> > > this route. It's good that this is only a build failure. One of the
> > > complaints we commonly hear from Cordova developers is that "I have a
> > > cordova project with a certain version of the platform, I need to find
> > > the plugin that will work with it". Our CLI always defaults to add the
> > > latest released version of the plugin.
> > >
> > > After this breaking change, an existing cordova project with
> > > cordova-android < 5.x, cannot build with the latest version of the
> > > following plugins:
> > >                 - camera
> > >                - geolocation
> > >                - contacts.
> > > These are some of the most popular plugins in cordova plugin ecosystem
> > [1].
> > >
> > > I propose that we should do our best to avoid disruptive breaking
> > > changes here. Some ideas that come to mind:
> > > - As Joe mentioned below - reflection. It has the downsides that Joe
> > > mentioned. No one likes to write code like this it but results in
> > > least grief for Cordova users. Some pain here for plugin developers
> > > will simplify the experience for large number of corodva JS
> > > developers. I know we are doing some of this in cordova-ios [2] and
> > > would love to find ways on how to make this manageable and not super
> > ugly.
> > > - Add an  '<engine name="cordova-android" version=">=5.0.0" /> '  to
> > > the plugins - failure happens at plugin add in this scenario.
> > > Cordova-lib could be more intelligent to detect this error and resort
> > > to using an older version of the plugin. The downside of this is that
> > > these projects cannot use the latest and greatest of these plugins.
> > >
> > > Thanks,
> > > Nikhil
> > >
> > > [1]
> > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordov
> > > a.apache.org%2fuse-the-force-luke%2fplugins%2f%3fsortBy%3dDownloads&da
> > > ta=01%7c01%7cnikhilkh%40microsoft.com%7c5d1a100510734c0605f508d2c3b4b9
> > > c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7apFzmhrtn%2bKulHrNn46
> > > kkRG%2bZp3KarDUTf2y0i7P5I%3d
> > > [2]
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> > > b.com%2fapache%2fcordova-plugin-camera%2fblob%2fmaster%2fsrc%2fios%2fC
> > > DVCamera.m%23L44&data=01%7c01%7cnikhilkh%40microsoft.com%7c5d1a1005107
> > > 34c0605f508d2c3b4b9c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CkH
> > > zeZ9uQUfYPDdAGlO2PJ9xJz89sZI5bdMRSlQtrMo%3d
> > >
> > > Thanks,
> > > Nikhil
> > >
> > >
> > > -----Original Message-----
> > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > Sent: Monday, September 21, 2015 6:32 PM
> > > To: dev@cordova.apache.org
> > > Subject: Re: [Android] 5.0.x release branch?
> > >
> > > On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal
> > > <ni...@microsoft.com>
> > > wrote:
> > >
> > > > Can you explain why latest plugins will not be compatible with older
> > > > versions of Cordova?
> > >
> > >
> > > They won't be compatible because Cordova-Android compiles against API
> > > 22, and these plugins will require API 23 so that they can detect
> > > permissions and support Marshmellow.
> > >
> > >
> > > > Can this be avoided by any means?
> > >
> > >
> > > Only with a lot of Java reflection, and I'd rather not subject plugin
> > > developers to that, or try to hide it under the hood in some awful
> > > utility class that everyone will want to see die.  I'm very much a fan
> > > of if statements because they work, and they're easy to read and
> > > debug, unlike when bad things happen to things you reflect into.
> > > Plugins that require API 23 will only work with Cordova-Android 5.0
> > > and up.  This only impacts five of our core plugins, but any plugin
> > > that requires permissions from the Android Manifest will have to be
> > > updated.  If we can avoid using advanced language tricks to make the
> > APKs compatible, we should do that.
> > >
> > > When you mean they would not be compatible - will it result in a build
> > > or
> > > > runtime failure?
> > > >
> > > >
> > > This will be a build failure, since API 22 does not have these
> > > permissions, nor does it have the code required for API 23.
> > >
> > >
> > > > For marshmallow, what is the guidance that we need to issue to the
> > > > larger Cordova plugin ecosystem? Joe you are ahead of the curve here
> > > > compared to most other plugin developers - a blot post explaining
> > > > what are known gotchas would be great. I really hope we can use our
> > > > Cordova blog to communicate these changes actively to the plugin
> > ecosystem.
> > > > This mailing list only gets 400+ subscribers.
> > > >
> > > >
> > > There will be a blog post once 5.0 is released.  We're not forcing
> > > people to upgrade to 5.0, and we will be supporting the 4.x branch for
> > > six months.  This does mean we're stuck supporting 3.x, 4.x and 5.x
> > > for a brief window, but I have no control over when Marshmallow is
> > > released, only whether we want to support it or not.  I think we do,
> but
> > I could be wrong.
> > >
> > > At least this should be easier than the jump from 3.x to 4.x for most
> > > people, but the alternative is that your plugin just doesn't work at
> > > all on Marshmallow.  We need to at least give plugin developers this
> > > option, since it'll roll out on all the Nexus devices in the next two
> > > weeks, and we'll hear more about it.
> > >
> > >
> > > > Can you re-base your cordova-android over the current master? It's
> > > > hard to see a diff in the current form:
> > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > > hu
> > > > b.com%2fapache%2fcordova-android%2fcompare%2fmaster...infil00p%3asmo
> > > > re
> > > > s&data=01%7c01%7cnikhilkh%40microsoft.com%7cb451a04dccc64fabdb9608d2
> > > > c2
> > > > edb23c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j0bxz39itXdtylHJ
> > > > lv
> > > > PYoJpZqXMhFjyTV35I9X5Yxzs%3d
> > > >
> > > >
> > > I had to do a merge commit to get this to happen (boo), but it should
> > > be mostly cleaned up now.  It seems some style cleanup creeped into
> > > the most recent changes, but this should be a bit more readable.
> > >
> > >
> > > > -Nikhil
> > > >
> > > > -----Original Message-----
> > > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > > Sent: Monday, September 21, 2015 2:14 PM
> > > > To: dev <de...@cordova.apache.org>
> > > > Subject: [Android] 5.0.x release branch?
> > > >
> > > > Hey
> > > >
> > > > In the next two weeks, Marshmallow will most likely getting released
> > > > with the brand new Nexus 6P being released from Huawei.  Given that
> > > > most of the Nexus devices will be getting this release, we should
> > > > probably release the 5.0.x branch of Android soon, and get the new
> > > plugins updated.
> > > >
> > > > It should be noted that the latest plugins will not be compatible
> > > > with older versions of Cordova, which is a big deal.  This is due to
> > > > the use of various compatibility checks to make sure they support
> > > > Marshmallow and older versions of Android.
> > > >
> > > > So, if everyone can look over the smores branches of my GitHub
> > > > before I create the 5.0.x branch and pull the changes into it, that
> > > > would be
> > > awesome.
> > > >
> > > >
> > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > > hu
> > > > b.com%2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cni
> > > > kh
> > > > ilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86
> > > > f1
> > > > 41af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%
> > > > 2b
> > > > ve4PVcCE%3d
> > > >
> > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > > hu
> > > > b.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=0
> > > > 1%
> > > > 7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7
> > > > c7
> > > > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv
> > > > 6p
> > > > c5qbeY%2bdUxiP4bc%3d
> > > >
> > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > > hu
> > > > b.com%2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c0
> > > > 1%
> > > > 7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f9
> > > > 88
> > > > bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCG
> > > > Rb
> > > > 4zWC8maWpE%3d
> > > >
> > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > > hu
> > > > b.com%2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7
> > > > c0
> > > > 1%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72
> > > > f9
> > > > 88bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2
> > > > fe
> > > > EmqLOdU%2fwua2TbLU%3d
> > > >
> > > > Work on audio is still outstanding, BUT for some reason Audio broke
> > > > recently on both Lollipop and Marshmallow.  I didn't test it out on
> > > > KitKat or Jellybean yet, but I'm wondering whether we should keep
> > > > maintaining this or support the standard HTML5 audio and deal with
> > > > the asset issue somehow (which isn't straight forward).
> > > >
> > > > I hopefully want to get a 5.0.x branch happening this week if we can.
> > > >
> > > > What do people think?
> > > >
> > > > Joe
> > > >
> > >
> >
>

Re: [Android] 5.0.x release branch?

Posted by Carlos Santana <cs...@gmail.com>.

No need to major version change for the Plugins, the API of the didn't
change.
Web developer still uses the same JS API to use the plugin.

Yes I did some thinking around the plugin search website. I think is a good
topic for the F2F.
Now that IBM is using Cordova Plugin more heavily to package our mobile
SDKs using Cordova Plugins, I think is beneficial to expose more info about
the plugin including engine tags

I would not go and build our own backend and have our own registry with
cordova metadata.

I think the solution is to put the metadata of plugin.xml into
package.json. We can show fast results in main search, but then user can
drill into the plugin details, and we can have a view with more information
and allow the user to select a specific version like we have today in our
plugin website search using the cordova registry.

The website can fetch the package.json and it will have the information to
display to the user.

So what I think we need to do is document and automate the information from
plugin.xml including engine tags into the package.json.

Today we have some sort of duplicate information between the "cordova" and
"keywords", I think it would be a good time to clean it up and add an array
in cordova.engines



On Wed, Sep 23, 2015 at 12:19 PM Nikhil Khandelwal <ni...@microsoft.com>
wrote:

> Merging threads. I was no aware of any security implications of using
> reflection - Perhaps if the reflection target can be controlled through
> external data. In any case, I understand your hesitation with use of
> reflection. I would love to have longer discussions on the F2F on what
> approaches we could use to make this easier for Cordova developers.
>
> Joe: Could you add the appropriate engine tags in any case? That's how
> Cordova currently handles versioning between plugins & platforms. Also,
> does this imply that the plugins should have a major version bump as it is
> a breaking change? Please create the 5.x branches and if you could submit a
> PR - I had other minor code review comments on the diffs below.
>
> Carlos: I understand in the extreme case it can be a fairly complicated
> implementation with lots of criteria to use to determine the ideal plugin
> that might work given a set of platforms. However, trying a couple of
> previous versions of the plugins might work 80% of the time and that might
> be good enough. This requires more thought as there are quite a few
> scenarios here.
>
> As for plugin search website helping you find the correct engine tags - I
> like the idea. But this might requires us maintaining a backend for plugin
> search as this is specified in plugin.xml (and not package.json - or did we
> finally move this?).
>
> Thanks,
> Nikhil
>
> -----Original Message-----
> From: Carlos Santana [mailto:csantana23@gmail.com]
> Sent: Tuesday, September 22, 2015 6:14 PM
> To: dev@cordova.apache.org
> Subject: Re: [Android] 5.0.x release branch?
>
> +1 we should always use the engine tag to mark the minimum compatible
> +version at least
>
> -1 for cordova CLI to automagically to install an older version. It will
> be a pain to get this implemented right, we would need to download all the
> package.json for multiple versions of the plugin and pick the lowest common
> denominator based on engine tags and remember that one plugin support
> multiple engine tags across different platform versions and CLI/plugman.
>
> This brings an interesting feature to implement In the plugin search
> website, to display the engine tags for a specific plugin version. Allowing
> a developer to search for a compatible plugin for their current app.
>
> - Carlos
> Sent from my iPhone
>
>
> -----Original Message-----
> From: Joe Bowser [mailto:bowserj@gmail.com]
> Sent: Tuesday, September 22, 2015 6:17 PM
> To: dev@cordova.apache.org
> Subject: Re: [Android] 5.0.x release branch?
>
> I'm completely against using reflection for this purpose.  Version codes
> were invented for a reason and we don't have any mechanism in place to unit
> test any Android code (or any other native code on any of the platforms).
>
> I will vote against any release that includes reflection for this purpose
> since reflection has only brought us security issues and extreme WebView
> breakage when used (Simon can tell you the tales of the HTC console.log
> reflection code.).  Reflection is a worst-case scenario tool like when a
> method in WebView marked as deprecated completely disappears, not something
> we should make a habit of using often.  If we open the door for this, we'll
> get reflection creeping elsewhere, like the Plugins API.
>
> Just say no to reflection.
>
>
> On Tue, Sep 22, 2015, 5:57 PM Nikhil Khandelwal <ni...@microsoft.com>
> wrote:
>
> > Thanks, Joe for the detailed explanation. I understand why we've taken
> > this route. It's good that this is only a build failure. One of the
> > complaints we commonly hear from Cordova developers is that "I have a
> > cordova project with a certain version of the platform, I need to find
> > the plugin that will work with it". Our CLI always defaults to add the
> > latest released version of the plugin.
> >
> > After this breaking change, an existing cordova project with
> > cordova-android < 5.x, cannot build with the latest version of the
> > following plugins:
> >                 - camera
> >                - geolocation
> >                - contacts.
> > These are some of the most popular plugins in cordova plugin ecosystem
> [1].
> >
> > I propose that we should do our best to avoid disruptive breaking
> > changes here. Some ideas that come to mind:
> > - As Joe mentioned below - reflection. It has the downsides that Joe
> > mentioned. No one likes to write code like this it but results in
> > least grief for Cordova users. Some pain here for plugin developers
> > will simplify the experience for large number of corodva JS
> > developers. I know we are doing some of this in cordova-ios [2] and
> > would love to find ways on how to make this manageable and not super
> ugly.
> > - Add an  '<engine name="cordova-android" version=">=5.0.0" /> '  to
> > the plugins - failure happens at plugin add in this scenario.
> > Cordova-lib could be more intelligent to detect this error and resort
> > to using an older version of the plugin. The downside of this is that
> > these projects cannot use the latest and greatest of these plugins.
> >
> > Thanks,
> > Nikhil
> >
> > [1]
> > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordov
> > a.apache.org%2fuse-the-force-luke%2fplugins%2f%3fsortBy%3dDownloads&da
> > ta=01%7c01%7cnikhilkh%40microsoft.com%7c5d1a100510734c0605f508d2c3b4b9
> > c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7apFzmhrtn%2bKulHrNn46
> > kkRG%2bZp3KarDUTf2y0i7P5I%3d
> > [2]
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> > b.com%2fapache%2fcordova-plugin-camera%2fblob%2fmaster%2fsrc%2fios%2fC
> > DVCamera.m%23L44&data=01%7c01%7cnikhilkh%40microsoft.com%7c5d1a1005107
> > 34c0605f508d2c3b4b9c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CkH
> > zeZ9uQUfYPDdAGlO2PJ9xJz89sZI5bdMRSlQtrMo%3d
> >
> > Thanks,
> > Nikhil
> >
> >
> > -----Original Message-----
> > From: Joe Bowser [mailto:bowserj@gmail.com]
> > Sent: Monday, September 21, 2015 6:32 PM
> > To: dev@cordova.apache.org
> > Subject: Re: [Android] 5.0.x release branch?
> >
> > On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal
> > <ni...@microsoft.com>
> > wrote:
> >
> > > Can you explain why latest plugins will not be compatible with older
> > > versions of Cordova?
> >
> >
> > They won't be compatible because Cordova-Android compiles against API
> > 22, and these plugins will require API 23 so that they can detect
> > permissions and support Marshmellow.
> >
> >
> > > Can this be avoided by any means?
> >
> >
> > Only with a lot of Java reflection, and I'd rather not subject plugin
> > developers to that, or try to hide it under the hood in some awful
> > utility class that everyone will want to see die.  I'm very much a fan
> > of if statements because they work, and they're easy to read and
> > debug, unlike when bad things happen to things you reflect into.
> > Plugins that require API 23 will only work with Cordova-Android 5.0
> > and up.  This only impacts five of our core plugins, but any plugin
> > that requires permissions from the Android Manifest will have to be
> > updated.  If we can avoid using advanced language tricks to make the
> APKs compatible, we should do that.
> >
> > When you mean they would not be compatible - will it result in a build
> > or
> > > runtime failure?
> > >
> > >
> > This will be a build failure, since API 22 does not have these
> > permissions, nor does it have the code required for API 23.
> >
> >
> > > For marshmallow, what is the guidance that we need to issue to the
> > > larger Cordova plugin ecosystem? Joe you are ahead of the curve here
> > > compared to most other plugin developers - a blot post explaining
> > > what are known gotchas would be great. I really hope we can use our
> > > Cordova blog to communicate these changes actively to the plugin
> ecosystem.
> > > This mailing list only gets 400+ subscribers.
> > >
> > >
> > There will be a blog post once 5.0 is released.  We're not forcing
> > people to upgrade to 5.0, and we will be supporting the 4.x branch for
> > six months.  This does mean we're stuck supporting 3.x, 4.x and 5.x
> > for a brief window, but I have no control over when Marshmallow is
> > released, only whether we want to support it or not.  I think we do, but
> I could be wrong.
> >
> > At least this should be easier than the jump from 3.x to 4.x for most
> > people, but the alternative is that your plugin just doesn't work at
> > all on Marshmallow.  We need to at least give plugin developers this
> > option, since it'll roll out on all the Nexus devices in the next two
> > weeks, and we'll hear more about it.
> >
> >
> > > Can you re-base your cordova-android over the current master? It's
> > > hard to see a diff in the current form:
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > hu
> > > b.com%2fapache%2fcordova-android%2fcompare%2fmaster...infil00p%3asmo
> > > re
> > > s&data=01%7c01%7cnikhilkh%40microsoft.com%7cb451a04dccc64fabdb9608d2
> > > c2
> > > edb23c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j0bxz39itXdtylHJ
> > > lv
> > > PYoJpZqXMhFjyTV35I9X5Yxzs%3d
> > >
> > >
> > I had to do a merge commit to get this to happen (boo), but it should
> > be mostly cleaned up now.  It seems some style cleanup creeped into
> > the most recent changes, but this should be a bit more readable.
> >
> >
> > > -Nikhil
> > >
> > > -----Original Message-----
> > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > Sent: Monday, September 21, 2015 2:14 PM
> > > To: dev <de...@cordova.apache.org>
> > > Subject: [Android] 5.0.x release branch?
> > >
> > > Hey
> > >
> > > In the next two weeks, Marshmallow will most likely getting released
> > > with the brand new Nexus 6P being released from Huawei.  Given that
> > > most of the Nexus devices will be getting this release, we should
> > > probably release the 5.0.x branch of Android soon, and get the new
> > plugins updated.
> > >
> > > It should be noted that the latest plugins will not be compatible
> > > with older versions of Cordova, which is a big deal.  This is due to
> > > the use of various compatibility checks to make sure they support
> > > Marshmallow and older versions of Android.
> > >
> > > So, if everyone can look over the smores branches of my GitHub
> > > before I create the 5.0.x branch and pull the changes into it, that
> > > would be
> > awesome.
> > >
> > >
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > hu
> > > b.com%2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cni
> > > kh
> > > ilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86
> > > f1
> > > 41af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%
> > > 2b
> > > ve4PVcCE%3d
> > >
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > hu
> > > b.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=0
> > > 1%
> > > 7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7
> > > c7
> > > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv
> > > 6p
> > > c5qbeY%2bdUxiP4bc%3d
> > >
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > hu
> > > b.com%2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c0
> > > 1%
> > > 7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f9
> > > 88
> > > bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCG
> > > Rb
> > > 4zWC8maWpE%3d
> > >
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > hu
> > > b.com%2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7
> > > c0
> > > 1%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72
> > > f9
> > > 88bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2
> > > fe
> > > EmqLOdU%2fwua2TbLU%3d
> > >
> > > Work on audio is still outstanding, BUT for some reason Audio broke
> > > recently on both Lollipop and Marshmallow.  I didn't test it out on
> > > KitKat or Jellybean yet, but I'm wondering whether we should keep
> > > maintaining this or support the standard HTML5 audio and deal with
> > > the asset issue somehow (which isn't straight forward).
> > >
> > > I hopefully want to get a 5.0.x branch happening this week if we can.
> > >
> > > What do people think?
> > >
> > > Joe
> > >
> >
>

RE: [Android] 5.0.x release branch?

Posted by Nikhil Khandelwal <ni...@microsoft.com>.

Merging threads. I was no aware of any security implications of using reflection - Perhaps if the reflection target can be controlled through external data. In any case, I understand your hesitation with use of reflection. I would love to have longer discussions on the F2F on what approaches we could use to make this easier for Cordova developers.

Joe: Could you add the appropriate engine tags in any case? That's how Cordova currently handles versioning between plugins & platforms. Also, does this imply that the plugins should have a major version bump as it is a breaking change? Please create the 5.x branches and if you could submit a PR - I had other minor code review comments on the diffs below.

Carlos: I understand in the extreme case it can be a fairly complicated implementation with lots of criteria to use to determine the ideal plugin that might work given a set of platforms. However, trying a couple of previous versions of the plugins might work 80% of the time and that might be good enough. This requires more thought as there are quite a few scenarios here.

As for plugin search website helping you find the correct engine tags - I like the idea. But this might requires us maintaining a backend for plugin search as this is specified in plugin.xml (and not package.json - or did we finally move this?). 

Thanks,
Nikhil

-----Original Message-----
From: Carlos Santana [mailto:csantana23@gmail.com] 
Sent: Tuesday, September 22, 2015 6:14 PM
To: dev@cordova.apache.org
Subject: Re: [Android] 5.0.x release branch?

+1 we should always use the engine tag to mark the minimum compatible 
+version at least

-1 for cordova CLI to automagically to install an older version. It will be a pain to get this implemented right, we would need to download all the package.json for multiple versions of the plugin and pick the lowest common denominator based on engine tags and remember that one plugin support multiple engine tags across different platform versions and CLI/plugman. 

This brings an interesting feature to implement In the plugin search website, to display the engine tags for a specific plugin version. Allowing a developer to search for a compatible plugin for their current app. 

- Carlos
Sent from my iPhone


-----Original Message-----
From: Joe Bowser [mailto:bowserj@gmail.com] 
Sent: Tuesday, September 22, 2015 6:17 PM
To: dev@cordova.apache.org
Subject: Re: [Android] 5.0.x release branch?

I'm completely against using reflection for this purpose.  Version codes were invented for a reason and we don't have any mechanism in place to unit test any Android code (or any other native code on any of the platforms).

I will vote against any release that includes reflection for this purpose since reflection has only brought us security issues and extreme WebView breakage when used (Simon can tell you the tales of the HTC console.log reflection code.).  Reflection is a worst-case scenario tool like when a method in WebView marked as deprecated completely disappears, not something we should make a habit of using often.  If we open the door for this, we'll get reflection creeping elsewhere, like the Plugins API.

Just say no to reflection.


On Tue, Sep 22, 2015, 5:57 PM Nikhil Khandelwal <ni...@microsoft.com>
wrote:

> Thanks, Joe for the detailed explanation. I understand why we've taken 
> this route. It's good that this is only a build failure. One of the 
> complaints we commonly hear from Cordova developers is that "I have a 
> cordova project with a certain version of the platform, I need to find 
> the plugin that will work with it". Our CLI always defaults to add the 
> latest released version of the plugin.
>
> After this breaking change, an existing cordova project with 
> cordova-android < 5.x, cannot build with the latest version of the 
> following plugins:
>                 - camera
>                - geolocation
>                - contacts.
> These are some of the most popular plugins in cordova plugin ecosystem [1].
>
> I propose that we should do our best to avoid disruptive breaking 
> changes here. Some ideas that come to mind:
> - As Joe mentioned below - reflection. It has the downsides that Joe 
> mentioned. No one likes to write code like this it but results in 
> least grief for Cordova users. Some pain here for plugin developers 
> will simplify the experience for large number of corodva JS 
> developers. I know we are doing some of this in cordova-ios [2] and 
> would love to find ways on how to make this manageable and not super ugly.
> - Add an  '<engine name="cordova-android" version=">=5.0.0" /> '  to 
> the plugins - failure happens at plugin add in this scenario. 
> Cordova-lib could be more intelligent to detect this error and resort 
> to using an older version of the plugin. The downside of this is that 
> these projects cannot use the latest and greatest of these plugins.
>
> Thanks,
> Nikhil
>
> [1] 
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordov
> a.apache.org%2fuse-the-force-luke%2fplugins%2f%3fsortBy%3dDownloads&da
> ta=01%7c01%7cnikhilkh%40microsoft.com%7c5d1a100510734c0605f508d2c3b4b9
> c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7apFzmhrtn%2bKulHrNn46
> kkRG%2bZp3KarDUTf2y0i7P5I%3d
> [2]
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> b.com%2fapache%2fcordova-plugin-camera%2fblob%2fmaster%2fsrc%2fios%2fC
> DVCamera.m%23L44&data=01%7c01%7cnikhilkh%40microsoft.com%7c5d1a1005107
> 34c0605f508d2c3b4b9c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CkH
> zeZ9uQUfYPDdAGlO2PJ9xJz89sZI5bdMRSlQtrMo%3d
>
> Thanks,
> Nikhil
>
>
> -----Original Message-----
> From: Joe Bowser [mailto:bowserj@gmail.com]
> Sent: Monday, September 21, 2015 6:32 PM
> To: dev@cordova.apache.org
> Subject: Re: [Android] 5.0.x release branch?
>
> On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal 
> <ni...@microsoft.com>
> wrote:
>
> > Can you explain why latest plugins will not be compatible with older 
> > versions of Cordova?
>
>
> They won't be compatible because Cordova-Android compiles against API 
> 22, and these plugins will require API 23 so that they can detect 
> permissions and support Marshmellow.
>
>
> > Can this be avoided by any means?
>
>
> Only with a lot of Java reflection, and I'd rather not subject plugin 
> developers to that, or try to hide it under the hood in some awful 
> utility class that everyone will want to see die.  I'm very much a fan 
> of if statements because they work, and they're easy to read and 
> debug, unlike when bad things happen to things you reflect into.  
> Plugins that require API 23 will only work with Cordova-Android 5.0 
> and up.  This only impacts five of our core plugins, but any plugin 
> that requires permissions from the Android Manifest will have to be 
> updated.  If we can avoid using advanced language tricks to make the APKs compatible, we should do that.
>
> When you mean they would not be compatible - will it result in a build 
> or
> > runtime failure?
> >
> >
> This will be a build failure, since API 22 does not have these 
> permissions, nor does it have the code required for API 23.
>
>
> > For marshmallow, what is the guidance that we need to issue to the 
> > larger Cordova plugin ecosystem? Joe you are ahead of the curve here 
> > compared to most other plugin developers - a blot post explaining 
> > what are known gotchas would be great. I really hope we can use our 
> > Cordova blog to communicate these changes actively to the plugin ecosystem.
> > This mailing list only gets 400+ subscribers.
> >
> >
> There will be a blog post once 5.0 is released.  We're not forcing 
> people to upgrade to 5.0, and we will be supporting the 4.x branch for 
> six months.  This does mean we're stuck supporting 3.x, 4.x and 5.x 
> for a brief window, but I have no control over when Marshmallow is 
> released, only whether we want to support it or not.  I think we do, but I could be wrong.
>
> At least this should be easier than the jump from 3.x to 4.x for most 
> people, but the alternative is that your plugin just doesn't work at 
> all on Marshmallow.  We need to at least give plugin developers this 
> option, since it'll roll out on all the Nexus devices in the next two 
> weeks, and we'll hear more about it.
>
>
> > Can you re-base your cordova-android over the current master? It's 
> > hard to see a diff in the current form:
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > hu 
> > b.com%2fapache%2fcordova-android%2fcompare%2fmaster...infil00p%3asmo
> > re
> > s&data=01%7c01%7cnikhilkh%40microsoft.com%7cb451a04dccc64fabdb9608d2
> > c2 
> > edb23c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j0bxz39itXdtylHJ
> > lv
> > PYoJpZqXMhFjyTV35I9X5Yxzs%3d
> >
> >
> I had to do a merge commit to get this to happen (boo), but it should 
> be mostly cleaned up now.  It seems some style cleanup creeped into 
> the most recent changes, but this should be a bit more readable.
>
>
> > -Nikhil
> >
> > -----Original Message-----
> > From: Joe Bowser [mailto:bowserj@gmail.com]
> > Sent: Monday, September 21, 2015 2:14 PM
> > To: dev <de...@cordova.apache.org>
> > Subject: [Android] 5.0.x release branch?
> >
> > Hey
> >
> > In the next two weeks, Marshmallow will most likely getting released 
> > with the brand new Nexus 6P being released from Huawei.  Given that 
> > most of the Nexus devices will be getting this release, we should 
> > probably release the 5.0.x branch of Android soon, and get the new
> plugins updated.
> >
> > It should be noted that the latest plugins will not be compatible 
> > with older versions of Cordova, which is a big deal.  This is due to 
> > the use of various compatibility checks to make sure they support 
> > Marshmallow and older versions of Android.
> >
> > So, if everyone can look over the smores branches of my GitHub 
> > before I create the 5.0.x branch and pull the changes into it, that 
> > would be
> awesome.
> >
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > hu 
> > b.com%2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cni
> > kh
> > ilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86
> > f1 
> > 41af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%
> > 2b
> > ve4PVcCE%3d
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > hu 
> > b.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=0
> > 1%
> > 7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7
> > c7 
> > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv
> > 6p
> > c5qbeY%2bdUxiP4bc%3d
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > hu 
> > b.com%2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c0
> > 1%
> > 7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f9
> > 88 
> > bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCG
> > Rb
> > 4zWC8maWpE%3d
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > hu
> > b.com%2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7
> > c0
> > 1%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72
> > f9 
> > 88bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2
> > fe
> > EmqLOdU%2fwua2TbLU%3d
> >
> > Work on audio is still outstanding, BUT for some reason Audio broke 
> > recently on both Lollipop and Marshmallow.  I didn't test it out on 
> > KitKat or Jellybean yet, but I'm wondering whether we should keep 
> > maintaining this or support the standard HTML5 audio and deal with 
> > the asset issue somehow (which isn't straight forward).
> >
> > I hopefully want to get a 5.0.x branch happening this week if we can.
> >
> > What do people think?
> >
> > Joe
> >
>

Re: [Android] 5.0.x release branch?

Posted by Joe Bowser <bo...@gmail.com>.

I'm completely against using reflection for this purpose.  Version codes
were invented for a reason and we don't have any mechanism in place to unit
test any Android code (or any other native code on any of the platforms).

I will vote against any release that includes reflection for this purpose
since reflection has only brought us security issues and extreme WebView
breakage when used (Simon can tell you the tales of the HTC console.log
reflection code.).  Reflection is a worst-case scenario tool like when a
method in WebView marked as deprecated completely disappears, not something
we should make a habit of using often.  If we open the door for this, we'll
get reflection creeping elsewhere, like the Plugins API.

Just say no to reflection.


On Tue, Sep 22, 2015, 5:57 PM Nikhil Khandelwal <ni...@microsoft.com>
wrote:

> Thanks, Joe for the detailed explanation. I understand why we've taken
> this route. It's good that this is only a build failure. One of the
> complaints we commonly hear from Cordova developers is that "I have a
> cordova project with a certain version of the platform, I need to find the
> plugin that will work with it". Our CLI always defaults to add the latest
> released version of the plugin.
>
> After this breaking change, an existing cordova project with
> cordova-android < 5.x, cannot build with the latest version of the
> following plugins:
>                 - camera
>                - geolocation
>                - contacts.
> These are some of the most popular plugins in cordova plugin ecosystem [1].
>
> I propose that we should do our best to avoid disruptive breaking changes
> here. Some ideas that come to mind:
> - As Joe mentioned below - reflection. It has the downsides that Joe
> mentioned. No one likes to write code like this it but results in least
> grief for Cordova users. Some pain here for plugin developers will simplify
> the experience for large number of corodva JS developers. I know we are
> doing some of this in cordova-ios [2] and would love to find ways on how to
> make this manageable and not super ugly.
> - Add an  '<engine name="cordova-android" version=">=5.0.0" /> '  to the
> plugins - failure happens at plugin add in this scenario. Cordova-lib could
> be more intelligent to detect this error and resort to using an older
> version of the plugin. The downside of this is that these projects cannot
> use the latest and greatest of these plugins.
>
> Thanks,
> Nikhil
>
> [1] http://cordova.apache.org/use-the-force-luke/plugins/?sortBy=Downloads
> [2]
> https://github.com/apache/cordova-plugin-camera/blob/master/src/ios/CDVCamera.m#L44
>
> Thanks,
> Nikhil
>
>
> -----Original Message-----
> From: Joe Bowser [mailto:bowserj@gmail.com]
> Sent: Monday, September 21, 2015 6:32 PM
> To: dev@cordova.apache.org
> Subject: Re: [Android] 5.0.x release branch?
>
> On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal <ni...@microsoft.com>
> wrote:
>
> > Can you explain why latest plugins will not be compatible with older
> > versions of Cordova?
>
>
> They won't be compatible because Cordova-Android compiles against API 22,
> and these plugins will require API 23 so that they can detect permissions
> and support Marshmellow.
>
>
> > Can this be avoided by any means?
>
>
> Only with a lot of Java reflection, and I'd rather not subject plugin
> developers to that, or try to hide it under the hood in some awful utility
> class that everyone will want to see die.  I'm very much a fan of if
> statements because they work, and they're easy to read and debug, unlike
> when bad things happen to things you reflect into.  Plugins that require
> API 23 will only work with Cordova-Android 5.0 and up.  This only impacts
> five of our core plugins, but any plugin that requires permissions from the
> Android Manifest will have to be updated.  If we can avoid using advanced
> language tricks to make the APKs compatible, we should do that.
>
> When you mean they would not be compatible - will it result in a build or
> > runtime failure?
> >
> >
> This will be a build failure, since API 22 does not have these
> permissions, nor does it have the code required for API 23.
>
>
> > For marshmallow, what is the guidance that we need to issue to the
> > larger Cordova plugin ecosystem? Joe you are ahead of the curve here
> > compared to most other plugin developers - a blot post explaining what
> > are known gotchas would be great. I really hope we can use our Cordova
> > blog to communicate these changes actively to the plugin ecosystem.
> > This mailing list only gets 400+ subscribers.
> >
> >
> There will be a blog post once 5.0 is released.  We're not forcing people
> to upgrade to 5.0, and we will be supporting the 4.x branch for six
> months.  This does mean we're stuck supporting 3.x, 4.x and 5.x for a brief
> window, but I have no control over when Marshmallow is released, only
> whether we want to support it or not.  I think we do, but I could be wrong.
>
> At least this should be easier than the jump from 3.x to 4.x for most
> people, but the alternative is that your plugin just doesn't work at all on
> Marshmallow.  We need to at least give plugin developers this option, since
> it'll roll out on all the Nexus devices in the next two weeks, and we'll
> hear more about it.
>
>
> > Can you re-base your cordova-android over the current master? It's
> > hard to see a diff in the current form:
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> > b.com%2fapache%2fcordova-android%2fcompare%2fmaster...infil00p%3asmore
> > s&data=01%7c01%7cnikhilkh%40microsoft.com%7cb451a04dccc64fabdb9608d2c2
> > edb23c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j0bxz39itXdtylHJlv
> > PYoJpZqXMhFjyTV35I9X5Yxzs%3d
> >
> >
> I had to do a merge commit to get this to happen (boo), but it should be
> mostly cleaned up now.  It seems some style cleanup creeped into the most
> recent changes, but this should be a bit more readable.
>
>
> > -Nikhil
> >
> > -----Original Message-----
> > From: Joe Bowser [mailto:bowserj@gmail.com]
> > Sent: Monday, September 21, 2015 2:14 PM
> > To: dev <de...@cordova.apache.org>
> > Subject: [Android] 5.0.x release branch?
> >
> > Hey
> >
> > In the next two weeks, Marshmallow will most likely getting released
> > with the brand new Nexus 6P being released from Huawei.  Given that
> > most of the Nexus devices will be getting this release, we should
> > probably release the 5.0.x branch of Android soon, and get the new
> plugins updated.
> >
> > It should be noted that the latest plugins will not be compatible with
> > older versions of Cordova, which is a big deal.  This is due to the
> > use of various compatibility checks to make sure they support
> > Marshmallow and older versions of Android.
> >
> > So, if everyone can look over the smores branches of my GitHub before
> > I create the 5.0.x branch and pull the changes into it, that would be
> awesome.
> >
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> > b.com%2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cnikh
> > ilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f1
> > 41af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%2b
> > ve4PVcCE%3d
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> > b.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=01%
> > 7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c7
> > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv6p
> > c5qbeY%2bdUxiP4bc%3d
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> > b.com%2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c01%
> > 7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988
> > bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCGRb
> > 4zWC8maWpE%3d
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> > b.com%2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7c0
> > 1%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f9
> > 88bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2fe
> > EmqLOdU%2fwua2TbLU%3d
> >
> > Work on audio is still outstanding, BUT for some reason Audio broke
> > recently on both Lollipop and Marshmallow.  I didn't test it out on
> > KitKat or Jellybean yet, but I'm wondering whether we should keep
> > maintaining this or support the standard HTML5 audio and deal with the
> > asset issue somehow (which isn't straight forward).
> >
> > I hopefully want to get a 5.0.x branch happening this week if we can.
> >
> > What do people think?
> >
> > Joe
> >
>

Re: [Android] 5.0.x release branch?

Posted by Carlos Santana <cs...@gmail.com>.

+1 we should always use the engine tag to mark the minimum compatible version at least 

-1 for cordova CLI to automagically to install an older version. It will be a pain to get this implemented right, we would need to download all the package.json for multiple versions of the plugin and pick the lowest common denominator based on engine tags and remember that one plugin support multiple engine tags across different platform versions and CLI/plugman. 

This brings an interesting feature to implement In the plugin search website, to display the engine tags for a specific plugin version. Allowing a developer to search for a compatible plugin for their current app. 

- Carlos
Sent from my iPhone

> On Sep 22, 2015, at 8:57 PM, Nikhil Khandelwal <ni...@microsoft.com> wrote:
> 
> Thanks, Joe for the detailed explanation. I understand why we've taken this route. It's good that this is only a build failure. One of the complaints we commonly hear from Cordova developers is that "I have a cordova project with a certain version of the platform, I need to find the plugin that will work with it". Our CLI always defaults to add the latest released version of the plugin.
> 
> After this breaking change, an existing cordova project with cordova-android < 5.x, cannot build with the latest version of the following plugins:
>                - camera
>               - geolocation
>               - contacts.
> These are some of the most popular plugins in cordova plugin ecosystem [1].
> 
> I propose that we should do our best to avoid disruptive breaking changes here. Some ideas that come to mind:
> - As Joe mentioned below - reflection. It has the downsides that Joe mentioned. No one likes to write code like this it but results in least grief for Cordova users. Some pain here for plugin developers will simplify the experience for large number of corodva JS developers. I know we are doing some of this in cordova-ios [2] and would love to find ways on how to make this manageable and not super ugly.
> - Add an  '<engine name="cordova-android" version=">=5.0.0" /> '  to the plugins - failure happens at plugin add in this scenario. Cordova-lib could be more intelligent to detect this error and resort to using an older version of the plugin. The downside of this is that these projects cannot use the latest and greatest of these plugins. 
> 
> Thanks,
> Nikhil
> 
> [1] http://cordova.apache.org/use-the-force-luke/plugins/?sortBy=Downloads
> [2] https://github.com/apache/cordova-plugin-camera/blob/master/src/ios/CDVCamera.m#L44
> 
> Thanks,
> Nikhil
> 
> 
> -----Original Message-----
> From: Joe Bowser [mailto:bowserj@gmail.com] 
> Sent: Monday, September 21, 2015 6:32 PM
> To: dev@cordova.apache.org
> Subject: Re: [Android] 5.0.x release branch?
> 
> On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal <ni...@microsoft.com>
> wrote:
> 
>> Can you explain why latest plugins will not be compatible with older 
>> versions of Cordova?
> 
> 
> They won't be compatible because Cordova-Android compiles against API 22, and these plugins will require API 23 so that they can detect permissions and support Marshmellow.
> 
> 
>> Can this be avoided by any means?
> 
> 
> Only with a lot of Java reflection, and I'd rather not subject plugin developers to that, or try to hide it under the hood in some awful utility class that everyone will want to see die.  I'm very much a fan of if statements because they work, and they're easy to read and debug, unlike when bad things happen to things you reflect into.  Plugins that require API 23 will only work with Cordova-Android 5.0 and up.  This only impacts five of our core plugins, but any plugin that requires permissions from the Android Manifest will have to be updated.  If we can avoid using advanced language tricks to make the APKs compatible, we should do that.
> 
> When you mean they would not be compatible - will it result in a build or
>> runtime failure?
>> 
>> 
> This will be a build failure, since API 22 does not have these permissions, nor does it have the code required for API 23.
> 
> 
>> For marshmallow, what is the guidance that we need to issue to the 
>> larger Cordova plugin ecosystem? Joe you are ahead of the curve here 
>> compared to most other plugin developers - a blot post explaining what 
>> are known gotchas would be great. I really hope we can use our Cordova 
>> blog to communicate these changes actively to the plugin ecosystem. 
>> This mailing list only gets 400+ subscribers.
>> 
>> 
> There will be a blog post once 5.0 is released.  We're not forcing people to upgrade to 5.0, and we will be supporting the 4.x branch for six months.  This does mean we're stuck supporting 3.x, 4.x and 5.x for a brief window, but I have no control over when Marshmallow is released, only whether we want to support it or not.  I think we do, but I could be wrong.
> 
> At least this should be easier than the jump from 3.x to 4.x for most people, but the alternative is that your plugin just doesn't work at all on Marshmallow.  We need to at least give plugin developers this option, since it'll roll out on all the Nexus devices in the next two weeks, and we'll hear more about it.
> 
> 
>> Can you re-base your cordova-android over the current master? It's 
>> hard to see a diff in the current form:
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
>> b.com%2fapache%2fcordova-android%2fcompare%2fmaster...infil00p%3asmore
>> s&data=01%7c01%7cnikhilkh%40microsoft.com%7cb451a04dccc64fabdb9608d2c2
>> edb23c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j0bxz39itXdtylHJlv
>> PYoJpZqXMhFjyTV35I9X5Yxzs%3d
>> 
>> 
> I had to do a merge commit to get this to happen (boo), but it should be mostly cleaned up now.  It seems some style cleanup creeped into the most recent changes, but this should be a bit more readable.
> 
> 
>> -Nikhil
>> 
>> -----Original Message-----
>> From: Joe Bowser [mailto:bowserj@gmail.com]
>> Sent: Monday, September 21, 2015 2:14 PM
>> To: dev <de...@cordova.apache.org>
>> Subject: [Android] 5.0.x release branch?
>> 
>> Hey
>> 
>> In the next two weeks, Marshmallow will most likely getting released 
>> with the brand new Nexus 6P being released from Huawei.  Given that 
>> most of the Nexus devices will be getting this release, we should 
>> probably release the 5.0.x branch of Android soon, and get the new plugins updated.
>> 
>> It should be noted that the latest plugins will not be compatible with 
>> older versions of Cordova, which is a big deal.  This is due to the 
>> use of various compatibility checks to make sure they support 
>> Marshmallow and older versions of Android.
>> 
>> So, if everyone can look over the smores branches of my GitHub before 
>> I create the 5.0.x branch and pull the changes into it, that would be awesome.
>> 
>> 
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
>> b.com%2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cnikh
>> ilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f1
>> 41af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%2b
>> ve4PVcCE%3d
>> 
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
>> b.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=01%
>> 7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c7
>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv6p
>> c5qbeY%2bdUxiP4bc%3d
>> 
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
>> b.com%2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c01%
>> 7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988
>> bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCGRb
>> 4zWC8maWpE%3d
>> 
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
>> b.com%2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7c0
>> 1%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f9
>> 88bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2fe
>> EmqLOdU%2fwua2TbLU%3d
>> 
>> Work on audio is still outstanding, BUT for some reason Audio broke 
>> recently on both Lollipop and Marshmallow.  I didn't test it out on 
>> KitKat or Jellybean yet, but I'm wondering whether we should keep 
>> maintaining this or support the standard HTML5 audio and deal with the 
>> asset issue somehow (which isn't straight forward).
>> 
>> I hopefully want to get a 5.0.x branch happening this week if we can.
>> 
>> What do people think?
>> 
>> Joe
>> 
> B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È[œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™PÛÜ™Ý˜K˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ËK[XZ[ˆ]‹Z[ÛÜ™Ý˜K˜\XÚK›Ü™ÃB

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org

RE: [Android] 5.0.x release branch?

Posted by Nikhil Khandelwal <ni...@microsoft.com>.

Thanks, Joe for the detailed explanation. I understand why we've taken this route. It's good that this is only a build failure. One of the complaints we commonly hear from Cordova developers is that "I have a cordova project with a certain version of the platform, I need to find the plugin that will work with it". Our CLI always defaults to add the latest released version of the plugin.

After this breaking change, an existing cordova project with cordova-android < 5.x, cannot build with the latest version of the following plugins:
                - camera
               - geolocation
               - contacts.
These are some of the most popular plugins in cordova plugin ecosystem [1].

I propose that we should do our best to avoid disruptive breaking changes here. Some ideas that come to mind:
- As Joe mentioned below - reflection. It has the downsides that Joe mentioned. No one likes to write code like this it but results in least grief for Cordova users. Some pain here for plugin developers will simplify the experience for large number of corodva JS developers. I know we are doing some of this in cordova-ios [2] and would love to find ways on how to make this manageable and not super ugly.
- Add an  '<engine name="cordova-android" version=">=5.0.0" /> '  to the plugins - failure happens at plugin add in this scenario. Cordova-lib could be more intelligent to detect this error and resort to using an older version of the plugin. The downside of this is that these projects cannot use the latest and greatest of these plugins. 

Thanks,
Nikhil

[1] http://cordova.apache.org/use-the-force-luke/plugins/?sortBy=Downloads
[2] https://github.com/apache/cordova-plugin-camera/blob/master/src/ios/CDVCamera.m#L44

Thanks,
Nikhil


-----Original Message-----
From: Joe Bowser [mailto:bowserj@gmail.com] 
Sent: Monday, September 21, 2015 6:32 PM
To: dev@cordova.apache.org
Subject: Re: [Android] 5.0.x release branch?

On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal <ni...@microsoft.com>
wrote:

> Can you explain why latest plugins will not be compatible with older 
> versions of Cordova?


They won't be compatible because Cordova-Android compiles against API 22, and these plugins will require API 23 so that they can detect permissions and support Marshmellow.


> Can this be avoided by any means?


Only with a lot of Java reflection, and I'd rather not subject plugin developers to that, or try to hide it under the hood in some awful utility class that everyone will want to see die.  I'm very much a fan of if statements because they work, and they're easy to read and debug, unlike when bad things happen to things you reflect into.  Plugins that require API 23 will only work with Cordova-Android 5.0 and up.  This only impacts five of our core plugins, but any plugin that requires permissions from the Android Manifest will have to be updated.  If we can avoid using advanced language tricks to make the APKs compatible, we should do that.

When you mean they would not be compatible - will it result in a build or
> runtime failure?
>
>
This will be a build failure, since API 22 does not have these permissions, nor does it have the code required for API 23.


> For marshmallow, what is the guidance that we need to issue to the 
> larger Cordova plugin ecosystem? Joe you are ahead of the curve here 
> compared to most other plugin developers - a blot post explaining what 
> are known gotchas would be great. I really hope we can use our Cordova 
> blog to communicate these changes actively to the plugin ecosystem. 
> This mailing list only gets 400+ subscribers.
>
>
There will be a blog post once 5.0 is released.  We're not forcing people to upgrade to 5.0, and we will be supporting the 4.x branch for six months.  This does mean we're stuck supporting 3.x, 4.x and 5.x for a brief window, but I have no control over when Marshmallow is released, only whether we want to support it or not.  I think we do, but I could be wrong.

At least this should be easier than the jump from 3.x to 4.x for most people, but the alternative is that your plugin just doesn't work at all on Marshmallow.  We need to at least give plugin developers this option, since it'll roll out on all the Nexus devices in the next two weeks, and we'll hear more about it.


> Can you re-base your cordova-android over the current master? It's 
> hard to see a diff in the current form:
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> b.com%2fapache%2fcordova-android%2fcompare%2fmaster...infil00p%3asmore
> s&data=01%7c01%7cnikhilkh%40microsoft.com%7cb451a04dccc64fabdb9608d2c2
> edb23c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j0bxz39itXdtylHJlv
> PYoJpZqXMhFjyTV35I9X5Yxzs%3d
>
>
I had to do a merge commit to get this to happen (boo), but it should be mostly cleaned up now.  It seems some style cleanup creeped into the most recent changes, but this should be a bit more readable.


> -Nikhil
>
> -----Original Message-----
> From: Joe Bowser [mailto:bowserj@gmail.com]
> Sent: Monday, September 21, 2015 2:14 PM
> To: dev <de...@cordova.apache.org>
> Subject: [Android] 5.0.x release branch?
>
> Hey
>
> In the next two weeks, Marshmallow will most likely getting released 
> with the brand new Nexus 6P being released from Huawei.  Given that 
> most of the Nexus devices will be getting this release, we should 
> probably release the 5.0.x branch of Android soon, and get the new plugins updated.
>
> It should be noted that the latest plugins will not be compatible with 
> older versions of Cordova, which is a big deal.  This is due to the 
> use of various compatibility checks to make sure they support 
> Marshmallow and older versions of Android.
>
> So, if everyone can look over the smores branches of my GitHub before 
> I create the 5.0.x branch and pull the changes into it, that would be awesome.
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> b.com%2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cnikh
> ilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f1
> 41af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%2b
> ve4PVcCE%3d
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> b.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=01%
> 7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c7
> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv6p
> c5qbeY%2bdUxiP4bc%3d
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> b.com%2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c01%
> 7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988
> bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCGRb
> 4zWC8maWpE%3d
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> b.com%2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7c0
> 1%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f9
> 88bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2fe
> EmqLOdU%2fwua2TbLU%3d
>
> Work on audio is still outstanding, BUT for some reason Audio broke 
> recently on both Lollipop and Marshmallow.  I didn't test it out on 
> KitKat or Jellybean yet, but I'm wondering whether we should keep 
> maintaining this or support the standard HTML5 audio and deal with the 
> asset issue somehow (which isn't straight forward).
>
> I hopefully want to get a 5.0.x branch happening this week if we can.
>
> What do people think?
>
> Joe
>

Re: [Android] 5.0.x release branch?

Posted by Joe Bowser <bo...@gmail.com>.

On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal <ni...@microsoft.com>
wrote:

> Can you explain why latest plugins will not be compatible with older
> versions of Cordova?


They won't be compatible because Cordova-Android compiles against API 22,
and these plugins will require API 23 so that they can detect permissions
and support Marshmellow.


> Can this be avoided by any means?


Only with a lot of Java reflection, and I'd rather not subject plugin
developers to that, or try to hide it under the hood in some awful utility
class that everyone will want to see die.  I'm very much a fan of if
statements because they work, and they're easy to read and debug, unlike
when bad things happen to things you reflect into.  Plugins that require
API 23 will only work with Cordova-Android 5.0 and up.  This only impacts
five of our core plugins, but any plugin that requires permissions from the
Android Manifest will have to be updated.  If we can avoid using advanced
language tricks to make the APKs compatible, we should do that.

When you mean they would not be compatible - will it result in a build or
> runtime failure?
>
>
This will be a build failure, since API 22 does not have these permissions,
nor does it have the code required for API 23.


> For marshmallow, what is the guidance that we need to issue to the larger
> Cordova plugin ecosystem? Joe you are ahead of the curve here compared to
> most other plugin developers - a blot post explaining what are known
> gotchas would be great. I really hope we can use our Cordova blog to
> communicate these changes actively to the plugin ecosystem. This mailing
> list only gets 400+ subscribers.
>
>
There will be a blog post once 5.0 is released.  We're not forcing people
to upgrade to 5.0, and we will be supporting the 4.x branch for six
months.  This does mean we're stuck supporting 3.x, 4.x and 5.x for a brief
window, but I have no control over when Marshmallow is released, only
whether we want to support it or not.  I think we do, but I could be wrong.

At least this should be easier than the jump from 3.x to 4.x for most
people, but the alternative is that your plugin just doesn't work at all on
Marshmallow.  We need to at least give plugin developers this option, since
it'll roll out on all the Nexus devices in the next two weeks, and we'll
hear more about it.


> Can you re-base your cordova-android over the current master? It's hard to
> see a diff in the current form:
> https://github.com/apache/cordova-android/compare/master...infil00p:smores
>
>
I had to do a merge commit to get this to happen (boo), but it should be
mostly cleaned up now.  It seems some style cleanup creeped into the most
recent changes, but this should be a bit more readable.


> -Nikhil
>
> -----Original Message-----
> From: Joe Bowser [mailto:bowserj@gmail.com]
> Sent: Monday, September 21, 2015 2:14 PM
> To: dev <de...@cordova.apache.org>
> Subject: [Android] 5.0.x release branch?
>
> Hey
>
> In the next two weeks, Marshmallow will most likely getting released with
> the brand new Nexus 6P being released from Huawei.  Given that most of the
> Nexus devices will be getting this release, we should probably release the
> 5.0.x branch of Android soon, and get the new plugins updated.
>
> It should be noted that the latest plugins will not be compatible with
> older versions of Cordova, which is a big deal.  This is due to the use of
> various compatibility checks to make sure they support Marshmallow and
> older versions of Android.
>
> So, if everyone can look over the smores branches of my GitHub before I
> create the 5.0.x branch and pull the changes into it, that would be awesome.
>
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%2bve4PVcCE%3d
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv6pc5qbeY%2bdUxiP4bc%3d
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCGRb4zWC8maWpE%3d
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2feEmqLOdU%2fwua2TbLU%3d
>
> Work on audio is still outstanding, BUT for some reason Audio broke
> recently on both Lollipop and Marshmallow.  I didn't test it out on KitKat
> or Jellybean yet, but I'm wondering whether we should keep maintaining this
> or support the standard HTML5 audio and deal with the asset issue somehow
> (which isn't straight forward).
>
> I hopefully want to get a 5.0.x branch happening this week if we can.
>
> What do people think?
>
> Joe
>

RE: [Android] 5.0.x release branch?

Posted by Nikhil Khandelwal <ni...@microsoft.com>.

Can you explain why latest plugins will not be compatible with older versions of Cordova? Can this be avoided by any means? When you mean they would not be compatible - will it result in a build or runtime failure?

For marshmallow, what is the guidance that we need to issue to the larger Cordova plugin ecosystem? Joe you are ahead of the curve here compared to most other plugin developers - a blot post explaining what are known gotchas would be great. I really hope we can use our Cordova blog to communicate these changes actively to the plugin ecosystem. This mailing list only gets 400+ subscribers.

Can you re-base your cordova-android over the current master? It's hard to see a diff in the current form:
https://github.com/apache/cordova-android/compare/master...infil00p:smores

-Nikhil

-----Original Message-----
From: Joe Bowser [mailto:bowserj@gmail.com] 
Sent: Monday, September 21, 2015 2:14 PM
To: dev <de...@cordova.apache.org>
Subject: [Android] 5.0.x release branch?

Hey

In the next two weeks, Marshmallow will most likely getting released with the brand new Nexus 6P being released from Huawei.  Given that most of the Nexus devices will be getting this release, we should probably release the 5.0.x branch of Android soon, and get the new plugins updated.

It should be noted that the latest plugins will not be compatible with older versions of Cordova, which is a big deal.  This is due to the use of various compatibility checks to make sure they support Marshmallow and older versions of Android.

So, if everyone can look over the smores branches of my GitHub before I create the 5.0.x branch and pull the changes into it, that would be awesome.

https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%2bve4PVcCE%3d
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv6pc5qbeY%2bdUxiP4bc%3d
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCGRb4zWC8maWpE%3d
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2feEmqLOdU%2fwua2TbLU%3d

Work on audio is still outstanding, BUT for some reason Audio broke recently on both Lollipop and Marshmallow.  I didn't test it out on KitKat or Jellybean yet, but I'm wondering whether we should keep maintaining this or support the standard HTML5 audio and deal with the asset issue somehow (which isn't straight forward).

I hopefully want to get a 5.0.x branch happening this week if we can.

What do people think?

Joe