cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: [Android] 5.0.x release branch?
Date Wed, 23 Sep 2015 21:19:21 GMT
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 <bowserj@gmail.com>:
>
> > On Wed, Sep 23, 2015 at 11:30 AM, Joe Bowser <bowserj@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" <bowserj@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
> > >> >><nikhilkh@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
> > >> >> > > <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://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 <dev@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/>
>

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