Eight classes handle plug-in – Service implementation

This article mainly introduces Android plug-in development, how to run not installed apK Service. Unlike the solution I described two years ago (running services that are not installed in APK), the solution implemented this time is completely open-ended and the plug-in APK can be a completely standalone application without special syntax changes.

Service loading process

As with the dynamic loading principle of an Activity, we need to start and load the Service first. The main process is as follows:

Starting a Service is similar to an Activity and eventually calls a method in ActivityManagerService.

• And then thestartServiceLocked()Safety monitoring;
• Once the safety checks are complete,scheduleCreateService()Ready to createService
• Call againscheduleServiceArgs()Send a message
• Will end up inActivityThread.CallbackIn the processingHandleSent message.

After defining the entire process for starting a Service, we find that although the process is very similar to the Activity startup process described in the previous article, we cannot use the same method for activities, because the Instrumentation class is not used at all. And just like in the Activity, there is no way to override the startServiceLocked() method to tamper with the system validation because it runs in another system process, system_server. A final problem is that unlike an Activity, a Service can start multiple instances, and the onCreate() method is never called again after the same Service has been executed.

Replace the system Service creation process

Although there is no way to create a Service through Instrumentation, there are ways to replace the system creation process. In the last activityThread. Callback step, Handle sends a number of message types, including: CREATE_SERVICE, SERVICE_ARGS, BIND_SERVICE, etc… Not only the creation of the service, but also the Activity’s lifecycle methods are invoked in this callback. CREATE_SERVICE calls a method called handleCreateService(CreateServiceData data) with the main code:

private void handleCreateService(CreateServiceData data) {  
	LoadedApk packageInfo = getPackageInfoNoCheck(data.info.applicationInfo, data.compatInfo); 
	Service service = null;
	try {
	 java.lang.ClassLoader cl = packageInfo.getClassLoader();
	service = (Service) cl.loadClass(data.info.name).newInstance();
	} catch (Exception e) {
	}
	
	Application app = packageInfo.makeApplication(false, mInstrumentation);
    service.attach(context, this, data.info.name, data.token, app, ActivityManagerNative.getDefault());
    service.onCreate();
    mServices.put(data.token, service);
    try {
    ActivityManagerNative.getDefault().serviceDoneExecuting(data.token, 0, 0, 0);
    } catch (RemoteException e) {
    }
}Copy the code

As you can see, the Service is also a normal class, where the system comes out new and executes its onCreate() method. So we can do our own Service creation logic by replacing the callback class and modifying its logic if the message is CREATE_SERVICE. If the service being loaded is a plug-in, the service will replace the ClassLoader with the plug-in ClassLoader, and the loaded class will follow the process of the original host service. The attach() and onCreate() methods are all called manually. Instead, reflection is used to find mH in the original ActivityThread class.

Field mHField = activityThreadClass.getDeclaredField("mH"); mHField.setAccessible(true); Handler mH = (Handler) mHField.get(currentActivityThread); Field mCallBackField = Handler.class.getDeclaredField("mCallback"); mCallBackField.setAccessible(true); / / callback modify it for us, so as to HOOK off ActivityThreadHandlerCallback callback = new ActivityThreadHandlerCallback (mH); mCallBackField.set(mH, callback);Copy the code

I really want to make fun of the Android source code, which is full of various weird names. For example, mH is actually a Handle, but its class name is only one letter, a capital H, so its object is called mH. Then there’s an ActivityInfo variable called aInfo, and then there’s an ApplicationInfo object called aInfo, and every now and then there’s an AI, and you don’t know what it is and you have to go back and find its type. OK, back to the point, after the callback is replaced, creating the Service can be performed by our own methods. The problem is that onCreate is not called more than once, so we also need to change the logic of handleMessage(). If it is SERVICE_ARGS or BIND_SERVICE, we need to check first. If the plug-in service is passed in that it has not been created, then you need to run the handleCreateService() method again to create it.

@Override public boolean handleMessage(Message msg) { switch (msg.what) { case 114: //CREATE_SERVICE if (! handleCreateService(msg.obj)) { mOldHandle.handleMessage(msg); } break; case 115: //SERVICE_ARGS handleBindService(msg.obj); mOldHandle.handleMessage(msg); break; case 121: //BIND_SERVICE handleBindService(msg.obj); mOldHandle.handleMessage(msg); break; } return true; ** @param data BindServiceData */ private void handleBindService(Object data) { ServiceStruct struct = pluginServiceMap.get(IActivityManagerHook.currentClazzName); Struct == null {CreateServiceData (struct == null) {CreateServiceData (struct == null) {CreateServiceData (struct == null) {CreateServiceData (struct == null) {CreateServiceData (struct == null) // This token has a field of the same name in BindServiceData and ServiceArgsData, so it passes handleCreateService(data); }}Copy the code

Step on pit and climb pit

If you implement the whole plugin along the same lines, you’ll notice two huge pitfalls:

• The plug-in service is created, but if more than one plug-in service is started, then all but the last one is createdonCreate()None of the other lifecycle methods are called.
• The plug-in Service will not be calledonDestroy()Methods.

Let’s start with the first problem, the lifecycle approach. As mentioned earlier, each lifecycle method is actually handled through this Handle as well. Services = mservices.get (data.token); Services = mservices.get (data.token); All created services are added to a map (HashMap before 4.0, ArrayMap after 4.0), from which they are read based on keys or tokens when needed. Life cycle methods are not called. HandleCreateService () : mservices.put (data.token, service); That’s what it was for. It also explains why other services do not call lifecycle methods because map values are overwritten. So simple, this key value token we create and add to it.

The second trap, onDestroy(), was not executed. After repeated testing, it was found that the message with STOP_SERVICE identifier was not sent. The solution is also very simple, since the system did not send, then manually send this message on the line. Find the source of all messages, ActivityManagerService, and it’s easy to replace our focus with a dynamic proxy. Find two methods related to destroy called stopServiceToken() and unbindService(). While both methods are executing, call doServiceDestroy() to manually send the message yourself. And then when the other side receives this message execute the plug-in onDestroy()

public void doServiceDestroy() { Message msg = mH.obtainMessage(); msg.what = ActivityThreadHandlerCallback.PLUGIN_STOP_SERVICE; mH.sendMessage(msg); } private void handleCreateService(CreateServiceData data) { switch (msg.what) { case 116: //STOP_SERVICE case PLUGIN_STOP_SERVICE: if (! handleStopService()) { mOldHandle.handleMessage(msg); } break; } return true; } /** * destroy policy, stop real service */ private Boolean handleStopService() {ServiceStruct struct = pluginServiceMap.get(IActivityManagerHook.currentClazzName); if (struct ! = null) { pluginServiceMap.remove(IActivityManagerHook.currentClazzName); if (pluginServiceMap.size() == 0) { return false; } else { struct.service.onDestroy(); return true; } } return false; }Copy the code

Resources are loaded dynamically with so files

In this way, the dynamic loading of activities and services in the uninstalled APK is resolved. As a review, there are only six classes in total, so why eight classes to handle the plug-in? There are two classes for handling the dynamic loading of resources and so files. So file first, in fact, DexClassLoader native support dynamic loading, but why we passed solib did not load, or because of permissions. SD cards on Android phones do not have executable permission, so we must copy the so file to the application package storage area, either getFilesDir() or getCacheDir() are directories with executable permission. When constructing the plug-in DexClassLoader, pass the third parameter to a path with executable permissions. Since we only need to load an APK dynamically, there is no plugin resource conflict involved at all, and only one method is needed:

public void loadRes(Context context, String resPath) throws Exception { assetManager = AssetManager.class.newInstance();  Method addAssetPath = assetManager.getClass().getMethod("addAssetPath", String.class); addAssetPath.invoke(assetManager, resPath); Resources = new Resources(assetManager, context.getResources().getDisplayMetrics(), context.getResources().getConfiguration()); }Copy the code

At the end

No tidbits at the end ~ so simple 8 classes, do you have any questions?