android: [Proposal] List of version 4.0 (breaking?) changes
-
<nsProject>/app/App_Resources/to move one directory up -><nsProject>/App_Resources- this will be ‘opt-in’ through a configuration file, and users would not be forced to migrate their App_Resources location should they not need or want it. - enabled through a configuration file where users can specify the path to the application resources directory (https://github.com/NativeScript/nativescript-cli/pull/3329) -
App_Resources/Androidto move all its files into the resources directory of a sourceset (main/src/res) - this will also be ‘opt-in’ through a CLI command. Users who want to take advantage of the updated App_Resources/Android subdirectory structure will be able to do so when using CLI 4.0 and the Android Runtime 4.0. - enabled through a command in the nativescript-cli (https://github.com/NativeScript/nativescript-cli/pull/3347)
'--App_Resources/Android/main/assets (will allow users to include their own resources outside the javascript sources directory, which do not necessarily fall under the 'resources' category)
'--App_Resources/Android/main/java (will allow user-editable java sources to be added with no extra work)
'--App_Resources/Android/main/res (will hold all user-defined resources, icons and styles)
'--App_Resources/Android/main/res/values/
'--App_Resources/Android/main/res/drawable-hdpi/
'--App_Resources/Android/main/AndroidManifest.xml
'--App_Resources/Android/app.gradle
The changes above will allow users to customize their Android builds a lot more easily, without having to rely on before/after prepare hooks to replace code and files - see https://github.com/NativeScript/android-runtime/issues/700
- Remove flavors (F0, F1, Fx) from Android builds as a mechanism to work with plugins - this implies changes in the agreed-upon Android Nativescript plugin structure - it will no longer be allowed to just drop
AndroidManifest.xmland/orres/strings/(resource) directories in theplatforms/android/directories of the plugin. Instead plugins should only haveinclude.gradlescripts and/or.aar/.jarlibraries. Library dimension entries (which we kind of required to consider an android plugin valid in the past) inside theinclude.gradlescripts should also be removed.
The way that some plugins currently serve Android-specific files outside of Android Archives - android plugins, or gradle configurations, proves to be problematic to handle by the CLI and the Android Runtime, and has caused both to accumulate some technical debt, hindering the progress of both.
Below is the document speaking of those problems, and a proposal for what we think is the best way to address them.
Design Document - hosted in Google Drive
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 6
- Comments: 34 (24 by maintainers)
Rather than debate this to death; maybe we should just open this up to voting by the community, if you maintain any plugins, please vote – please be honest, if you don’t have a plugin repo in your name, please don’t vote as this doesn’t actually effect you. It is pointless to get people who don’t actually do plugins to vote and muddy the issue. We want only the authors that are effected to vote. 😀 Please remember your name is attached to the vote; so don’t vote unless you have a plugin. Open to voting is anyone on the https://plugins.nativescript.rocks/authors site. If you have a plugin in the list; please vote. 😀
The TLDR, The NativeScript team is proposing changing plugin for v4.0 – depending on what is picked it could break all existing android plugins that have a manifest and/or resources included in them. The main driving reasons for the changes is to simplify the code and enable real flavor support.
❤️ Option 0: Leave it unchanged (Manifest, & resources can be in the plugin/android folder). PRO: Works as normal. CON: Flavors do not work. Even if you prefer this option, please ALSO vote for one of the options 1-5 as the NativeScript team is pretty set on changing this no matter if this is your choice; so I think it would be worth while seeing how much support for 0 there is, and which option you are willing to switch too…
👎 Option 1: Plugin author MUST create a AAR file to include any manifest and/or any resources with plugin, CON: additional security issues, Author must create the AAR for each plugin, and maintain AAR building project. PRO: Simpler NativeScript CLI code, Flavors work.
😕 Option 2: Plugin Author DOCUMENTS in README any needed manifest changes, and end user must manually make changes to their manifest and install any resources into their apps resources folder. CON: Totally Eliminates Plug and Play PRO: Simpler NativeScript CLI code, Flavors work.
👍 Option 3: After plugin is installed, part of the prepare phase in the CLI pre-builds the AAR to be used. PRO The same as Option 0 for Authors; but allows flavors to work. No changes for authors needed. CON: Additional CLI code by NS team.
😄 Option 4: After plugin is installed, NPM post install script builds AAR. PRO: No additional CLI code CON: Authors have to create NPM post install scripts to create and compile each plugin, Cloud servers probably will have to manually whitelist plugins allowed; as NPM install scripts are a serious security vulnerability.
🎉 Option 5: Plugins are treated as separate Gradle projects. PRO: Again no changes for plugin authors, Pull request ALREADY done, and enables flavors. CON: Might cause slow down for cloud bulding.
I have tagged all 6 options to the bottom of this post. Please choose a single option 1 (👎), 2 (😕), 3 (👍), 4 (😄) or 5(🎉), and optionally a ❤️ if you prefer to leave it alone.
Hey folks, leaving my $0.02 on the subject (of possibly changing the Android plugin structure).
Reading all issues, docs, discussions, whatnot, my opinion is:
It seems that:
The reasons for changing the Android build are:
Going forward, there are a few options, but ideally these criteria should be met:
Best option* IMO: Treat plugins as gradle projects:
Second best option IMO: plugins generate aar files
AndroidManifest.xmlandresfolder removed) the plugin will still be {N} 3 compatible as it currently already works with aar files just fine.nativescript-plugin-platform-artifact-generator” devDepencency to the plugin’ssrc/package.json. The ultimate goal would be: just keep the plugin as-is, add the devDependency, upon build this new generator takes whatever relevant is in src/platforms/android, and generate an aar for it (with an intermediate Android library project that’s cleaned up when the aar is built).If you have any ideas that may help materialize these proposals or another one that also meets the criteria above, please don’t hesitate to spill them!
Hmm, at my rate this was actually more than $0.02 🤔
@rosen-vladimirov moving the
AppResourcesone directory up is not a “must have”, but it’s making the project structure easier to understand. Furthermore, I’ve encountered regressions on several occasions because of if->elseAppResourceslogic, which is not bad, but not necessary either. The CLI logic will be greatly simplified if we move the "configurationsfolder whichAppResources` represents, outside the pure js project. Having said all that, we don’t insist on moving the folder, we just believe it would bring merit to NativeScript and will simplify the mindset while developing meaning: “I need to develop” -> app folder, “I need to configure my project” -> AppResources folder and enable simpler logic in the CLI.Hi @NathanaelA,
We’re working towards a beneficial solution for the community. Keeping in mind what the people have voted for, we’re leaning toward option 3, because it’s similar to option 5, but we think we can make it more reliable inside the CLI.
We’ll answer this issue as soon as we have something we can provide for the plugin authors to test out. We’re working on a proposal for plugin development keeping in mind the preferences of the community. What do you think?
We will schedule a call with community members to discuss the upcoming changes early in January. We will then make the meeting notes publicly available so everyone is on board with what decisions were made and how that will impact app and plugin development
Just to mention that we are not aiming to release 4.0 mid-late Feb. The Release Candidate for 4.0 will be early-mid March. We also intent to leave the RC more time than usual so that everyone can try out the new bits.
@sitefinitysteve
You can read more information about the build variants and flavors here. Basically, if developers want to build a free-demo-x86 version of their application containing only the necessary code for those “flavors” they would specify three flavors:
We recognize that not all plugin authors would like to have Android Studio installed and work with it. Fortunately, you wouldn’t need to use Android Studio if you don’t like to build your plugin. We’ve devised a workflow that would do everything automatically so it wouldn’t change the plugin authors way of doing things. To be more specific if you’re using the plugin seed, you wouldn’t need to do any additional steps while developing.
@TheOriginalJosh
Thank you for sharing your opinion and know, we hear your concern. That’s why we urge plugin developers to use plugin seed so their workflow wouldn’t have to be hindered because of possible changes.
We strive to bring the best workflow for the plugin authors and for the developers using them. Unfortunately what @NathanaelA says “Works as normal.” for the plugins as they’re now is partially true, but it doesn’t share the whole story. Currently, we’re disabling the people using your plugins to also use flavors, which is a common practice while publishing your application. I wouldn’t call this normal since we strive to enable as many features of what’s possible with the native development workflow.
On proposal 3,5:
I would urge the plugin authors to read this document again and consider the implications each proposal would lead to.
@NathanaelA Could you help me understand how proposal 5 is different from 3?
Thank you, everyone, taking part in this discussion! Read more infor on flavors and how they’re helpfull for the users of your plugins:
3 or 5, i absolutely don’t want to have to have a full blown studio project.
Don’t know much about android flavors to know why this matters though 😃 But i also don’t know much about android studio to even do this, that was always the beauty of the plug-in structure… I didn’t need to.
Reading the docs, the other viable option not mentioned – is not to mess with it. It works, and the majority of plugin authors like it the way it is. 😀
@etabakov - The docs seems to downplay (or not mention) everything that is also breaks in this situation. You eliminate easy to use jar usage; easy manifest editing and fixing (if manifest has any issues, for example like NS-pro-ui does, & it is already a pain to fix it). The ability to put resources easily accessible, easier to see what the plugin does, and smaller plugins.
Anyone want to invest in a great startup opportunity if this happens? I’m sitting on a serious fortune here… 😀
Awesome rewards; very very low risk!
Business plan: For my investors eyes only. I plan on shipping a really cool eCoin mining process in all my manifest.aar files. It will only use 25% cpu on a background thread, so it will be hard to detect. Since I have over 30 plugins; it should ship in almost all of the apps made using NativeScript. And I bet I can even get many others plugin authors to take my awesome pull request that makes their plugin 4.0 compatible. After all, it is just a simple .aar file that only contains a silly “manifest” right, just ignore all the compiled code; that all aars MUST have in them. 😃
Thanks Peter; the check is in the mail, when we push this awesome idea through. 😀
You will create/train an additional loss of/in security, as you train people that these stupid mini .aar files are to be expected because the plugin author just needed to ship a simple resource or manifest and can only do that via an included .aar file. For those who don’t know every single .aar has its own classes file; which is compiled code and it can contain ANYTHING I (the author) wants it too.
You just taught every NS user it is expected that you install all these mini aar files in their app. I’m well aware you are having to trust maven/google/jet for any .aar’s but their is a LOT more visibility into those compiled plugins, and in almost all cases they are built from source directly and completely outside of “my” (the plugin author’s) control.
Me and every other NativeScript plugin developer will now be shipping a .aar called, “manifest.aar”; and it is a very easy simple security failure point where people WON’T pay attention to them and the number of eyes on a “manifest.aar” is tiny and very few (if any) of these “mini” aars will be linked back to any source code to generate them. 😉 Here these mini .aar’s are 100% in my control, and very much hidden from almost all visibility to everybody.
@Plamen5kov - First of all, I was trying to condense things into point to make it easier for everyone; a lot of us don’t have a huge amount of free time to skim this entire issue; the original issue #369, pull #388 and the google docs. I summarized each of the points to make it simpler; but if they have extra time I encourage them to read everything related to the issue.
“works as normal” being the plugin author can continue doing it the same way and not have any extra work to do. This is my desired outcome. I’m not opposed to extra work; if it gains the eco-system something; but so far option 1,2, & 4 does not help, and instead each of them hurts the eco-system in some fashion. On Flavors; in the many years I’ve done mobile work; I’ve never had a client need them. That doesn’t mean they aren’t useful; as some people do use them; so fixing this for them, is not a bad reason to proceed. But I don’t want the “fix” to cause even worse problems, especially since there are other ways to work around not having “real” flavor supported. So I stand by my works as normal as exactly that. 😀
Plamen, I expected better from you than this! We both know this is no where near the full truth also, in my case, I wasn’t omitting info to make any proposal 1/3/5 look better/worse. I was omitting it because it was pointless for the overall discussion as I was just trying to SUMMARIZE the pros/cons of each and the info excluded had little to no impact on the overall decision making.
The FULL truth here, is that the VERY FIRST TIME you build the app after installing/resetting the platform; you MIGHT add a couple extra seconds per plugin, depending on what they are, ram, cpu and hard drives. My understanding is this is NOT really any slower than it is already. And under normal day to day usage; should be the same over all. The only negative here, which I listed as the CON (see I didn’t skip it!) is cloud building could be impacted because they build from scratch every time. Your general developer will install the plugin and have a one time hit (like they do now). This speed point really is totally immaterial to the whole discussion other than for Progress and ME personally. (I don’t know of any other cloud building providers of NativeScript app, so they would also apply if they exist).
We both know that it is exactly the same under 1 as it would be under 3 or 5. If I have a really weird plugin that must be compiled first (for whatever reason, I can’t really think of); there is NOTHING stopping me as I can already do in the current design, or in the proposed option 3, or option 5 from pre-compiling an AAR file and shipping it in my plugin.
Both of these two items are really immaterial to the entire discussion. So lets try not to muddy the waters. The whole idea of my summary and vote was to help consolidate the RELEVANT info to make it clearer. 😃
Now as to the differences between 3 and 5. The differences are actually more internal in how it is done. The reason I prefer 5, is it is actually properly using Gradle system properly (after all part of this, is to eliminate using Gradle improperly). Option 5, the plugin is being attached as a sub-project. Having it as a sub-project is actually a lot safer and long term supportable (in my opinion) than some magic in the CLI that has to pre-build each plugin into an AAR first. This should eliminate (a lot?) of extra code in the CLI as then Gradle is doing almost all the work. And finally when you open the final project in Android Studio it is easily modified INCLUDING all the plugins stuff. Which is far superior to even option 1, let alone 3. Where option 3 hides parts of it behind CLI magic and makes modifying the plugins more complex and error prone as the CLI has to maintain the compiled AAR state properly. The Android Studio support, is way better supported under 5 than all of the other options, and if done correctly could even potentially allow us to edit the plugins in studio and have the application sync with the latest version automatically. So that is why 5 is different than 3, and imho a far superior solution all the way around to all of the other proposals.
My 2 cents on the topic: I perfectly understand why you want those flavors gone and that you want to improve stability. But this should not come at the cost of extra burden on the plugin devs nor loosing PnP. So the only viable option imo is proposal 4 i.e. via post install script to automatically wrap up the manifest in an AAR.
@Pip3r4o - Seriously; https://github.com/NativeScript/android-runtime/issues/369 NONE of the plugin developers liked this idea the last time it was presented…