Continuing on Simon's point, we already have duplication of entries for preference tags in https://issues.apache.org/jira/browse/CB-9264 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 <[email protected]> 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 > 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] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
