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 Tue, 22 Mar 2016 14:02:19 GMT
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
> > > >>
> > >
> > >
> >
>

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