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 12:28:50 GMT
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