I had a similar problem with wrapping my head around this libraries issue when I started using Android Studio and Gradle just a few weeks ago (see discussion here <https://groups.google.com/forum/?fromgroups&hl=en#!topic/android-developers/O1hSIbQK0SU>, also for an overview of the available options). You would usually add 3rd party libraries as module dependecies to your app project (hit F4 and go to "Dependencies" tab, click the green plus icon and select "Library dependency"). An online repository is searched for the requested library (also taking the requested version number into account). As far as I understand, that library will be downloaded once into your local Maven cache, which will be used by all your app projects. So in this case there should be no redundancy.
When it comes to self-developed library modules you can do the same. I get around this module-inclusion problem by deploying development snapshots of my own libraries into my local Maven repository and adding them to the dependencies list of my Android app. No redundancy here. Libraries can be centrally maintained and developed outside the app project. The same with 3rd party libraries, they also can be added as dependencies from online repositories. The whole project organization and setup is driven by Gradle build files. You are free to configure it any way you wish. I do not quite understand the system property problem and I think there's also no point in requesting any change. Android updates are super-slow to roll out and it would take many years until you could rely on that feature. A library that interfaces with the Android API is also usually compiled against the Android SDK, so the programmer should be well aware of the presence of Android. Unless you access the Android API via reflection, but in this case you can just use reflection to figure out that your code is running on Android. On Wednesday, February 11, 2015 at 2:40:22 AM UTC-8, Ristar wrote: > > As written in the title, the Android Studio needs a "*create library*" > function very very very very very badly. > > Chucking the source files from everywhere to everywhere else is very bad. > It is the lazy man's way out, yes. But if one uses his own libraries across > many projects, it'd be a nightmare. The current method of having different > libraries inside the same project is very bad. > > Libraries should be managed from one project to reduce headaches, double > work, not knowing which file is where, etc. In other words, 1 lib project > for all app projects to use will definitely prevent many FUBAR scenarios > that waste everyone's time and makes everyone angry. > > Look at how Netbeans does it. That is the way to go. > > One more thing I have noticed, is that os.name returns "Linux", not > "Android". This is not so good. If it returns "Android", programmers can > utilise existing libraries for desktop versions of Java and adapt it to > android quickly. Hell, you can even put "Linux Android" or the other way > around. As long as there is a way to differentiate between desktop and > mobile. > > For example: > > if(System.getProperty("os.name").equals("Android")){ > //android implementation here. > } > else{ > //desktop implementation here. > } > > Thanks. > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.