AndroidLife

AndroidLife is a collection of Android implementation examples covering various aspects of Android development, including UI components, design patterns, utilities, and system services. Developers can use this repository as a reference for implementing specific features such as:

• UI & Design Support: TextInputLayout, NavigationView, FloatingActionButton, Snackbar, CoordinatorLayout, and various TabLayout styles.
• Utilities: DeviceUtil, DateUtil, ImageUtil (for downloading and saving to gallery), ReflectionUtil, and ResourcesUtil.
• Core Android Concepts: AsyncTask templates, LaunchMode (specifically singleTask), Service (local and AIDL/remote), BroadcastReceiver (static, dynamic, and download), and ContentProvider.
• Advanced UI: EasySlidingTabs, EasyRecyclerView, EasyFlowLayout, TagTextView (rich text with clickable labels), and Span effects.
• Data & Concurrency: SQLite demos, RxAndroid usage, and Otto subscription mechanism.
• Hardware & System: SensorManager and LocationManager.

To hook the Activity Manager Service (AMS), you must intercept the communication between the local process and the remote AMS via the IActivityManager interface.

In Android, ActivityManagerNative holds a static Singleton<IActivityManager> named gDefault. The actual instance of the service is stored within the mInstance field of this Singleton object.

Hooking Strategy:

1. Create a dynamic proxy implementation of IActivityManager using java.lang.reflect.InvocationHandler.
2. Use reflection to access the gDefault field in android.app.ActivityManagerNative.
3. Access the mInstance field within the android.util.Singleton class.
4. Replace the existing mInstance with your dynamic proxy instance.

// 1. Implement the handler
public class IActivityManagerHandler implements InvocationHandler {
    Object base;
    IActivityManagerHandler(Object base) { this.base = base; }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        // Logic before method call
        final Object object = method.invoke(this.base, args);
        // Logic after method call
        return object;
    }
}

// 2. Use AMSHooker to perform the replacement
AMSHooker.hookActivityManagerNative();

To hook Activity Manager Service (AMS) for an activity plugin, you must understand the transition between the system_server process and the target App process.

1. Leaving system_server (Entering App Process)

The transition begins in ActivityStackSupervisor#realStartActivityLocked. This method calls app.thread.scheduleLaunchActivity(...).

• app.thread is an instance of ApplicationThread (an inner class of ActivityThread).
• Calling this method invokes a remote Binder Proxy object, which moves execution from the system_server process to the App process.

2. Inside the App Process

Once in the App process, the execution follows this path:

1. ActivityThread.H#handleMessage receives the LAUNCH_ACTIVITY message.
2. ActivityThread#handleLaunchActivity is called.
3. ActivityThread#performLaunchActivity is called.
4. Instrumentation#callActivityOnCreate is called.
5. Finally, the Activity#onCreate lifecycle method is executed.

3. Intercepting the LAUNCH_ACTIVITY message

In ActivityThread.H, the LAUNCH_ACTIVITY message can be intercepted by leveraging the Handler priority system. The Handler.dispatchMessage method follows this priority:

1. Highest Priority: msg.callback (attached to the specific message).
2. Medium Priority: mCallback (the Handler's callback object).
3. Lowest Priority: handleMessage (the default implementation).

To intercept the LAUNCH_ACTIVITY message without knowing which specific message object is being sent, you should hook/inject a Handler.Callback into ActivityThread.H#mCallback.

Validation of whether an Activity is declared in the AndroidManifest.xml occurs within the system_server process, specifically during the execution of ActivityStarter methods.

If the Activity is not found in the manifest, ActivityStarter returns ActivityManager.START_CLASS_NOT_FOUND. This result is passed back to the application process, where Instrumentation.checkStartActivityResult catches it and throws an ActivityNotFoundException.

Error Scenario: If you attempt to start an explicit component that is missing from the manifest, the following error is triggered: Unable to find explicit activity class <component_name>; have you declared this activity in your AndroidManifest.xml?

// Inside ActivityStarter (system_server)
if (err == ActivityManager.START_SUCCESS && aInfo == null) {
    err = ActivityManager.START_CLASS_NOT_FOUND;
}

// Inside Instrumentation (application process)
case ActivityManager.START_CLASS_NOT_FOUND:
    if (intent instanceof Intent && ((Intent)intent).getComponent() != null)
        throw new ActivityNotFoundException("Unable to find explicit activity class " + ...);

When interacting with a plugin's ContentProvider, you cannot use the plugin's original URI directly. Instead, you must use a stub URI provided by the host.

The URI format is: StubContentProvider.STUB_URI + / + [Plugin's Full Provider Class Name]

Example URI Construction: If the plugin provider class is com.camnter.content.provider.plugin.plugin.PluginContentProvider, the URI used by the host to query it would be: content://com.camnter.content.provider.plugin.host.StubContentProvider/com.camnter.content.provider.plugin.plugin.PluginContentProvider

// Constructing the URI to access the plugin provider
this.pluginUri = Uri.parse(StubContentProvider.STUB_URI.toString() + '/' + 
    "com.camnter.content.provider.plugin.plugin.PluginContentProvider");

// Using the resolver to interact with the plugin
this.resolver = this.getContentResolver();

// Querying
Cursor result = this.resolver.query(this.pluginUri, null, null, null, null);

// Inserting
ContentValues values = new ContentValues();
values.put("content", "some data");
this.resolver.insert(this.pluginUri, values);

// Deleting
this.resolver.delete(this.pluginUri, null, null);

To allow a plugin Activity to access resources (including layouts) from a plugin APK, you must hook the mResources field within ContextImpl.

Important Note: A plugin Activity cannot access cacheFile before calling super.attachBaseContext(newBase). You must use the newBase context provided in attachBaseContext to retrieve file paths.

There are two ways to handle plugin resources:

1. Direct Loading: Load plugin resources directly. This allows accessing raw resources but cannot load layouts via LayoutInflater.
2. Hooking mResources: By using reflection to replace the mResources field in ContextImpl, you enable the standard Android resource system (including setContentView(R.layout...)) to resolve plugin resources.

When using custom Views or Fragments, ensure you hold a reference to the inflated view:

final View selfView = LayoutInflater.from(this).inflate(R.layout.activity_main, null);
this.setContentView(selfView);

@Override
protected void attachBaseContext(Context newBase) {
    try {
        final Field field = newBase.getClass().getDeclaredField("mResources");
        field.setAccessible(true);
        if (this.resources == null) {
            this.resources = this.getPluginResources(newBase);
        }
        field.set(newBase, this.resources);
    } catch (Exception e) {
        e.printStackTrace();
    }
    super.attachBaseContext(newBase);
}