Today I'd like to share with you some tips for navigating the source code of the Android framework.As Android developers, I believe this is an underutilized skill that we should be striving to hone.Because Android is an open source framework, we can investigate its implementation and gain a unique depth of understanding into how it works; and how to make it best work for us. Documentation can be wrong, outdated, or lack specifics; but the source code cannot steer you wrong. This is not to say that the SDK documentation is of no use; but we cannot always rely on it to explain every behavior that might affect us. Additionally, the source code can be quite instructive in implementing performant code for requirements that may be similar to, but not quite the same as, the framework components.
I'm going to show you a couple different tools and methods of getting into the source code, from the light and simple to the deep dive.We'll start off with some tools you can use inside of your browser to quickly and easily get to the source of individual class elements from right within the SDK documentation you're likely already familiar with.
The first step is to make sure you have Google Chrome installed.Both of the source diving tools we are going to look at in this section are browser extensions that only work in Chrome. If your daily browser preferences lie elsewhere, I'm hopeful that exposure to these tools will cause you to reconsider (at least while you are developing).
The first tool is the Android SDK Reference Search by Roman Nurik. This extension provides two major benefits: the first is an addition to the omnibar allowing you to jump directly to reference documentation for any class of interest.The second, and more salient to our discussion here, is the addition of a "View Source" link that is added to all doc pages that will link you from the reference docs into the source code for that class.
Next up is the Android Resource Navigator by Jeff Gilfelt.This extension provides slightly deeper searchable access in the omnibar to the styles, themes, and other resources used by the platform. Additionally, XML and image resource references in GitHub AOSP mirror are linked so you can click on them to jump to their implementation without the need for another search; and this is the case whether or not you started the search from the omnibar.
When you get to the point where you want to dive a little deeper into the framework and system services, the browser environment can be a bit constraining.So let's move beyond this and see what we can accomplish with the command-line tools bundled into the Android Open Source Project. For this, we will first need to obtain a local copy of the source tree.
Lastly, I'd like to share with you some guidance to keep you on the right track. The Android source tree is a big place, but hopefully these thoughts will help you find the signal among all the noise.
1. System apps
Most of the core system applications will be found in packages/apps; source code for applications like Browser, Launcher, and Settings can all be found here. Additionally, a handful of applications also live in frameworks/base/packages; most notably
SystemUI, which controls all of the system chrome for the status bar, window shade, and soft nav buttons.
2. Framework classes
Much of the framework is contained in frameworks/base/core, with a few packages like telephony and location living in their own directories under frameworks/base. It is important to realize that the Android APIs are not entirely written in Java. Many of the framework classes have a native C/C++ component to them. AOSP typically segments the files into a separate java/ and jni/ directory; the latter standing for Java Native Interface and including the native components.
3. Framework resources
The XML and drawable resources of the framework are located in the res/ directory of frameworks/base/core. You will find this file hierarchy structured similar to what you would find in an application project; with XML resources in the drawable/, layout/, values/ and xml/ directories, and image resources in the qualified directories such as drawable-hdpi/.
The platform also has its own Android Manifest file, which contains the definition of published system elements like permissions. Many of the system-level activities and receivers are published here as well. This is where we saw the implementation of
RECEIVE_BOOT_COMPLETED in our deep dive example.
4. System service structure
Most of the system services available to applications follow a common implementation pattern. The classes accessible to applications, such as
NotificationManager, are typically found somewhere in frameworks/base/core; and are often very thin wrappers around method calls to a single service object running in a remote process.
These service defitions, where most of the implementation code exists, are usually found in frameworks/base/services with names similar to their corresponding manager, such as
NotificationManagerService. As we discussed earlier, these services are usually not written entirely in Java; and may very well include a native C/C++ component. Because of this, the implementation is typically split between the java/ and jni/ directories.
If you'd like to dive into more detail about how Android works, then I would encourage you to sign up for one of the Android Internals classes that I'll be teaching for ProTech.
I'd also like to encourage you to check out what we're working on over at Double Encore.
Thanks very much for your time today and I hope you learned something new.