Android Launcher3中快捷方式无法卸载的坑（微信，
问题背景是以google原生Launcher3为基础，从中开发出和自家手机系统相匹配风格的launcher程序。开发过程中竟然发现微信创建的联系人快捷方式无法和微信APP同时卸载，APP被卸载后快捷方式依然存在，点击提示“未安装该应用。”。如图：
image.png
想解决此问题必须先弄清楚应用卸载后，桌面图标被删除的流程。弄清楚这一点，后面再看如何修复这个问题。
Launcher3应用卸载后桌面图标及快捷方式的删除流程
Launcher3中微信联系人快捷方式无法卸载的解决方案
微信的快捷键问题解决后，又发现了应用宝的快捷方式问题。在做测试系统fota升级时发现应用宝创建的快捷方式【手机管理】也无法删除，造成这个问题的原因是老的系统预装了应用宝，然后在桌面创建了【手机管理】的快捷方式，但是新的系统又移除了应用宝，换了其他应用市场，fota升级后相当于应用宝凭空消失，应用宝APP是没有了，但是它创建的快捷方式依然存在。如图：
image.png
要解决这个问题，必须弄清楚fota升级中，新系统里面移除了某一个应用，launcher是怎么监听或检测的？launcher里面肯定有什么机制会检测本地应用和桌面显示的是否一致，否则肯定会出问题。前面讲过卸载APP是会同时删除数据和图标，这个场景肯定是不会触发卸载流程的，我们就从launcher启动，数据加载入手，看看是否有验证机制。通过阅读源码，在Launcher.java中发现如下逻辑：
@Override
protected void onResume() {
............
mModel.startLoader(PagedView.INVALID_RESTORE_PAGE);
............
}
在onResume中调用了LauncherModel的startLoader方法启动数据加载。我们在看看startLoader中干了些什么：
public void startLoader(int synchronousBindPage) {
startLoader(synchronousBindPage, LOADER_FLAG_NONE);
}
public void startLoader(int synchronousBindPage, int loadFlags) {
// Enable queue before starting loader. It will get disabled in Launcher#finishBindingItems
InstallShortcutReceiver.enableInstallQueue();
synchronized (mLock) {
// Clear any deferred bind-runnables from the synchronized load process
// We must do this before any loading/binding is scheduled below.
synchronized (mDeferredBindRunnables) {
mDeferredBindRunnables.clear();
}
// Don't bother to start the thread if we know it's not going to do anything
if (mCallbacks != null && mCallbacks.get() != null) {
// If there is already one running, tell it to stop.
stopLoaderLocked();
mLoaderTask = new LoaderTask(mApp.getContext(), loadFlags);
if (synchronousBindPage != PagedView.INVALID_RESTORE_PAGE
&& mAllAppsLoaded && mWorkspaceLoaded && !mIsLoaderTaskRunning) {
mLoaderTask.runBindSynchronousPage(synchronousBindPage);
} else {
sWorkerThread.setPriority(Thread.NORM_PRIORITY);
sWorker.post(mLoaderTask);
}
}
}
}
startLoader方法中启动了一个叫LoaderTask的线程，接下来我们看看这个线程干了些什么？
private class LoaderTask implements Runnable {
.......
public void run() {
......
// Optimize for end-user experience: if the Launcher is up and // running with the
// All Apps interface in the foreground, load All Apps first. Otherwise, load the
// workspace first (default).
keep_running: {
if (DEBUG_LOADERS) Log.d(TAG, "step 1: loading workspace");
loadAndBindWorkspace();//加载和绑定数据到Workspace
if (mStopped) {
break keep_running;
}
waitForIdle();
// second step
if (DEBUG_LOADERS) Log.d(TAG, "step 2: loading all apps");
loadAndBindAllApps();//加载和绑定数据到所有app界面
}
......
}
.......
}
这个线程主是加载及绑定数据，那会不会是在这个数据加载过程中有什么检查机制？我们带着这个疑问来看看loadAndBindWorkspace干了些什么？
private void loadAndBindWorkspace() {
mIsLoadingAndBindingWorkspace = true;
// Load the workspace
if (DEBUG_LOADERS) {
Log.d(TAG, "loadAndBindWorkspace mWorkspaceLoaded=" + mWorkspaceLoaded);
}
if (!mWorkspaceLoaded) {
loadWorkspace();//加载数据
synchronized (LoaderTask.this) {
if (mStopped) {
return;
}
mWorkspaceLoaded = true;
}
}
// Bind the workspace
bindWorkspace(-1);//绑定数据
}
这里先加载了数据，然后再把数据绑定到了Workspace上，我们再看看loadWorkspace方法中做了些什么？
private void loadWorkspace() {
.......
final ArrayList<Long> itemsToRemove = new ArrayList<Long>();//需要移除的集合
.......
if (user == null) {
// User has been deleted remove the item.
itemsToRemove.add(id);
continue;
}
try {
intent = Intent.parseUri(intentDescription, 0);
ComponentName cn = intent.getComponent();
if (cn != null && cn.getPackageName() != null) {//判断是否有ComponentName对象且包名不为null
boolean validPkg = launcherApps.isPackageEnabledForProfile(
cn.getPackageName(), user);//根据包名检测此包是否可用
boolean validComponent = validPkg &&
launcherApps.isActivityEnabledForProfile(cn, user);//根据ComponentName检测是否可用
if (validComponent) {
.......
} else if (validPkg) {
.......
intent = manager.getLaunchIntentForPackage(cn.getPackageName());
.......
if (intent == null) {
// The app is installed but the component is no
// longer available.
Launcher.addDumpLog(TAG,
"Invalid component removed: " + cn, true);
itemsToRemove.add(id);//添加到移除列表
continue;
}
.......
} else if (restored) {
.......
itemsToRemove.add(id);//添加到移除列表
.......
} else if (REMOVE_UNRESTORED_ICONS) {
Launcher.addDumpLog(TAG,
"Unrestored package removed: " + cn, true);
itemsToRemove.add(id);//添加到移除列表
continue;
}
} else if (launcherApps.isAppEnabled(
manager, cn.getPackageName(),
PackageManager.GET_UNINSTALLED_PACKAGES)) {
.......
} else if (!isSdCardReady) {
.......
} else {
// Do not wait for external media load anymore.
// Log the invalid package, and remove it
Launcher.addDumpLog(TAG,
"Invalid package removed: " + cn, true);
itemsToRemove.add(id);//添加到移除列表
continue;
}
} else if (cn == null) {
// For shortcuts with no component, keep them as they are
restoredRows.add(id);
restored = false;
}
} catch (URISyntaxException e) {
Launcher.addDumpLog(TAG,
"Invalid uri: " + intentDescription, true);
itemsToRemove.add(id);//添加到移除列表
continue;
}
.......
if (itemsToRemove.size() > 0) {//删除数据库和缓存中的数据
// Remove dead items
contentResolver.delete(LauncherSettings.Favorites.CONTENT_URI,
Utilities.createDbSelectionQuery(
LauncherSettings.Favorites._ID, itemsToRemove), null);
if (DEBUG_LOADERS) {
Log.d(TAG, "Removed = " + Utilities.createDbSelectionQuery(
LauncherSettings.Favorites._ID, itemsToRemove));
}
// Remove any empty folder
for (long folderId : LauncherAppState.getLauncherProvider()
.deleteEmptyFolders()) {
sBgWorkspaceItems.remove(sBgFolders.get(folderId));
sBgFolders.remove(folderId);
sBgItemsIdMap.remove(folderId);
}
}
........
}
此方法很长，代码只摘抄了少许关键部分，它主要是把数据从数据库读取出来，然后循环检测这个数据是否有效，无效则把数据存到itemsToRemove列表，然后在末尾整体从数据库和缓存中删除数据。
至此我们清楚了launcher启动后对应用的检测机制，那么这个fota升级后快捷方式还在的问题具体是在哪一步出了问题呢？有了前面微信联系人快捷方式卸载的解决经验，我首先想到的是不是应用宝的快捷方式也是一样没有componentName信息，通过获取数据库中数据可以看到如下信息：
tmast://mobilemanage#Intent;launchFlags=0x4000000;B.is_from_push_click=true;i.preActivityTagName=204006;end
通过信息可以看到，不仅没有componentName，就连package都没有，对应的Intent对象数据如下：
Intent { act=android.intent.action.VIEW dat=tmast://mobilemanage flg=0x4000000 (has extras) }
果然不出意外，问题出在快捷方式的数据上。前面在看loadWorkspace源码时，我们知道它对应用是否有效的检测也是先判断是否有ComponentName对象，如果没有，它做了什么处理呢？
ComponentName cn = intent.getComponent();
if (cn != null && cn.getPackageName() != null) {
.............
} else if (cn == null) {
// For shortcuts with no component, keep them as they are
restoredRows.add(id);
restored = false;
}
当ComponentName为null时，它并没有检测这个应用是否有效，也没有加入itemsToRemove列表中，就是因为这里导致这个本不应该存在的图标依然显示在桌面上。知道原因后，修改如下：
if (cn == null) {
//如果cn为空，则查询系统是否有支持此intent的activity，如果没有则认为此条记录是无效的，然后删除它
cn = intent.resolveActivity(context.getPackageManager());
if (cn == null) {//没有此启动项，则视为无效Shortcut，直接删除
itemsToRemove.add(id);
continue;
} else {
// For shortcuts with no component, keep them as they are
restoredRows.add(id);
restored = false;
}
}
通过Intent检测是否有支持的Activity，如果没有则把此条记录加入itemsToRemove列表，然后执行删除逻辑。这样应用宝的快捷方式残留问题已解决。
