Develop Reference

On using support libraries in Android for graphical reasons

I feel I have some questions about using support libraries. Having started developing some months ago, I am facing the situation where all of my targeted devices (let's say API>16) have pretty good and consistent tools, smart enough to fit my needs, but really miss some UI elements in comparison with API=21.
Today I added three new dependencies from the v7 support libraries. What I've noticed is that, as expected, the app size lifted from just 200kB to 3800kB. While that does not really make me worried, I can imagine that, along with size increasing, the smoothness of a process relying on dependencies can be reduced. And I went for v7 for purely graphical wishes.
I'm wondering: is it convenient to rely on support libraries if not strictly needed? Is it reasonable to add size and lose some smoothness, just to bring Material to, say, >4.2 users? Would it be better to have separate styles and take some (sometimes hard) work to emulate new features on older OS versions?
(note that the goal here is maximizing the popularity of the app).
As a consumer myself, I'd go for the best looking UI, but only if the app runs as it should. In addition, the older the device (and we're talking about older devices here), the more concerned should the user be about size and smoothness, as his hardware would be dated.
P.S.: I don't think that 4MB is a troubling size - I'm asking for some kind of "rule". Plus, I've read here, and I feel my question could be "constructive", although secondary. Feel free to flag it if it's not.

Using any library is a shortcut to doing all the work yourself - if you find it more efficient to pour over the design guidelines, implement , and test on many devices and many API versions, then do so. For many, the easier choice is to use the Support Library.
For APK size and 'smoothness of a process', Google provides two tools minification (via ProGuard) and resource shrinking as per this Google+ post announcing their availability. Assuming you are using Android Studio and Gradle, you can add:
android {
buildTypes {
release {
minifyEnabled true
shrinkResources true
}
}
}
Which will strip out unused methods (the minifyEnabled part) as well as unused resources (the shrinkResources part). This can be especially helpful with libraries such as the AppCompat Support Library which contains a number of image resources that you may not actually use in your application.
Obviously, the minification/shrinking process takes some time and can slow down your development process hence why they are only enabled in that example for release builds.

I would definitely recommend using the support libraries. We use them on our commercial app and we do not get complaints from users with older devices. But because we use them we are able to move very quickly to adopt new Android features, many of which would be extremely difficult to implement ourselves. Especially with Lollipop, Google is making it harder to just imitate the UI.
I was going to add some comments about ProGuard, which I also recommend, but Ian's answer has some great suggestions along those lines, so I will leave it at that.

Which libraries does Sherlock exclude?

Action Bar Sherlock, while being a neat library, as you might know, has two to three pretty invasive elements:
It forces you to inherit your Fragments and Activities from SherlockFragments and SherlockActivities. This is a sparse resource which you can't use for another handy library that might require you to do the same. Luckily the compat library isn't one of them (actually it is, but Sherlock builds on it).
It uses an Android library project. Since the tooling for these can't quite be called very stable yet, you might run into problems sooner. In fact, I have run into Eclipse bugs.
It's yet another library that makes Proguard's job harder and adds to your apk's size. Apk sizes are still a huge limitation for some users, among which Google TV users.
As such, what other possible (future) libraries, including 3rd party ones, would I be excluding if I choose to use Action Bar Sherlock? Any other limitations I'm missing?

As such, what other possible (future) libraries, including 3rd party
ones, would I be excluding if I choose to use Action Bar Sherlock? Any
other limitations I'm missing?
Frankly, I don't know of any. Most libraries which are making the use of a custom implementation of Activity(like ActionBarSherlock is doing as well) will most likely extend SherlockActivity(since almost everybody uses ABS) or if not then you could just modify it yourself. So no, as far as I can tell there won't be any limitations.

As #Jake Wharton himself pointed out this is just not true. Using the existing code and examples, it is a simple and fairly quick implementation for creating custom ABS activities and fragments.
I use library projects extensively, including having library project references that go multiple levels deep. I've run into a few issues, but nothing that was a deal breaker. Eclipse gets confused sometimes on rebuilds, but usually cleaning all the projects gets everything sorted out. Library projects are getting more stable all the time.
This is actually two points, but with a similar theme -- for any library, not just ABS, you have to tradeoff the value you get from including the library's features against the cost of doing so. I feel the value of the interface right now is worth the extra effort and apk size. This is a value decision that needs to be made on a per app basis.
#Ahmad is correct, ABS poses obvious no limitations on 3rd party libraries. It might take some coding to integrate, but they should work together. Furthermore, ABS use will fade naturally in the future. It is a compatibility library, so as the device distribution shifts more and more to Android 3+ devices, the need to support action bar UIs on 2.X devices will be less of an issue.

How to implement multiple Android versions to use different libraries?

I know there are a lot of questions out there about multiple Android versions pertaining to free/paid versions but this might be a little different.
My app currently uses AdMob for advertising and it's published on the Android Market and on the Samsung App Store. Unfortunately, the Samsung store will require everyone to migrate to their own Ad Network in the future, Samsung AdHub. Both AdMob and AdHub have their own libraries, their own SDKs.
I'm looking for a solution to build 2 different versions, one including AdMob the another including AdHub (and all the necessary code). What solutions do I have to easily build 2 versions without much hassle when it's time for a new version release?
Lots of solutions recommend to move the main project into a library project and then build 2 other apps which include the library project (the base project). But I'm not very fond of that solution (I prefer to keep my app in one single project, if possible) and I'm trying to look for alternatives and then make up my mind about which one is better for my needs.

I'd think you should make this possible in your code using the Strategy design pattern. It suites well and can be switched at any trigger your like (even on runtime). If you make a facade for each jar file you will be able to change the dependencies while building, having the same source code.
Other option with this method is just making some configuration in your application that determines which library to use.

Some interesting solutions can be found here:
https://groups.google.com/d/topic/android-developers/8pRugcnzR_E/discussion

The way to go now is to use Android Studio and use different Gradle flavors for each app. Thus, if you fix core functionality, you can quickly do a build for each appstore with it's own ad network.

Library Projects is the way to go. Create a base project where you implement all the common stuff and then create two separate project that use the common one as a "Library". then just implement the rest needed to make the Apps behave differently.

Moving an existing app to Android 3.x

I have a published app for Android 1.x and 2.x, and now I want to make it support 3.x.
But Android 3.0 has massive API change, especially on UI, thus if I want to make one app compatible to 2.x and 3.x, the code will be ugly and package file will be huge.
On the other hand, if I make another app for 3.x, then I need to maintain two copies of their common codes. That's really annoying.
What should I choose, or does anyone have a more smart solution? Thanks!

If you package them together you could still maintain everything separately - For example: put a prefix in front of every layout and class for 3.x, such as honeyMain.class, and honeymain.xml
Or you could do it a way that makes more sense for you.
Or keep them partially together.
It WILL make your app larger, but then when 15 people with 3.x download it and 60 people with 2.x download it, you get 75 downloads, instead of 15 for one app and 60 for the other. The 75 cumulative will look better on the apps over all ranking on the market.
On the other hand, if the 3.x is really ugly or FCs, then negative ratings will impact both 2.x and 3.x, but that is easily controlled for by testing, testing, testing.
Also, I personally hate managing code for two different apps. It's overly repetitive.
So, my recommendation is to package them together.

Make use of resource qualifiers, e.g. -xlarge, -v11, etc.
Use reflection where necessary or other techniques to avoid pulling in stuff not supported by API level.
Use the compatability library, that way you can fragmentize your code regardless, avoiding duplication, and with little effort handle different screen sizes.
See providing resources
See multple screens
See compat lib

Right click on your project and select "properties",select "android" from window,and which type of version you want check it and apply

How do you release two versions of an app on the Market?

I would like to add two versions of my app to the Android Market, one for a few cents, and one free version, with ads. That's a very common practice.
I'm currently building AdMod into my app, and it seems I'll have to change quite a few files, so it seems best to make a separate version of my app for this.
How do you achieve that? A branch? A different repository? Has anyone found a way to keep both apps in the same repository in a reasonable manner?
The title is not misspelled, I do mean "realise", i.e. how people manage the two versions, not how they add them to the Market.

This kind of thing is a complete nightmare - unfortunately the Android build system doesn't really support it in any good way.
We do it by having 99% of the code of our application in a library project. We then create one application project for each different version of the app, each of which use that library.
Where we need different versions of the app to behave differently, we currently achieve that by having different resources that are queried at runtime. We are in the process of moving to using Dependency Injection via RoboGuice, however.
There are elements of this that work reasonably well, and others that don't. It's necessary, for example, to duplicate the AndroidManifest.xml file, which can be error-prone (it's easy, for example, to add a new activity to one manifest and forget to do so in the others). It's a mess, unfortunately, but the least-bad solution we've found.
Personally speaking, I would strongly advise against using branches to achieve this effect. They can work well initially, but will rapidly become a maintenance nightmare.
One side benefit of using a library is that we've found that it makes testing considerably easier. For an example of how to set this up, see:
http://www.paulbutcher.com/2010/09/android-library-project-with-tests-step-by-step/

People usually upload them twice(like two different programs) and just modify the title for adding something like Ad-Free, Donate and things like that. And on the free version just add the Free label and also put on the description that it's Ad-Supported.
Here is an example with the SMS Popup application:
For the Android Market, they are considered different programs, but for us it's the same, but one is Ad-Supported and the other isn't.