cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon MacDonald <simon.macdon...@gmail.com>
Subject Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests
Date Wed, 23 Mar 2016 15:30:18 GMT
Seems like editing attributes in a config-file is a wanted enhancement. Do
we have a JIRA for it?


Simon Mac Donald
http://hi.im/simonmacdonald

On Tue, Mar 22, 2016 at 5:09 PM, Carlos Santana <csantana23@gmail.com>
wrote:

> I agree to enable config.xml to be able to set or override using
> config-file (i.e. any xml file including strings.xml)
> I also think that adding support in config.xml and plugin.xml to edit
> attributes is very helpful, this is exactly what we are doing for one of
> our plugin to add the attribute android:name for <application> and it was a
> pain, and I think we still have problems doing it from
> before_plugin_install hook, it would be easier from plugin.xml
>
>
>
> On Tue, Mar 22, 2016 at 10:55 AM julio cesar sanchez <
> jcesarmobile@gmail.com>
> wrote:
>
> > Yes, Simon, that's my opinion, and we should show the conficting values
> and
> > the id of the plugin with the conficting values so the user knows he has
> to
> > change the values on the config.xml or remove the plugin.
> >
> > But we still will have problems if the plugin uses a hook to write values
> > instead of using the config-file tag
> >
> > 2016-03-22 15:11 GMT+01:00 Alexis Kofman <alexis.kofman@gmail.com>:
> >
> > > Maybe the configured values of the plugins are sometimes just default
> > > values that the user can override through the config.xml file.
> > > What about adding a flag indicating whether the value is overridable ?
> > My 2
> > > cents ...
> > >
> > > On Tue, Mar 22, 2016 at 3:02 PM, Simon MacDonald <
> > > simon.macdonald@gmail.com>
> > > wrote:
> > >
> > > > So for Android's case you are thinking the order of precedence should
> > be:
> > > >
> > > > config.xml
> > > > plugin.xml
> > > > AndroidManifest.xml // created by the "cordova" cli
> > > >
> > > > Then if config.xml overrides something that one of the plugins
> depends
> > on
> > > > then the app won't build. I can actually get behind that proposal if
> > I'm
> > > > understanding you correctly.
> > > >
> > > >
> > > > Simon Mac Donald
> > > > http://hi.im/simonmacdonald
> > > >
> > > > On Tue, Mar 22, 2016 at 9:51 AM, julio cesar sanchez <
> > > > jcesarmobile@gmail.com
> > > > > wrote:
> > > >
> > > > > I think, if there is a conflict between config.xml and plugin.xml
> we
> > > > should
> > > > > not build.
> > > > >
> > > > > If we pick config.xml values, the plugins with conflicting values
> > might
> > > > not
> > > > > work, and if we pick the plugin.xml values, the app might not work
> > the
> > > > way
> > > > > the user wants.
> > > > >
> > > > > I think both options are bad, the user wants the plugin to work and
> > to
> > > > get
> > > > > the values he manually added and both aren't possible if there are
> > > > > conflicts.
> > > > >
> > > > >
> > > > > 2016-03-22 13:28 GMT+01:00 Simon MacDonald <
> > simon.macdonald@gmail.com
> > > >:
> > > > >
> > > > > > When it comes to the AndroidManifest if config.xml and plugin.xml
> > > > > (possibly
> > > > > > multiple plugin.xml's) disagree on the value of an attribute:
> > > > > >
> > > > > > - if the value is a boolean then it should default to 'false'.
> For
> > > > > instance
> > > > > > if it is an attribute like supports small screens if one plugin
> > sets
> > > it
> > > > > to
> > > > > > false it should be false for or else the app may not build.
> > > > > > - if the value is a integer then it should default to the highest
> > > > integer
> > > > > > provided. For instance minimum SDK version, again have to pick
> the
> > > > > highest
> > > > > > or the app won't build.
> > > > > > - if the value is a string, damned if I know if there are
> conflicts
> > > in
> > > > > > multiple plugin.xml files but plugin.xml should take precedence
> > over
> > > > > > config.xml.
> > > > > >
> > > > > > Sound reasonable?
> > > > > >
> > > > > >
> > > > > > Simon Mac Donald
> > > > > > http://hi.im/simonmacdonald
> > > > > >
> > > > > > On Tue, Mar 22, 2016 at 3:27 AM, Parashuram N <
> > > panarasi@microsoft.com>
> > > > > > wrote:
> > > > > >
> > > > > > > The disagreement could also like in a “preference”
specifying a
> > > > value,
> > > > > > > that is overwritten by this fragment.
> > > > > > >
> > > > > > > On 3/21/16, 11:28 PM, "Jesse" <purplecabbage@gmail.com>
wrote:
> > > > > > >
> > > > > > > >I like having the same xml fragments in config.xml
as we use
> in
> > > > > > plugin.xml
> > > > > > > >
> > > > > > > ><platform name="android">
> > > > > > > >    <config-file target="AndroidManifest.xml"
> > > > > > > >parent="/manifest/application">
> > > > > > > >        <activity android:name="
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=com.foo.Foo&data=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MPgaRi3qGueHAnmnV6tXJyRlIzQIu6gHxeYTnpiKR9c%3d
> > > > > > > "
> > > > > > > >android:label="@string/app_name">
> > > > > > > >            <intent-filter>
> > > > > > > >            </intent-filter>
> > > > > > > >        </activity>
> > > > > > > >    </config-file>
> > > > > > > ></platform>
> > > > > > > >
> > > > > > > >We will need to address precedence, as a plugin.xml
and
> > config.xml
> > > > can
> > > > > > > >disagree.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >> On Mar 21, 2016, at 12:46 PM, Shazron <shazron@gmail.com>
> > > wrote:
> > > > > > > >>
> > > > > > > >> Continuing on Simon's point, we already have duplication
of
> > > > entries
> > > > > > > >> for preference tags in
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-9264&data=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Amj46nGpbpE3scp6sjDw1FemeGton2Hu6YSyQqZNT4M%3d
> > > > > > > >> and a post-processing step does the removal of
dupes. Not
> sure
> > > if
> > > > > this
> > > > > > > >> removal method would be adequate (as long as the
desired tag
> > to
> > > > > > > >> express is written to the config file *last*)
> > > > > > > >>
> > > > > > > >> On Mon, Mar 21, 2016 at 3:41 PM, Simon MacDonald
> > > > > > > >> <simon.macdonald@gmail.com> wrote:
> > > > > > > >>> I agree the config-file is the way to go but
we need to go
> > one
> > > > step
> > > > > > > more
> > > > > > > >>> and enable the changing of attributes in the
config file
> > > instead
> > > > of
> > > > > > > just
> > > > > > > >>> adding lines to AndroidManifest.xml. For instance,
the
> first
> > > bug
> > > > > > > CB-10894
> > > > > > > >>> talks about adding a preference for screen
sizes.
> > > > > > > >>>
> > > > > > > >>> The default AndroidManifest.xml that is created
with
> Cordova
> > > > > Android
> > > > > > > will
> > > > > > > >>> add the line:
> > > > > > > >>>
> > > > > > > >>>    <supports-screens android:anyDensity="true"
> > > > > > > >android:largeScreens="true"
> > > > > > > >>> android:normalScreens="true" android:resizeable="true"
> > > > > > > >>> android:smallScreens="true" android:xlargeScreens="true"
/>
> > > > > > > >>>
> > > > > > > >>> and if you want to make smallScreens="false"
you have no
> way
> > of
> > > > > doing
> > > > > > > it
> > > > > > > >as
> > > > > > > >>> it adds a duplicate line if you are using
the config-file
> way
> > > of
> > > > > > doing
> > > > > > > >>> things. We really need attribute level granularity
in the
> > > > > config-file
> > > > > > > >tag.
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>> Simon Mac Donald
> > > > > > > >>>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi.im%2fsimonmacdonald&data=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fTHN2714ZxbZ7blck0JpCvz2U%2fLEFSzVDQP2mTLSMm8%3d
> > > > > > > >>>
> > > > > > > >>> On Mon, Mar 21, 2016 at 4:52 PM, Richard Knoll
<
> > > > > > riknoll@microsoft.com>
> > > > > > > >>> wrote:
> > > > > > > >>>
> > > > > > > >>>> I agree that config-file is the way to
go. After an
> offline
> > > > > > discussion
> > > > > > > >>>> with Nikhil, Parashu, and Jason, one question
that came up
> > was
> > > > > > whether
> > > > > > > >all
> > > > > > > >>>> of this native config stuff belongs in
config.xml or
> should
> > be
> > > > > > > separated
> > > > > > > >>>> out. One idea would be to define separate
files for each
> > > > > > configuration
> > > > > > > >file
> > > > > > > >>>> you wish to modify (something like
> > AndroidManifest.merge.xml).
> > > > > Those
> > > > > > > >files
> > > > > > > >>>> would follow the same format as the config-file
tag and
> you
> > > > could
> > > > > > add
> > > > > > > >>>> entries to build.json or config.xml specifying
what native
> > > > config
> > > > > > each
> > > > > > > >file
> > > > > > > >>>> modifies. It breaks from how we do it
in plugin.xml, but
> it
> > > > > prevents
> > > > > > > >having
> > > > > > > >>>> gigantic config.xml files that are mostly
composed of
> native
> > > > > > > fragments.
> > > > > > > >The
> > > > > > > >>>> current config file mixing that we do
is somewhat messy.
> > > > > > > >>>> Thoughts?
> > > > > > > >>>>
> > > > > > > >>>> Richard
> > > > > > > >>>>
> > > > > > > >>>> -----Original Message-----
> > > > > > > >>>> From: Alexis Kofman [mailto:alexis.kofman@gmail.com]
> > > > > > > >>>> Sent: Monday, March 21, 2016 1:39 PM
> > > > > > > >>>> To: dev@cordova.apache.org
> > > > > > > >>>> Subject: Re: [Android] Need a solution
to config.xml and
> > > > > > > >>>> AndroidManifest.xml feature requests
> > > > > > > >>>>
> > > > > > > >>>> Hello all,
> > > > > > > >>>>
> > > > > > > >>>> I agree with Julio that it is less confusing
 keeping the
> > same
> > > > > > > mecanism
> > > > > > > >>>> that the one it already exists with the
plugin.xml.
> > > > > > > >>>> Le 21 mars 2016 19:17, "julio cesar sanchez"
<
> > > > > > jcesarmobile@gmail.com>
> > > > > > > a
> > > > > > > >>>> écrit :
> > > > > > > >>>>
> > > > > > > >>>>> I think we should add the config-file
tag to the
> > config.xml.
> > > > > > > >>>>> It's already implemented on the plugin.xml.
It allows you
> > to
> > > > > modify
> > > > > > > >>>>> the AndroidManifest.xml or the info.plist
when you
> install
> > a
> > > > > > plugin.
> > > > > > > >>>>> But the number of plugins that just
modify the
> > > > > AndroidManifest.xml
> > > > > > or
> > > > > > > >>>>> info.plist is increasing, I think
that should be on the
> > > > > config.xml
> > > > > > > too.
> > > > > > > >>>>>
> > > > > > > >>>>> So we don't duplicate anything with
our own tags, we just
> > let
> > > > > them
> > > > > > > add
> > > > > > > >>>>> whatever they want from the config-file
tag.
> > > > > > > >>>>> And if something can't be edited from
the config-file
> tag,
> > we
> > > > > tell
> > > > > > > >>>>> them to create a hook.
> > > > > > > >>>>>
> > > > > > > >>>>> Phonegap build uses the config-file
tag on the config.xml
> > to
> > > > > allow
> > > > > > > >>>>> their users to edit the AndroidManifest.xml
and the
> > > info.plist
> > > > > > > >>>>>
> > > > > > > >>>>> @Parashuram idea might work on android,
but I think we
> > should
> > > > > have
> > > > > > > >>>>> something that can be used on all
the platforms
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>> 2016-03-21 18:40 GMT+01:00 Parashuram
N <
> > > > panarasi@microsoft.com
> > > > > >:
> > > > > > > >>>>>
> > > > > > > >>>>>> Given that we are now using Gradle
for builds, could
> these
> > > > > simply
> > > > > > be
> > > > > > > >>>>>> gradle sub-projects that define
an AndroidManifest.xml,
> > that
> > > > > gets
> > > > > > > >>>>>> merged during Android build ?
One way could be to
> support
> > > > > > specifying
> > > > > > > >>>>>> "sub-projects" in config.xml,
and these changes get
> picked
> > > up.
> > > > > > Would
> > > > > > > >>>>>> it work for all cases ?
> > > > > > > >>>>>>
> > > > > > > >>>>>> -----Original Message-----
> > > > > > > >>>>>> From: Joe Bowser [mailto:bowserj@gmail.com]
> > > > > > > >>>>>> Sent: Monday, March 21, 2016 10:07
AM
> > > > > > > >>>>>> To: dev <dev@cordova.apache.org>
> > > > > > > >>>>>> Subject: [Android] Need a solution
to config.xml and
> > > > > > > >>>>>> AndroidManifest.xml feature requests
> > > > > > > >>>>>>
> > > > > > > >>>>>> Hey
> > > > > > > >>>>>>
> > > > > > > >>>>>> So, if you've been paying attention
to the JIRA, we've
> > been
> > > > > > getting
> > > > > > > >>>>>> slammed with a ton of feature
requests/bugs regarding
> the
> > > > > Android
> > > > > > > >>>>> Manifest
> > > > > > > >>>>>> where people want to add a 1:1
mapping between the two
> XML
> > > > > files.
> > > > > > > >>>>>>
> > > > > > > >>>>>> The thing is that it's getting
out of control, and we
> need
> > > to
> > > > > > find a
> > > > > > > >>>>>> better solution to this problem.
 I'm not sure what a
> > better
> > > > > > > >>>>>> solution to this is, but if you
want to see some of the
> > > issues
> > > > > > that
> > > > > > > >>>>>> are related to this, here's a
small list:
> > > > > > > >>>>>
> > > > > > >
> > > >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > > > > > > >>>>> s.apache.org
> > > > > > > %2fjira%2fbrowse%2fCB-10894&data=01%7c01%7cpanarasi%40micr
> > > > > > > >>>>> osoft.com
> > > > > > > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
> > > > > > > >>>>>
> > > > > > >
> > > >
> cd011db47%7c1&sdata=f3qD84Rx%2bc%2bDzryeeXDCIX%2bhrCk%2boM%2f26%2fT5OA
> > > > > > > >>>>> y9RMA%3d
> > > > > > > >>>>>
> > > > > > >
> > > >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > > > > > > >>>>> s.apache.org
> > > > > > > %2fjira%2fbrowse%2fCB-10917&data=01%7c01%7cpanarasi%40micr
> > > > > > > >>>>> osoft.com
> > > > > > > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
> > > > > > > >>>>>
> > > > > > >
> > > >
> cd011db47%7c1&sdata=I1ycCL25rWlN4uTU%2fPXFBkv1PYXrDeX6dF6%2fMzyNSbE%3d
> > > > > > > >>>>>
> > > > > > >
> > > >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > > > > > > >>>>> s.apache.org
> > > > > > > %2fjira%2fbrowse%2fCB-8159&data=01%7c01%7cpanarasi%40micro
> > > > > > > >>>>> soft.com
> > > > > > > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7c
> > > > > > > >>>>>
> > > > > >
> > d011db47%7c1&sdata=HS3ZRL%2fxY%2fJWZo5eMQPGFO6BS2W03z13va8NV7sZpjo%3d
> > > > > > > >>>>>
> > > > > > >
> > > >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > > > > > > >>>>> s.apache.org
> > > > > > > %2fjira%2fbrowse%2fCB-10755&data=01%7c01%7cpanarasi%40micr
> > > > > > > >>>>> osoft.com
> > > > > > > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
> > > > > > > >>>>>
> > > > > >
> > cd011db47%7c1&sdata=PeZms4TWbWqHInf%2fnYYbL3e5o9aB3Ijcl8fQxoUmsgU%3d
> > > > > > > >>>>>
> > > > > > >
> > > >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > > > > > > >>>>> s.apache.org
> > > > > > > %2fjira%2fbrowse%2fCB-8976&data=01%7c01%7cpanarasi%40micro
> > > > > > > >>>>> soft.com
> > > > > > > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7c
> > > > > > > >>>>>
> > > > d011db47%7c1&sdata=4VoysIEst8o7k3kvkyYu9MeBDF8VZ3q7aG6oLcoCN2w%3d
> > > > > > > >>>>>>
> > > > > > > >>>>>> All of these are either indirectly
or directly related
> to
> > > the
> > > > > > > >>>>>> AndroidManifest, and it's clear
that if we just allowed
> > > people
> > > > > to
> > > > > > > >>>>>> edit an AndroidManifest, or at
least allow portions of
> it
> > to
> > > > be
> > > > > > > >>>>>> immutable, we
> > > > > > > >>>>> would
> > > > > > > >>>>>> be better off.  Obviously, plugins
that install
> > third-party
> > > > > > > >>>>>> activities
> > > > > > > >>>>> and
> > > > > > > >>>>>> content providers would have to
edit the manifest, but I
> > > think
> > > > > > that
> > > > > > > >>>>> things
> > > > > > > >>>>>> are getting out of hand with the
things that people want
> > to
> > > > > > control
> > > > > > > >>>>>> from config.xml.
> > > > > > > >>>>>>
> > > > > > > >>>>>> What do people think? Does anyone
have a good solution
> to
> > > this
> > > > > > > >problem?
> > > > > > > >>>>>> Are we really abstracting anything
out by duplicating
> the
> > > same
> > > > > > > >>>>>> config in our own config.xml?
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > > >>>> To unsubscribe, e-mail:
> dev-unsubscribe@cordova.apache.org
> > > > > > > >>>> For additional commands, e-mail:
> > dev-help@cordova.apache.org
> > > > > > > >>
> > > > > > > >>
> > > > >
> ---------------------------------------------------------------------
> > > > > > > >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > > > >> For additional commands, e-mail:
> dev-help@cordova.apache.org
> > > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Alexis Kofman
> > >
> >
>

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