Android动态部署五:如何从插件apk中启动Service

转载请注明出处:http://blog.csdn.net/ximsfei/article/details/51072332

github地址:https://github.com/ximsfei/DynamicDeploymentApk

Android动态部署一:Google原生Split APK浅析

Android动态部署二:APK安装及AndroidManifest.xml解析流程分析

Android动态部署三:如何从插件apk中启动Activity(一)

Android动态部署四:如何从插件apk中启动Activity(二)

经过前面几篇文章的分析,我们了解到了Google原生是如何拆分apk的,并且我们自己可以通过解析manifest文件,通过创建插件ClassLoader,Resources对象来启动插件APK中的Activity,上一篇文章关于资源的问题,有一点遗漏,在插件中开发者有可能通过如下代码获取资源Id

getIdentifier("xxx", "layout", getPackageName());

此时调用getPackageName()方法返回的是宿主apk的包名,所以我们需要在DynamicContextImpl类中重写getPackageName()方法,返回从插件apk的manifest中解析出来的的包名,接下来我们通过分析Service启动流程来看看宿主apk如何启动Android四大组件之Service。

Service启动流程

startService(new Intent(this, TargetService.class));

在Activity中,很简单的一行代码,就可以启动TargetService了,下图就是调用这行代码后的时序图:

带着成功启动插件Activity的经验,我们继续通过分析Service启动流程,试图从中找到hook点从而将我们对插件Service的扩展操作,通过类似的重写DynamicInstrumentation类,替换进ActivityThread中。

在时序图中我们发现在调用startService方法后,最终都会调到ContextImpl中的startService。

@Override
public ComponentName startService(Intent service) {
    warnIfCallingFromSystemProcess();
    return startServiceCommon(service, mUser);
}

private ComponentName startServiceCommon(Intent service, UserHandle user) {
    try {
        validateServiceIntent(service);
        service.prepareToLeaveProcess();
        ComponentName cn = ActivityManagerNative.getDefault().startService(
            mMainThread.getApplicationThread(), service, service.resolveTypeIfNeeded(
                        getContentResolver()), getOpPackageName(), user.getIdentifier());
        if (cn != null) {
            if (cn.getPackageName().equals("!")) {
                throw new SecurityException(
                        "Not allowed to start service " + service
                        + " without permission " + cn.getClassName());
            } else if (cn.getPackageName().equals("!!")) {
                throw new SecurityException(
                        "Unable to start service " + service
                        + ": " + cn.getClassName());
            }
        }
        return cn;
    } catch (RemoteException e) {
        throw new RuntimeException("Failure from system", e);
    }
}

在看了源码之后我们发现,这个方法的功能,其实跟Activity启动流程中Instrumentation类中的execStartActivity方法类似,看到这就感觉启动插件Service已经十拿九稳了,我们已经跨出了很大的一步,我们继续来深入研究Service的启动流程的源码:

ActiveServices.java

private final String bringUpServiceLocked(ServiceRecord r, int intentFlags, boolean execInFg,
        boolean whileRestarting) throws TransactionTooLargeException {
    if (r.app != null && r.app.thread != null) {
        sendServiceArgsLocked(r, execInFg, false);//如果Service已启动,在这里会直接调用Service的onStartCommand方法
        return null;
    }

    if (!whileRestarting && r.restartDelay > 0) {
        // If waiting for a restart, then do nothing.
        return null;
    }

    if (DEBUG_SERVICE) Slog.v(TAG_SERVICE, "Bringing up " + r + " " + r.intent);

    // We are now bringing the service up, so no longer in the
    // restarting state.
    if (mRestartingServices.remove(r)) {
        r.resetRestartCounter();
        clearRestartingIfNeededLocked(r);
    }

    // Make sure this service is no longer considered delayed, we are starting it now.
    if (r.delayed) {
        if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE, "REM FR DELAY LIST (bring up): " + r);
        getServiceMap(r.userId).mDelayedStartList.remove(r);
        r.delayed = false;
    }

    // Make sure that the user who owns this service is started.  If not,
    // we don‘t want to allow it to run.
    if (mAm.mStartedUsers.get(r.userId) == null) {
        String msg = "Unable to launch app "
                + r.appInfo.packageName + "/"
                + r.appInfo.uid + " for service "
                + r.intent.getIntent() + ": user " + r.userId + " is stopped";
        Slog.w(TAG, msg);
        bringDownServiceLocked(r);
        return msg;
    }

    // Service is now being launched, its package can‘t be stopped.
    try {
        AppGlobals.getPackageManager().setPackageStoppedState(
                r.packageName, false, r.userId);
    } catch (RemoteException e) {
    } catch (IllegalArgumentException e) {
        Slog.w(TAG, "Failed trying to unstop package "
                + r.packageName + ": " + e);
    }

    final boolean isolated = (r.serviceInfo.flags&ServiceInfo.FLAG_ISOLATED_PROCESS) != 0;
    final String procName = r.processName;
    ProcessRecord app;

    if (!isolated) {
        app = mAm.getProcessRecordLocked(procName, r.appInfo.uid, false);
        if (DEBUG_MU) Slog.v(TAG_MU, "bringUpServiceLocked: appInfo.uid=" + r.appInfo.uid
                    + " app=" + app);
        if (app != null && app.thread != null) {
            try {
                app.addPackage(r.appInfo.packageName, r.appInfo.versionCode, mAm.mProcessStats);
                realStartServiceLocked(r, app, execInFg); //这里会真正启动Service
                return null;
            } catch (TransactionTooLargeException e) {
                throw e;
            } catch (RemoteException e) {
                Slog.w(TAG, "Exception when starting service " + r.shortName, e);
            }

            // If a dead object exception was thrown -- fall through to
            // restart the application.
        }
    } else {
        // If this service runs in an isolated process, then each time
        // we call startProcessLocked() we will get a new isolated
        // process, starting another process if we are currently waiting
        // for a previous process to come up.  To deal with this, we store
        // in the service any current isolated process it is running in or
        // waiting to have come up.
        app = r.isolatedProc;
    }

    // Not running -- get it started, and enqueue this service record
    // to be executed when the app comes up.
    if (app == null) {
        if ((app=mAm.startProcessLocked(procName, r.appInfo, true, intentFlags,
                "service", r.name, false, isolated, false)) == null) {
            String msg = "Unable to launch app "
                    + r.appInfo.packageName + "/"
                    + r.appInfo.uid + " for service "
                    + r.intent.getIntent() + ": process is bad";
            Slog.w(TAG, msg);
            bringDownServiceLocked(r);
            return msg;
        }
        if (isolated) {
            r.isolatedProc = app;
        }
    }

    if (!mPendingServices.contains(r)) {
        mPendingServices.add(r);
    }

    if (r.delayedStop) {
        // Oh and hey we‘ve already been asked to stop!
        r.delayedStop = false;
        if (r.startRequested) {
            if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE,
                    "Applying delayed stop (in bring up): " + r);
            stopServiceLocked(r);
        }
    }

    return null;
}

private final void sendServiceArgsLocked(ServiceRecord r, boolean execInFg,
        boolean oomAdjusted) throws TransactionTooLargeException {
    ...

    while (r.pendingStarts.size() > 0) {
        ...
        try {
            ...
            r.app.thread.scheduleServiceArgs(r, si.taskRemoved, si.id, flags, si.intent);
        } catch (Exception e) {
        }
        ...
    }
    ...
}

private final void realStartServiceLocked(ServiceRecord r,
        ProcessRecord app, boolean execInFg) throws RemoteException {
    if (app.thread == null) {
        throw new RemoteException();
    }
    ...
    r.app = app;
    r.restartTime = r.lastActivity = SystemClock.uptimeMillis();

    final boolean newService = app.services.add(r);
    bumpServiceExecutingLocked(r, execInFg, "create");
    mAm.updateLruProcessLocked(app, false, null);
    mAm.updateOomAdjLocked();

    boolean created = false;
    try {
        if (LOG_SERVICE_START_STOP) {
            String nameTerm;
            int lastPeriod = r.shortName.lastIndexOf(‘.‘);
            nameTerm = lastPeriod >= 0 ? r.shortName.substring(lastPeriod) : r.shortName;
            EventLogTags.writeAmCreateService(
                    r.userId, System.identityHashCode(r), nameTerm, r.app.uid, r.app.pid);
        }
        synchronized (r.stats.getBatteryStats()) {
            r.stats.startLaunchedLocked();
        }
        mAm.ensurePackageDexOpt(r.serviceInfo.packageName);
        app.forceProcessStateUpTo(ActivityManager.PROCESS_STATE_SERVICE);
        app.thread.scheduleCreateService(r, r.serviceInfo,
                mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
                app.repProcState);// 类似Activity启动流程中的app.thread.scheduleLaunchActivity方法,在这里会new一个Service,并且调用attach以及onCreate方法
        r.postNotification();
        created = true;
    } catch (DeadObjectException e) {
        Slog.w(TAG, "Application dead when creating service " + r);
        mAm.appDiedLocked(app);
        throw e;
    } finally {
        if (!created) {
            // Keep the executeNesting count accurate.
            final boolean inDestroying = mDestroyingServices.contains(r);
            serviceDoneExecutingLocked(r, inDestroying, inDestroying);

            // Cleanup.
            if (newService) {
                app.services.remove(r);
                r.app = null;
            }

            // Retry.
            if (!inDestroying) {
                scheduleServiceRestartLocked(r, false);
            }
        }
    }

    requestServiceBindingsLocked(r, execInFg);

    updateServiceClientActivitiesLocked(app, null, true);

    // If the service is in the started state, and there are no
    // pending arguments, then fake up one so its onStartCommand() will
    // be called.
    if (r.startRequested && r.callStart && r.pendingStarts.size() == 0) {
        r.pendingStarts.add(new ServiceRecord.StartItem(r, false, r.makeNextStartId(),
                null, null));
    }

    sendServiceArgsLocked(r, execInFg, true);//第一次启动的Service,会在这里调用onStartCommand方法

    if (r.delayed) {
        if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE, "REM FR DELAY LIST (new proc): " + r);
        getServiceMap(r.userId).mDelayedStartList.remove(r);
        r.delayed = false;
    }

    if (r.delayedStop) {
        // Oh and hey we‘ve already been asked to stop!
        r.delayedStop = false;
        if (r.startRequested) {
            if (DEBUG_DELAYED_STARTS) Slog.v(TAG_SERVICE,
                    "Applying delayed stop (from start): " + r);
            stopServiceLocked(r);
        }
    }
}

ActivityThread.java

//ActivityThread$ApplicationThread
public final void scheduleServiceArgs(IBinder token, boolean taskRemoved, int startId,
    int flags ,Intent args) {
    ...
    sendMessage(H.SERVICE_ARGS, s);
}

public final void scheduleCreateService(IBinder token,
        ServiceInfo info, CompatibilityInfo compatInfo, int processState) {
    ...
    sendMessage(H.CREATE_SERVICE, s);
}

//ActivityThread$H
public void handleMessage(Message msg) {
    switch (msg.what) {
        case CREATE_SERVICE: {
            handleCreateService((CreateServiceData)msg.obj);
        } break;
        case SERVICE_ARGS: {
            handleServiceArgs((ServiceArgsData)msg.obj);
        } break;
    }
}

//ActivityThread
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();//这里和Activity的启动流程有些许区别
    } catch (Exception e) {
        if (!mInstrumentation.onException(service, e)) {
            throw new RuntimeException(
                "Unable to instantiate service " + data.info.name
                + ": " + e.toString(), e);
        }
    }

    try {
        if (localLOGV) Slog.v(TAG, "Creating service " + data.info.name);

        ContextImpl context = ContextImpl.createAppContext(this, packageInfo);
        context.setOuterContext(service);

        Application app = packageInfo.makeApplication(false, mInstrumentation);
        service.attach(context, this, data.info.name, data.token, app,
                ActivityManagerNative.getDefault());
        service.onCreate();//这里直接调用了onCreate,而没有类似的先调用callActivityOnCreate方法
        mServices.put(data.token, service);
        try {
            ActivityManagerNative.getDefault().serviceDoneExecuting(
                    data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
        } catch (RemoteException e) {
            // nothing to do.
        }
    } catch (Exception e) {
        if (!mInstrumentation.onException(service, e)) {
            throw new RuntimeException(
                "Unable to create service " + data.info.name
                + ": " + e.toString(), e);
        }
    }
}

private void handleServiceArgs(ServiceArgsData data) {
    Service s = mServices.get(data.token);
    if (s != null) {
        try {
            if (data.args != null) {
                data.args.setExtrasClassLoader(s.getClassLoader());
                data.args.prepareToEnterProcess();
            }
            int res;
            if (!data.taskRemoved) {
                res = s.onStartCommand(data.args, data.flags, data.startId);
            } else {
                s.onTaskRemoved(data.args);
                res = Service.START_TASK_REMOVED_COMPLETE;
            }

            QueuedWork.waitToFinish();

            try {
                ActivityManagerNative.getDefault().serviceDoneExecuting(
                        data.token, SERVICE_DONE_EXECUTING_START, data.startId, res);
            } catch (RemoteException e) {
                // nothing to do.
            }
            ensureJitEnabled();
        } catch (Exception e) {
            if (!mInstrumentation.onException(s, e)) {
                throw new RuntimeException(
                        "Unable to start service " + s
                        + " with " + data.args + ": " + e.toString(), e);
            }
        }
    }
}

看到这里,原生Service也启动起来了,我们发现Service的启动流程和Activity的类似,但又不完全一样,正是因为这些许差别,让我们的开发工作陷入了困境,遇到了下面这些“坑”:

1. Service不像Activity的标准模式,可以一直实例化,当某个Service启动后,从上面的代码可以看到,再次调用startService方法,源码中并不会去重新创建Service,调用onCreate,而是直接调用onStartCommand方法,所以我们不能通过StubService的方式来启动插件Service。

2. Service的handleCreateService方法不像在Activity启动流程中的performLaunchActivity方法中获取类名后,通过Instrumentation类的newActivity方法实例化,通过callActivityOnCreate方法间接调用Activity的onCreate,这样我们有机会通过重写DynamicInstrumentation类来扩展插件功能,而Service却直接在ActivityThread类中实例化,并且在attach方法结束后直接调用onCreate方法。

private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent) {
    ...
    Activity a = performLaunchActivity(r, customIntent);
    ...
}

private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
    ActivityInfo aInfo = r.activityInfo;
    if (r.packageInfo == null) {
        r.packageInfo = getPackageInfo(aInfo.applicationInfo, r.compatInfo,
                Context.CONTEXT_INCLUDE_CODE);
    }
    ...
    Activity activity = null;
    try {
        java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
        activity = mInstrumentation.newActivity(
                cl, component.getClassName(), r.intent);
        ...
    } catch (Exception e) {
        ...
    }

    try {
        ...
        if (activity != null) {
            ...
            activity.attach(appContext, this, getInstrumentation(), r.token,
                    r.ident, app, r.intent, r.activityInfo, title, r.parent,
                    r.embeddedID, r.lastNonConfigurationInstances, config,
                    r.referrer, r.voiceInteractor);
            ...
            if (r.isPersistable()) {
                mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
            } else {
                mInstrumentation.callActivityOnCreate(activity, r.state);
            }
            ...
        }
    } catch (Exception e) {
        ...
    }
    return activity;
}

上面那两个坑,恰恰是我们在实现从插件apk中启动Activity时所关注的点,似乎这些点在这里一个都用不上,前面跨出的一大步,感觉也是被打了回去,在接下来的几天里,我反复阅读源码,发现了其中的一个关键点,插件中的Service是使用插件的ClassLoader通过类名来加载的,那我们可以在ClassLoader上做一些“手脚”。

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) {
        ...
    }
    ...
}

public final LoadedApk getPackageInfoNoCheck(ApplicationInfo ai,
        CompatibilityInfo compatInfo) {
    return getPackageInfo(ai, compatInfo, null, false, true, false);
}

private LoadedApk getPackageInfo(ApplicationInfo aInfo, CompatibilityInfo compatInfo,
        ClassLoader baseLoader, boolean securityViolation, boolean includeCode,
        boolean registerPackage) {
    ...
    synchronized (mResourcesManager) {
        WeakReference<LoadedApk> ref;
        if (differentUser) {
            // Caching not supported across users
            ref = null;
        } else if (includeCode) {
            ref = mPackages.get(aInfo.packageName);//宿主apk的LoadApk保存在mPackages中
        } else {
            ref = mResourcePackages.get(aInfo.packageName);
        }

        LoadedApk packageInfo = ref != null ? ref.get() : null;
        if (packageInfo == null || (packageInfo.mResources != null
                && !packageInfo.mResources.getAssets().isUpToDate())) {
            if (localLOGV) Slog.v(TAG, (includeCode ? "Loading code package "
                    : "Loading resource-only package ") + aInfo.packageName
                    + " (in " + (mBoundApplication != null
                            ? mBoundApplication.processName : null)
                    + ")");
            packageInfo =
                new LoadedApk(this, aInfo, compatInfo, baseLoader,
                        securityViolation, includeCode &&
                        (aInfo.flags&ApplicationInfo.FLAG_HAS_CODE) != 0, registerPackage);

            if (mSystemThread && "android".equals(aInfo.packageName)) {
                packageInfo.installSystemApplicationInfo(aInfo,
                        getSystemContext().mPackageInfo.getClassLoader());
            }

            if (differentUser) {
                // Caching not supported across users
            } else if (includeCode) {
                mPackages.put(aInfo.packageName,
                        new WeakReference<LoadedApk>(packageInfo));
            } else {
                mResourcePackages.put(aInfo.packageName,
                        new WeakReference<LoadedApk>(packageInfo));
            }
        }
        return packageInfo;
    }
}

看到这个点之后,感觉像是抓住一个救命稻草那样兴奋,我们可以在每次安装一个插件apk的同时将插件apk的ClassLoader安装到mPackages.get(“host package name”)中,这样就可以不做其他的修改,根据插件apk中的Service类名就可以加载TargetService了,同时细心的读者也会发现,其实Activity,BroadcastReceiver,ContentProvider也是通过这样的方式加载的,真是一劳永逸呢。

DynamicClassLoaderWrapper.java

package com.ximsfei.dynamic.app;

import java.util.ArrayList;

/**
 * Created by pengfenx on 3/15/2016.
 */
public class DynamicClassLoaderWrapper extends ClassLoader {
    private final ClassLoader mBase;
    private final ArrayList<ClassLoader> mDynamicLoaders = new ArrayList<>();

    protected DynamicClassLoaderWrapper(ClassLoader base) {
        super();
        mBase = base;
    }

    public void addClassLoader(ClassLoader cl) {
        if (!mDynamicLoaders.contains(cl)) {
            mDynamicLoaders.add(cl);
        }
    }

    @Override
    protected Class<?> findClass(String className) throws ClassNotFoundException {
        try {
            return mBase.loadClass(className);
        } catch (ClassNotFoundException e) {
        }

        int N = mDynamicLoaders.size();
        for (int i=0; i<N; i++) {
            try {
                return mDynamicLoaders.get(i).loadClass(className);
            } catch (ClassNotFoundException e) {
            }//这里用try catch来判断该插件中是否存在TargetService不是很好
        }
        throw new ClassNotFoundException(className);
    }

}

安装ClassLoader:

public synchronized void installClassLoader(ClassLoader classLoader) {
    Object loadedApk = ((WeakReference) getPackages().get(getHostPackageName())).get();
    try {
        ClassLoader cl = Reflect.create(loadedApk.getClass())
                .setMethod("getClassLoader").invoke(loadedApk);
        if (!(cl instanceof DynamicClassLoaderWrapper)) {
            DynamicClassLoaderWrapper dclw = new DynamicClassLoaderWrapper(cl);
            dclw.addClassLoader(classLoader);
            Reflect.create(loadedApk.getClass()).setField("mClassLoader")
                    .set(loadedApk, dclw);
        } else {
            ((DynamicClassLoaderWrapper) cl).addClassLoader(classLoader);
        }
    } catch (Exception e) {
    }
}

private synchronized Map getPackages() {
    if (mPackages == null) {
        try {
            mPackages = mActivityThreadReflect.setField("mPackages").get(currentActivityThread());
        } catch (Exception e) {
        }
    }
    return mPackages;
}

stopService, bindService, unbindService的流程与startService流程类似,并且不需要做过多的修改,在这里就不再分析了,有兴趣的读者可以自己去看一下源码,分析一下。

遗留问题

第一个坑中,Service只能启动一次,所以我们不能通过伪装成StubService的方式,来“骗过”AndroidManifest的检测,我也没有想到更好的方法来实现,暂时只能将要使用的Service类名注册到宿主apk的AndroidManifest中来实现,如果读者有什么好的方法,可以分享出来一起学习一下。

时间: 2024-12-12 16:06:42

Android动态部署五:如何从插件apk中启动Service的相关文章

Android动态部署五:怎样从插件apk中启动Service

转载请注明出处:http://blog.csdn.net/ximsfei/article/details/51072332 github地址:https://github.com/ximsfei/DynamicDeploymentApk Android动态部署一:Google原生Split APK浅析 Android动态部署二:APK安装及AndroidManifest.xml解析流程分析 Android动态部署三:怎样从插件apk中启动Activity(一) Android动态部署四:怎样从插

Android插件化开发---运行未安装apk中的Service

如果你还不知道什么叫插件化开发,那么你应该先读一读之前写的这篇博客:Android插件化开发,初入殿堂 上一篇博客主要从整体角度分析了一下Android插件化开发的几个难点与动态加载没有被安装的apk中的Activity和资源的方法.其实一般的插件开发主要也就是加载个Activity,读取一些资源图片之类的.但是总有遇到特殊情况的时候,比如加载Service. 要动态加载Service,有两种思路:一是通过NDK的形式,将Service通过C++运行起来(这种方法我没有尝试,只听群里的朋友说实现

Android插件化(三)加载插件apk中的Resource资源

Android加载插件apk中的Resource资源 简介 如何加载未安装apk中的资源文件呢?我们从android.content.res.AssetManager.java的源码中发现,它有一个私有方法addAssetPath,只需要将apk的路径作为参数传入,我们就可以获得对应的AssetsManager对象,然后我们就可以使用AssetsManager对象,创建一个Resources对象,然后就可以从Resource对象中访问apk中的资源了.总结如下: 1.新建一个AssetManag

(转)从android一个apk中启动第三方apk应用

从android一个apk中启动第三方apk应用 我们在开发中,经常遇到遇到在一个apk中要去运行另外一个apk,就像我们windows一样,搞一个快捷方式一样,那怎么实现呢? 问题的核心点在于我们要拿到第三方apk的package名称跟class名称,这两个至关重要!比如笔者做测试用的qq apk,package名称是com.tencent.pad.qq,class名称是com.tencent.pad.qq.login.QQLoginActivity.从一个apk启动到另外一个apk,当然也是

Android动态加载技术(插件化技术)

No1: 插件化技术的好处: 1)减轻应用的内存和CPU占用 2)实现热插拔,即在不发布新版本的情况下更新某些模块 No2: 插件化方案必须要解决三个基础性问题:资源访问.Activity生命周期的管理和ClassLoader的管理 No3: 宿主是指普通的apk,插件一般指经过处理的dex或者apk.插件化框架大多采用apk作为插件,很多需要用到代理Activity,插件Activity的启动大多数是借助一个代理Activity来实现的. No4: Activity的工作主要是通过Contex

Android开发之AIDL的使用一--跨应用启动Service

启动其他App的服务,跨进程启动服务. 与启动本应用的Service一样,使用startService(intent)方法 不同的是intent需要携带的内容不同,需要使用intent的setComponent()方法. setComponent()方法需要传入两个参数,第一个参数是包名,第二个参数是组件名.即,第一个参数传入要启动的其他app的包名,第二个参数传入的时候要启动的其他app的service名. 看下面的例子:(aidlserviceapp应用通过button启动aidlservi

Android 使用动态载入框架DL进行插件化开发

如有转载,请声明出处: 时之沙: http://blog.csdn.net/t12x3456    (来自时之沙的csdn博客) 概述: 随着应用的不断迭代.应用的体积不断增大,项目越来越臃肿,冗余添加.项目新功能的加入,无法确定与用户匹配性,发生严重异常往往牵一发而动全身,仅仅能紧急公布补丁版本号.强制用户进行更新.结果频繁的更新,反而容易减少用户使用黏性.或者是公司业务的不断发展,同系的应用越来越多,传统方式须要通过用户量最大的主项目进行引导下载并安装. 怎么办? 參考浏览器-插件开发模式:

android动态加载已安装apk中的方法

在android开发中,有很多时候是需要用到动态加载的,今天学习在android中动态加载已安装的apk中的方法. 首先,我们需要新建一个用来被加载的android工程,暂且给他取名叫做:plugproj 在plugproj中新建一个类Dynamic,在这个类中,我们新建一些方法,等会我们会分别在该工程安装和没有安装的情况下加载这些方法,Dynamic.java如下: package com.example.plugproj; import android.app.Activity; impor

Android动态加载那些事儿

基础 1.Java 类加载器 类加载器(class loader)是 Java?中的一个很重要的概念.类加载器负责加载 Java 类的字节代码到 Java 虚拟机中.本文首先详细介绍了 Java 类加载器的基本概念,包括代理模式.加载类的具体过程和线程上下文类加载器等,接着介绍如何开发自己的类加载器,最后介绍了类加载器在 Web 容器和 OSGi?中的应用. 2.反射原理 Java 提供的反射機制允許您於執行時期動態載入類別.檢視類別資訊.生成物件或操作生成的物件,要舉反射機制的一個應用實例,就