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
http://hi.im/simonmacdonald
On Mon, Mar 21, 2016 at 4:52 PM, Richard Knoll <[email protected]>
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:[email protected]]
> Sent: Monday, March 21, 2016 1:39 PM
> To: [email protected]
> 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" <[email protected]> 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 <[email protected]>:
> >
> > > 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:[email protected]]
> > > Sent: Monday, March 21, 2016 10:07 AM
> > > To: dev <[email protected]>
> > > 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: [email protected]
> For additional commands, e-mail: [email protected]
>
