What is "the Android Framework"? In short; it is the layer of Android that defines APIs, services, and environments for Android applications. For a better explanation you should see AOSP's description.

Note that this post starts with the assumption that you already have a working Android build, have sourced build/envsetup.sh and have lunched. The best place to get help with this is the AOSP Downloading and Building documentation.

Iterating Within the Java Framework

In a Nutshell

The Android framework module is built by the frameworks/base/Android.mk makefile. In AOSP mm builds the module for the current directory and mmm <dir> builds the module in <dir> (or in a list of dirs).

ProTip:  elinux.org's wiki is a good cheatsheet

You'll need a rooted device to iterate on the framework without having to flash the entire system each time. This is because the adb sync command is copying just the parts of the framework you have rebuilt to the device's /system partition. For the Java framework this will be out/target/product/<device name>/system/framework/framework.jar.

Alternative System Build

It's worth mentioning that there's an alternative way to get a system image which contains a java framework onto a device. Once you've run the mmm part of the build and have the build intermediates you want to get onto a device you can run

which stands for "Make System with No Dependencies". This simply packages up whatever is in the out folder into a new system image. You can then `reboot fastboot` and `fastboot flash system` to install the entire system image onto a connected device.

Careful here though, if this is the first time you are flashing a device from your local build you'll want to do a full build/flash or your device may get into the infamous infinite app optimization and reboot. See the Android Open Source Project's docs for full details on building AOSP and get past the point where you:

before starting to use make snod or adb sync.

Being System

The signature and signatureOrSystem protection levels become more important when developing for the Android application framework. That said, don't define systemOrSignature permissions unless you understand the ramifications doing so has for your Android distribution (I'll have to write a follow up post some day about this). For the signature level, the framework itself is signed using a key that establishes a signature defining what packages belong to the system and what packages are from another source (i.e. "downloaded"). Because of this your package will have to have the same signature as the framework to obtain signature level permissions defined by the system.

Under build/target/product/security you'll see several keys that sign various parts of the system. We're mostly concerned with the platform key when working with the application framework.

To create an application keystore with the same signature as the application framework build you'll need to create a java keystore that contains the platform key and certificate found the build. To do this you'll need two things: the JDK's keytool executable and openssl. Once you have these on your path, have a working AOSP build, and an Android application development environment you can create a new debug keystore like so:

You can check that this is a valid keystore using keytool:

Now all you have to do is either point your app build to use this keystore or
replace your randomly generated debug keystore with this one:

If you've already installed an application package and get an Application Installation Failed, INSTALL_FAILED_UPDATE_INCOMPATIBLE error this is because the signature has changed. Uninstall the package and you should be able to install the version with the new signature without further errors.

Free Rein

WARNING! This hack disables critical security measures in Android. Don't install any real user accounts on a development device running this hack.

Sometimes you want to test integration with apps that are production signed and limit access to certain activities by signature. If production signing your development app is too much of a burden you can just disable the signature check. In Lollipop this was found in ActivityStackSupervisor.java:1430. By commenting out the real security check and always reporting PERMISSION_GRANTED you can start any Activity you want on your hacked system regardless of signatures:

Tools

Here are some resources that you'll find useful while hacking AOSP:

AndroidXREF – Online OpenGrok index of the full AOSP codebase organized by release branch. This resource is invaluable for developing AOSP and applications. Frankly the existence of this site is one of the key benefits of Android over iOS for developers. There's no scouring docs and trying to reverse engineer strange behaviours. You just go to the source and you know exactly what the problem is. done.

App Detective – A useful app for enumerating all the activities, services, providers, permissions,  etc available on a system. This can help with building rich integrations with other popular apps.