Develop Reference

How do you extend an Android class like DayPickerPagerAdapter which is in the android.widget package?

I would like extend the DayPickerPagerAdapter module from the android.widget package. Is this possible?
What I am trying to do is to create my own DatePickerDialog (which I will also need to extend) where I can highlight multiple days as opposed to only having the selected day highlighted.
Will I have to just copy the source code of these android classes? If so, is that legal to do?
Thanks!

Yes, you can technically extend these classes by creating your new class in the same package (create the folder structure to match the package that you're extending), meaning that you would create something like this:
/src/main/java/android/widget/CustomDayPickerPagerAdapter.java
...and this will allow you to extend the DayPickerPagerAdapter class, because it's package-private.
However, this is no guarantee that you'll be able to successfully manipulate the internals of the component in the way that you want, because much of the functionality is likely private, which would mean you're out of luck.
You can also, of course, copy the source code of these components, as you suggest. This is perfectly legal because the entire Android project is open-source (Apache 2.0 license). The downside of this is having to periodically check for updates and bugfixes from upstream, and having to re-integrate them into your custom component.

Uncle Bob's clean architecture approach - what is recommended package structure?

I'd like to know if I'm using Clean Architecture the right way. I am trying to lay it like this diagram:
I've read that the package structure should be arranged by use case but I'm having difficulty following how that would be done.
Let's take a look at my package structure:
notice I don't know where to really put the activities in the UI folder, could you recommend ? does it matter?
In the data folder, I have my repositories I use for repository design pattern.
my retrofit network calls are on the same level as the UI folder. likewise for my dependency injection framework.
My concern comes after reading this publication I am now wondering if I did the package structure correctly?

One aspect Uncle Bob is emphasizing is that the clean architecture is screaming. That means that the top-level structure and names should express your business domain and not technical details and frameworks u use. On the second level we should separate the different circles.
In an e-commerce app things like cart, search and product catalog would shape the top-level structure. Use cases, controller and presenters would be on the second level.
I have blogged about this with more detailed example: Implementing Clean Architecture - Make it scream.

I would suggest you have a look to this repository. You can have a lot of feedback from the discussions in the issues section. I'll would read specially this discussion.
Now in orther to answer your question.
Does it matter? I would say no, it does not matter. Package structure is only a convinient way to structure your code to make it more readable and mantaiable. As long as you respect the Clean-Architecture principles it does not matter where you have your classes. Remember you can always do a refactor while you are progressing and your project is growing.
Where to put activities? If you already separate your UI package in components, you should stick to it and have an activities folder.
Recomendations: first I like to have one package or even a module for each layer (e.g. data, domain, presentation, infrastructure...) then within each package you can make your own decisions that you prefer. For example, I like to separate the presentation layer into features but the domain and data layer by components. The benefits of having one module for each layer is that if a new developer is going to contribute to the project you can enforce the clean architecture principles since they wont be able to reference a data class inside a domain usecase.

Android Studio best practices on app modules

I'm trying to understand the concept of modules on Android. I've read this article on the official documentation, but I'm a bit confused. Here is stated:
An Android Application Module is the container for your application's source code, resource files, and application level settings, such as the module-level build file, resource files, and Android Manifest file. The application module contents are eventually built into the .apk file that gets installed on a device.
and that's pretty much all the documentation I've found on this. I still don't understand in which cases would make sense to create different modules. I know that it may be vary from case to case, but ideally what would be the minimum logical size of a module?
A practical example
I'm building an app with a drawer view. Each button of the drawer will open a fragment which will have some logic to it. Would it make sense to make a module that contains only a fragment and a few java classes with no activities in it?
I'd really like to know which are the best practices on this.
Thank you.

Perhaps the best argument for breaking code and resources into modules is reusability. If not for multiple dependents of such a module, why would you need to separate this code out into a module at all? If you only ever have one application, there's not much need to have this code broken out into a module.
As soon as you have multiple applications sharing the same code, then I think a module is justified. A module could be many things. It could be a base application that contains the bulk of the code. It could contain the "Model" aspect of your application, or maybe an API or networking layer. It could be a container for proprietary algorithms. It could be some generalized code that you're planning to open-source. Who knows?
Consider it from the opposite angle. What's the risk of doing this now if you don't really need to? Maybe mental overhead? Having to think about and maintain this module may be more trouble than its worth if you don't have a good reason to do it in the first place.
What is the cost of deferring this decision? Is there any compelling reason why this code couldn't be refactored out of the main application into a module at some later point?
Something as small as a single Fragment for a single UI component sounds like something that doesn't need to be in its own module.

Modular android project - how?

My scenario
I have to implement a "modular" android app. There is a core module from which I should be able to invoke other modules. Each module provides a different feature to the user. Imagine I am making a city guide, then one module may contain a map with POIs, another one an event calendar and a third one pre-defined city guides. The modules contain views to be loaded in activities of the core module (like dashboards where each module puts its item/picture). They also contain activities which should be invoked (like when a user taps an item on the dashboard). As far as I know, I will need a database and/or preferences only in the core module. The "plug-in modules" use classes (utilities) of the core module, e.g. when connecting to the backend.
My solution on iOS
For iOS, I achieved this with targets in XCode. I have one project and depending on the customer's needs I compile only the relevant modules. It would be even better if the user can install modules whenever he wants, without the need of reinstalling the "core" application.
My problems on Android
In SO, I already found various solutions like library project, switching from Eclipse to Android Studio + something, using package manager and broadcast receiver... But I still don't understand... How is the modularity of an android application to be achieved?
Here are some concrete problems that I see:
Libraries: My modules all use classes of the core module, so they are not independent. I achieve the modularity by using interfaces/inheritance depending on the flexibility that I need.
Broadcast receiver: This seems to be everything else than recommended. See, for example, here or here.
What I need is, at least, to be able to use the same code for delivering app with features A and B to one customer and with B and C to another one. And, until now, I have no idea how to achieve it.
PS: I don't want to use scripting, I am not familiar with that.

I don't see this "modular" app as anything different from one app, with several packages, each containing discrete functionality, that is adapted to some list of settings or external parameter (either provided by the user or you).
My approach would be to have a "main" package. That package would contain the shared functionality you mention above and serve as the hub for your application. I would then create separate sub-packages for the different "add on" functionality. This allows you to still use the code in your main package with a simple import statement. From your description these additional functions should probably be implemented as a Fragment. A Fragment is almost a stand alone application with the exception that it is "hosted" by an Activity. Depending on how these add on functions are used (I cannot tell if they relate to the UI, just background processing etc) you could easily have 3 of 4 different fragments and choose to load only 1 or 3 or 2 of them at runtime.
To control which parts of the code are used I would just set up a simple switching class (it could even be part of the first activity launched, I cant tell from your description above). Here I would check for some setting indicating which parts of the app will be "active." This could be easily defined using SharedPreferences to store a specific configuration, e.g. use A and B, prior to delivering the final project. You would then just initialize the fragments you need and display them either (1) individually in a Fragment layout element or FrameLayout; (2) collectively in some other view structure like a ViewPager.
I follows your links on the BroadcastReceiver and I am still not sure why they are "everything else than recommended." Used correctly a BroadcastReceiver is very useful. I tend to use a LocalBroadcastManager along with a BroadcastReceiver to notify other sections of the app when some AsyncTask, e.g. downloading a lot of data, is complete. These parts of the app can then access a local database or process the information downloaded on their own time. I wouldn't use a BroadcastReceiver to modulate parts of the app if that is what you're looking for. I would instead just use a SharedPreference file to set the configuration at runtime.

If you need modules like facebook sdk or something like that better use library project. If you use Idea or Android Studio there is such thing like Module. If I need some modeles in one app I prefer just put in different packages like com.appname.model, com.appname.ui and so on. Broadcast Receiver isn't about modules. As I know there isn't analog of ios target.

Android global/common functions

Just started today to learn Android development, and I just can't find any info on how may I define a Helper class, or a collection of functions that will load globally and I'll be able to use them in any Activity that I create.
What I'm planning, is to create (at least for now) 2 functions that will be used almost in every activity, and would be a mess having to define the same functions in every activity.
Which would be the proper way to approach the above?

I want to throw out a quick note that you should not be putting functions in a global application class for this purpose. Generally what happens is that if you have shared functionality, you abstract that and put the code in:
Static methods
Another package
A library implementing the functionality against which you link your app
A content provider
You should explicitly not implement this functionality in the Application class. There are uses for extending the application, but doing so results in code smell and is a common antipattern for beginners. If you want a bunch of functionality which is shared in your app, a library is the perfect solution (even if it's just code you separate into another package). This encourages reuse and allows the code to be more cleanly segmented and tested.
It's common in Java to have either a class or pacakge of the form *.util for this.
(I'm guessing you come from something like a Rails world where this is the norm, since Ruby is much more metaprogramming oriented than Java, you generally use different tricks.)

This would be a static method in Java.
Java Static Methods
In a class Helper,
public static void DoSomething(){
}
Would be accessible from any class.
Example:
Helper.MyFunction();