Android "Application Framework" Documents / Tuts

Question

Can someone point me to tutorials related to developing an Android development framework? Here I am especially talking about the "Application Framework" (the second level from the top in the android architecture), and not in application development.

I'm interested in: what happens after any application calls the system / framework API? How does the OS check if this application has this specific permission? Which component in the "application structure" handles this check? What java classes are responsible for this?

I would like to play with these java classes and make some observations.

PS: I assume that the permission model is implemented at the "application framework" level. Correct me if I am wrong.

Answer 1

There are limited resources for developing the framework, as far as I know, most of what is available is distributed through various blogs and mailing lists. For starters, I would recommend the open source project site, source.android.com . It contains limited documentation on how to do something, but at least provides customization for working with an open source project. Then there are official mailing lists related to the development of the platform and level. Various ROM projects may also have useful information about sites such as the Cyanogenmod wiki .

Then, to answer your specific question about how permissions are implemented within the framework. There is no special component that processes checks; each service provider within the structure must perform a permission check before allowing a service call. There are two important parts to this scan: the package manager on the system server and the IPC Binder mechanism. A package manager is an OS component that handles the installation of applications. This will lead to the analysis of the AndroidManifest.xml file during installation, offer the user permissions and maintain the registry which permissions are performed by the specific application. This is based on the idea that each application works with its own Linux user ID. For each uid there is a list of permissions.

The second part is the communication mechanism between Binder processes. Binder is an object-oriented way to execute IPC, but it also implements some security features. The most important thing about permissions is that it allows the receiving end of the IPC call to check the caller’s uid. A service protected by permission will have a Binder interface and will do two things for each request received. First, he will call a binder to get the caller’s uid, and then he will call the system server providing the uid and permission to check if it has been granted. If the check is in order, it will continue and make a call to the service, otherwise it will raise a security exception.

If we look into the source code, starting with a simple call to the vibrator service. (All of the codes below are copyrighted by the open source Android project under the Apache 2.0 license.)

public void vibrate(long milliseconds, IBinder token) { if (mContext.checkCallingOrSelfPermission(android.Manifest.permission.VIBRATE) != PackageManager.PERMISSION_GRANTED) { throw new SecurityException("Requires VIBRATE permission"); } 

The implementation for checking permissions at the frame level belongs to the Context class, and more specifically, we have the ContextImpl.java file, where

 @Override public int checkCallingOrSelfPermission(String permission) { if (permission == null) { throw new IllegalArgumentException("permission is null"); } return checkPermission(permission, Binder.getCallingPid(), Binder.getCallingUid()); } @Override public int checkPermission(String permission, int pid, int uid) { if (permission == null) { throw new IllegalArgumentException("permission is null"); } try { return ActivityManagerNative.getDefault().checkPermission( permission, pid, uid); } catch (RemoteException e) { return PackageManager.PERMISSION_DENIED; } } 

This is a call through the Binder in the ActivityManagerService, where we will end:

 /** * As the only public entry point for permissions checking, this method * can enforce the semantic that requesting a check on a null global * permission is automatically denied. (Internally a null permission * string is used when calling {@link #checkComponentPermission} in cases * when only uid-based security is needed.) * * This can be called with or without the global lock held. */ public int checkPermission(String permission, int pid, int uid) { if (permission == null) { return PackageManager.PERMISSION_DENIED; } return checkComponentPermission(permission, pid, uid, -1, true); } /** * This can be called with or without the global lock held. */ int checkComponentPermission(String permission, int pid, int uid, int owningUid, boolean exported) { // We might be performing an operation on behalf of an indirect binder // invocation, eg via {@link #openContentUri}. Check and adjust the // client identity accordingly before proceeding. Identity tlsIdentity = sCallerIdentity.get(); if (tlsIdentity != null) { Slog.d(TAG, "checkComponentPermission() adjusting {pid,uid} to {" + tlsIdentity.pid + "," + tlsIdentity.uid + "}"); uid = tlsIdentity.uid; pid = tlsIdentity.pid; } // Root, system server and our own process get to do everything. if (uid == 0 || uid == Process.SYSTEM_UID || pid == MY_PID) { return PackageManager.PERMISSION_GRANTED; } // If there is a uid that owns whatever is being accessed, it has // blanket access to it regardless of the permissions it requires. if (owningUid >= 0 && uid == owningUid) { return PackageManager.PERMISSION_GRANTED; } // If the target is not exported, then nobody else can get to it. if (!exported) { Slog.w(TAG, "Permission denied: checkComponentPermission() owningUid=" + owningUid); return PackageManager.PERMISSION_DENIED; } if (permission == null) { return PackageManager.PERMISSION_GRANTED; } try { return AppGlobals.getPackageManager() .checkUidPermission(permission, uid); } catch (RemoteException e) { // Should never happen, but if it does... deny! Slog.e(TAG, "PackageManager is dead?!?", e); } return PackageManager.PERMISSION_DENIED; } 

The package manager call checkUidPermission is what the search will do to match the uid with the tables of permissions granted. If you want to continue tracing the source, then the corresponding file is PackageManagerService.java.

If you're just researching, feel free to dive right into the code under / base / in an open source project. All files mentioned above are there. Follow the build instructions and you can check your changes using the emulator. If you don’t want to modify the core files of the framework, look at the sample in / device / sample on how to make the extensions of the framework. However, most permission-related APIs are application-level, so you can simply uninstall the application that provides the service and make your own permission to do so.