APP開發中經常會有這種需求：在瀏覽器或者短信中喚起APP，如果安裝了就喚起，否則引導下載。對於Android而言，這里主要牽扯的技術就是deeplink，也可以簡單看成scheme，Android一直是支持scheme的，但是由於Android的開源特性，不同手機廠商或者不同瀏覽器廠家處理的千奇百怪，有些能拉起，有些不行，本文只簡單分析下link的原理，包括deeplink，也包括Android6.0之后的AppLink。其實個人認為，AppLink就是特殊的deeplink，只不過它多了一種類似於驗證機制，如果驗證通過，就設置默認打開，如果驗證不過，則退化為deeplink，如果單從APP端來看，區別主要在Manifest文件中的android:autoVerify="true"，如下，
APPLINK只是在安裝時候多了一個驗證，其他跟之前deeplink一樣，如果沒聯網，驗證失敗，那就跟之前的deeplink表現一樣
deeplink配置（不限http/https）
<intent-filter> <data android:scheme="https" android:host="test.example.com" /> <category android:name="android.intent.category.DEFAULT" /> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.BROWSABLE" /> </intent-filter> （不限http/https） <intent-filter> <data android:scheme="example" /> <!-- 下面這幾行也必須得設置 --> <category android:name="android.intent.category.DEFAULT" /> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.BROWSABLE" /> </intent-filter>
applink配置（只能http/https）
<intent-filter android:autoVerify="true"> <data android:scheme="https" android:host="test.example.com" /> <category android:name="android.intent.category.DEFAULT" /> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.BROWSABLE" /> </intent-filter>
果如果APPLink驗證失敗，APPLink會完全退化成deepLink，這也是為什么說APPLINK是一種特殊的deepLink，所以先分析下deepLink，deepLink理解了，APPLink就很容易理解。
deepLink原理分析
deeplink的scheme相應分兩種：一種是只有一個APP能相應，另一種是有多個APP可以相應，比如，如果為一個APP的Activity配置了http scheme類型的deepLink，如果通過短信或者其他方式喚起這種link的時候，一般會出現一個讓用戶選擇的彈窗，因為一般而言，系統會帶個瀏覽器，也相應這類scheme，比如下面的例子：
<intent-filter> <data android:scheme="https" android:host="test.example.com" /> <category android:name="android.intent.category.DEFAULT" /> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.BROWSABLE" /> </intent-filter>
如果是設置了一個私用的，並且沒有跟其他app重復的，那么會直接打開，比如下面的：
<intent-filter> <data android:scheme="example" /> <!-- 下面這幾行也必須得設置 --> <category android:name="android.intent.category.DEFAULT" /> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.BROWSABLE" /> </intent-filter>
當然，如果私有scheme跟其他APP的重復了，還是會喚起APP選擇界面（其實是一個ResolverActivity）。下面就來看看scheme是如何匹配並拉起對應APP的。
startActivity入口與ResolverActivity
無論APPLink跟DeepLink其實都是通過喚起一個Activity來實現界面的跳轉，無論從APP外部：比如短信、瀏覽器，還是APP內部。通過在APP內部模擬跳轉來看看具體實現，寫一個H5界面，然后通過Webview加載，不過Webview不進行任何設置，這樣跳轉就需要系統進行解析，走deeplink這一套：
<html> <body> <a href="https://test.example.com/a/g">Scheme跳轉</a> </body> </html>
點擊Scheme跳轉，一般會喚起如下界面，讓用戶選擇打開方式：
果通過adb打印log，你會發現ActivityManagerService會打印這樣一條Log：
> 12-04 20:32:04.367 887 9064 I ActivityManager: START u0 {act=android.intent.action.VIEW dat=https://test.example.com/... cmp=android/com.android.internal.app.ResolverActivity (has extras)} from uid 10067 on display 0
其實看到的選擇對話框就是ResolverActivity，不過我們先來看看到底是走到ResolverActivity的，也就是這個scheme怎么會喚起App選擇界面，在短信中，或者Webview中遇到scheme，他們一般會發出相應的Intent（當然第三方APP可能會屏蔽掉，比如微信就換不起APP），其實上面的作用跟下面的代碼結果一樣：
val intent = Intent() intent.setAction("android.intent.action.VIEW") intent.setData(Uri.parse("https://test.example.com/a/g")) intent.addCategory("android.intent.category.DEFAULT") intent.addCategory("android.intent.category.BROWSABLE") startActivity(intent)
那剩下的就是看startActivity，在6.0的源碼中，startActivity最后會通過ActivityManagerService調用ActivityStatckSupervisor的startActivityMayWait
ActivityStatckSUpervisor
final int startActivityMayWait(IApplicationThread caller, int callingUid, String callingPackage, Intent intent, String resolvedType, IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor, IBinder resultTo, String resultWho, int requestCode, int startFlags, ProfilerInfo profilerInfo, WaitResult outResult, Configuration config, Bundle options, boolean ignoreTargetSecurity, int userId, IActivityContainer iContainer, TaskRecord inTask) { ... boolean componentSpecified = intent.getComponent() != null; //創建新的Intent對象，即便intent被修改也不受影響 intent = new Intent(intent); //收集Intent所指向的Activity信息, 當存在多個可供選擇的Activity,則直接向用戶彈出resolveActivity [見2.7.1] ActivityInfo aInfo = resolveActivity(intent, resolvedType, startFlags, profilerInfo, userId); ... }
startActivityMayWait會通過resolveActivity先找到目標Activity，這個過程中，可能找到多個匹配的Activity，這就是ResolverActivity的入口：
ActivityInfo resolveActivity(Intent intent, String resolvedType, int startFlags, ProfilerInfo profilerInfo, int userId) { // Collect information about the target of the Intent. ActivityInfo aInfo; try { ResolveInfo rInfo = AppGlobals.getPackageManager().resolveIntent( intent, resolvedType, PackageManager.MATCH_DEFAULT_ONLY | ActivityManagerService.STOCK_PM_FLAGS, userId); aInfo = rInfo != null ? rInfo.activityInfo : null; } catch (RemoteException e) { aInfo = null; }
可以認為，所有的四大組件的信息都在PackageManagerService中有登記，想要找到這些類，就必須向PackagemanagerService查詢
PackageManagerService
@Override public ResolveInfo resolveIntent(Intent intent, String resolvedType, int flags, int userId) { if (!sUserManager.exists(userId)) return null; enforceCrossUserPermission(Binder.getCallingUid(), userId, false, false, "resolve intent"); List<ResolveInfo> query = queryIntentActivities(intent, resolvedType, flags, userId); return chooseBestActivity(intent, resolvedType, flags, query, userId); }
PackageManagerService會通過queryIntentActivities找到所有適合的Activity，再通過chooseBestActivity提供選擇的權利。這里分如下三種情況：
- 僅僅找到一個，直接啟動
- 找到了多個，並且設置了其中一個為默認啟動，則直接啟動相應Acitivity
- 找到了多個，切沒有設置默認啟動，則啟動ResolveActivity供用戶選擇
關於如何查詢，匹配的這里不詳述，僅僅簡單看看如何喚起選擇頁面，或者默認打開，比較關鍵的就是chooseBestActivity
private ResolveInfo chooseBestActivity(Intent intent, String resolvedType, int flags, List<ResolveInfo> query, int userId) { <!--查詢最好的Activity--> ResolveInfo ri = findPreferredActivity(intent, resolvedType, flags, query, r0.priority, true, false, debug, userId); if (ri != null) { return ri; } ... } ResolveInfo findPreferredActivity(Intent intent, String resolvedType, int flags, List<ResolveInfo> query, int priority, boolean always, boolean removeMatches, boolean debug, int userId) { if (!sUserManager.exists(userId)) return null; // writer synchronized (mPackages) { if (intent.getSelector() != null) { intent = intent.getSelector(); } <!--如果用戶已經選擇過默認打開的APP，則這里返回的就是相對應APP中的Activity--> ResolveInfo pri = findPersistentPreferredActivityLP(intent, resolvedType, flags, query, debug, userId); if (pri != null) { return pri; } <!--找Activity--> PreferredIntentResolver pir = mSettings.mPreferredActivities.get(userId); ... final ActivityInfo ai = getActivityInfo(pa.mPref.mComponent, flags | PackageManager.GET_DISABLED_COMPONENTS, userId); ... } @Override public ActivityInfo getActivityInfo(ComponentName component, int flags, int userId) { if (!sUserManager.exists(userId)) return null; enforceCrossUserPermission(Binder.getCallingUid(), userId, false, false, "get activity info"); synchronized (mPackages) { ... <!--弄一個ResolveActivity的ActivityInfo--> if (mResolveComponentName.equals(component)) { return PackageParser.generateActivityInfo(mResolveActivity, flags, new PackageUserState(), userId); } } return null; }
其實上述流程比較復雜，這里只是自己簡單猜想下流程，找到目標Activity后，無論是真的目標Acitiviy，還是ResolveActivity，都會通過startActivityLocked繼續走啟動流程，這里就會看到之前打印的Log信息：
ActivityStatckSUpervisor
final int startActivityLocked(IApplicationThread caller...{ if (err == ActivityManager.START_SUCCESS) { Slog.i(TAG, "START u" + userId + " {" + intent.toShortString(true, true, true, false) + "} from uid " + callingUid + " on display " + (container == null ? (mFocusedStack == null ? Display.DEFAULT_DISPLAY : mFocusedStack.mDisplayId) : (container.mActivityDisplay == null ? Display.DEFAULT_DISPLAY : container.mActivityDisplay.mDisplayId))); }
如果是ResolveActivity還會根據用戶選擇的信息將一些設置持久化到本地，這樣下次就可以直接啟動用戶的偏好App。其實以上就是deeplink的原理，說白了一句話：scheme就是隱式啟動Activity，如果能找到唯一或者設置的目標Acitivity則直接啟動，如果找到多個，則提供APP選擇界面。
AppLink原理
一般而言，每個APP都希望被自己制定的scheme喚起，這就是Applink，之前分析deeplink的時候提到了ResolveActivity這么一個選擇過程，而AppLink就是自動幫用戶完成這個選擇過程，並且選擇的scheme是最適合它的scheme（開發者的角度）。因此對於AppLink要分析的就是如何完成了這個默認選擇的過程。
目前Android源碼提供的是一個雙向認證的方案：在APP安裝的時候，客戶端根據APP配置像服務端請求，如果滿足條件，scheme跟服務端配置匹配的上，就為APP設置默認啟動選項，所以這個方案很明顯，在安裝的時候需要聯網才行，否則就是完全不會驗證，那就是普通的deeplink，既然是在安裝的時候去驗證，那就看看PackageManagerService是如何處理這個流程的：
private void installPackageLI(InstallArgs args, PackageInstalledInfo res) { final int installFlags = args.installFlags; <!--開始驗證applink--> startIntentFilterVerifications(args.user.getIdentifier(), replace, pkg); ... } private void startIntentFilterVerifications(int userId, boolean replacing, PackageParser.Package pkg) { if (mIntentFilterVerifierComponent == null) { return; } final int verifierUid = getPackageUid( mIntentFilterVerifierComponent.getPackageName(), (userId == UserHandle.USER_ALL) ? UserHandle.USER_OWNER : userId); mHandler.removeMessages(START_INTENT_FILTER_VERIFICATIONS); final Message msg = mHandler.obtainMessage(START_INTENT_FILTER_VERIFICATIONS); msg.obj = new IFVerificationParams(pkg, replacing, userId, verifierUid); mHandler.sendMessage(msg); }
startIntentFilterVerifications發送一個消息開啟驗證，隨后調用verifyIntentFiltersIfNeeded進行驗證
private void verifyIntentFiltersIfNeeded(int userId, int verifierUid, boolean replacing, PackageParser.Package pkg) { ... <!--檢查是否有Activity設置了AppLink--> final boolean hasDomainURLs = hasDomainURLs(pkg); if (!hasDomainURLs) { if (DEBUG_DOMAIN_VERIFICATION) Slog.d(TAG, "No domain URLs, so no need to verify any IntentFilter!"); return; } <!--是否autoverigy--> boolean needToVerify = false; for (PackageParser.Activity a : pkg.activities) { for (ActivityIntentInfo filter : a.intents) { <!--needsVerification是否設置autoverify --> if (filter.needsVerification() && needsNetworkVerificationLPr(filter)) { needToVerify = true; break; } } } <!--如果有搜集需要驗證的Activity信息及scheme信息--> if (needToVerify) { final int verificationId = mIntentFilterVerificationToken++; for (PackageParser.Activity a : pkg.activities) { for (ActivityIntentInfo filter : a.intents) { if (filter.handlesWebUris(true) && needsNetworkVerificationLPr(filter)) { if (DEBUG_DOMAIN_VERIFICATION) Slog.d(TAG, "Verification needed for IntentFilter:" + filter.toString()); mIntentFilterVerifier.addOneIntentFilterVerification( verifierUid, userId, verificationId, filter, packageName); count++; } } } } } <!--開始驗證--> if (count > 0) { mIntentFilterVerifier.startVerifications(userId); } }
以看出，驗證就三步：檢查、搜集、驗證。在檢查階段，首先看看是否有設置http/https scheme的Activity，並且是否滿足設置了Intent.ACTION_DEFAULT與Intent.ACTION_VIEW，如果沒有，則壓根不需要驗證
private static boolean hasDomainURLs(Package pkg) { if (pkg == null || pkg.activities == null) return false; final ArrayList<Activity> activities = pkg.activities; final int countActivities = activities.size(); for (int n=0; n<countActivities; n++) { Activity activity = activities.get(n); ArrayList<ActivityIntentInfo> filters = activity.intents; if (filters == null) continue; final int countFilters = filters.size(); for (int m=0; m<countFilters; m++) { ActivityIntentInfo aii = filters.get(m); // 必須設置Intent.ACTION_VIEW 必須設置有ACTION_DEFAULT 必須要有SCHEME_HTTPS或者SCHEME_HTTP，查到一個就可以 if (!aii.hasAction(Intent.ACTION_VIEW)) continue; if (!aii.hasAction(Intent.ACTION_DEFAULT)) continue; if (aii.hasDataScheme(IntentFilter.SCHEME_HTTP) || aii.hasDataScheme(IntentFilter.SCHEME_HTTPS)) { return true; } } } return false; }
檢查的第二步試看看是否設置了autoverify，當然中間還有些是否設置過，用戶是否選擇過的操作，比較復雜，不分析，不過不影響對流程的理解：
public final boolean needsVerification() { return getAutoVerify() && handlesWebUris(true); } public final boolean getAutoVerify() { return ((mVerifyState & STATE_VERIFY_AUTO) == STATE_VERIFY_AUTO); }
只要找到一個滿足以上條件的Activity，就開始驗證。如果想要開啟applink，Manifest中配置必須像下面這樣
<intent-filter android:autoVerify="true"> <data android:scheme="https" android:host="xxx.com" /> <data android:scheme="http" android:host="xxx.com" /> <!--外部intent打開，比如短信，文本編輯等--> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter>
搜集其實就是搜集intentfilter信息，下面直接看驗證過程
@Override public void startVerifications(int userId) { ... sendVerificationRequest(userId, verificationId, ivs); } mCurrentIntentFilterVerifications.clear(); } private void sendVerificationRequest(int userId, int verificationId, IntentFilterVerificationState ivs) { Intent verificationIntent = new Intent(Intent.ACTION_INTENT_FILTER_NEEDS_VERIFICATION); verificationIntent.putExtra( PackageManager.EXTRA_INTENT_FILTER_VERIFICATION_ID, verificationId); verificationIntent.putExtra( PackageManager.EXTRA_INTENT_FILTER_VERIFICATION_URI_SCHEME, getDefaultScheme()); verificationIntent.putExtra( PackageManager.EXTRA_INTENT_FILTER_VERIFICATION_HOSTS, ivs.getHostsString()); verificationIntent.putExtra( PackageManager.EXTRA_INTENT_FILTER_VERIFICATION_PACKAGE_NAME, ivs.getPackageName()); verificationIntent.setComponent(mIntentFilterVerifierComponent); verificationIntent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND); UserHandle user = new UserHandle(userId); mContext.sendBroadcastAsUser(verificationIntent, user); }
目前Android的實現是通過發送一個廣播來進行驗證的，也就是說，這是個異步的過程，驗證是需要耗時的（網絡請求），所以安裝后，一般要等個幾秒Applink才能生效，廣播的接受處理者是：IntentFilterVerificationReceiver
public final class IntentFilterVerificationReceiver extends BroadcastReceiver { private static final String TAG = IntentFilterVerificationReceiver.class.getSimpleName(); ... @Override public void onReceive(Context context, Intent intent) { final String action = intent.getAction(); if (Intent.ACTION_INTENT_FILTER_NEEDS_VERIFICATION.equals(action)) { Bundle inputExtras = intent.getExtras(); if (inputExtras != null) { Intent serviceIntent = new Intent(context, DirectStatementService.class); serviceIntent.setAction(DirectStatementService.CHECK_ALL_ACTION); ... serviceIntent.putExtras(extras); context.startService(serviceIntent); }
ntentFilterVerificationReceiver收到驗證消息后，通過start一個DirectStatementService進行驗證，兜兜轉轉最終調用IsAssociatedCallable的verifyOneSource
private class IsAssociatedCallable implements Callable<Void> { ... private boolean verifyOneSource(AbstractAsset source, AbstractAssetMatcher target, Relation relation) throws AssociationServiceException { Result statements = mStatementRetriever.retrieveStatements(source); for (Statement statement : statements.getStatements()) { if (relation.matches(statement.getRelation()) && target.matches(statement.getTarget())) { return true; } } return false; }
IsAssociatedCallable會逐一對需要驗證的intentfilter進行驗證，具體是通過DirectStatementRetriever的retrieveStatements來實現：
Override public Result retrieveStatements(AbstractAsset source) throws AssociationServiceException { if (source instanceof AndroidAppAsset) { return retrieveFromAndroid((AndroidAppAsset) source); } else if (source instanceof WebAsset) { return retrieveFromWeb((WebAsset) source); } else { .. } }
AndroidAppAsset好像是Google的另一套assetlink類的東西，好像用在APP web登陸信息共享之類的地方 ，不看，直接看retrieveFromWeb：從名字就能看出，這是獲取服務端Applink的配置，獲取后跟本地校驗，如果通過了，那就是applink啟動成功：
private Result retrieveStatementFromUrl(String urlString, int maxIncludeLevel, AbstractAsset source) throws AssociationServiceException { List<Statement> statements = new ArrayList<Statement>(); if (maxIncludeLevel < 0) { return Result.create(statements, DO_NOT_CACHE_RESULT); } WebContent webContent; try { URL url = new URL(urlString); if (!source.followInsecureInclude() && !url.getProtocol().toLowerCase().equals("https")) { return Result.create(statements, DO_NOT_CACHE_RESULT); } <!--通過網絡請求獲取配置--> webContent = mUrlFetcher.getWebContentFromUrlWithRetry(url, HTTP_CONTENT_SIZE_LIMIT_IN_BYTES, HTTP_CONNECTION_TIMEOUT_MILLIS, HTTP_CONNECTION_BACKOFF_MILLIS, HTTP_CONNECTION_RETRY); } catch (IOException | InterruptedException e) { return Result.create(statements, DO_NOT_CACHE_RESULT); } try { ParsedStatement result = StatementParser .parseStatementList(webContent.getContent(), source); statements.addAll(result.getStatements()); <!--如果有一對多的情況，或者說設置了“代理”，則循環獲取配置--> for (String delegate : result.getDelegates()) { statements.addAll( retrieveStatementFromUrl(delegate, maxIncludeLevel - 1, source) .getStatements()); } <!--發送結果--> return Result.create(statements, webContent.getExpireTimeMillis()); } catch (JSONException | IOException e) { return Result.create(statements, DO_NOT_CACHE_RESULT); } }
其實就是通過UrlFetcher獲取服務端配置，然后發給之前的receiver進行驗證:
public WebContent getWebContentFromUrl(URL url, long fileSizeLimit, int connectionTimeoutMillis) throws AssociationServiceException, IOException { final String scheme = url.getProtocol().toLowerCase(Locale.US); if (!scheme.equals("http") && !scheme.equals("https")) { throw new IllegalArgumentException("The url protocol should be on http or https."); } HttpURLConnection connection = null; try { connection = (HttpURLConnection) url.openConnection(); connection.setInstanceFollowRedirects(true); connection.setConnectTimeout(connectionTimeoutMillis); connection.setReadTimeout(connectionTimeoutMillis); connection.setUseCaches(true); connection.setInstanceFollowRedirects(false); connection.addRequestProperty("Cache-Control", "max-stale=60"); ... return new WebContent(inputStreamToString( connection.getInputStream(), connection.getContentLength(), fileSizeLimit), expireTimeMillis); }
看到這里的HttpURLConnection就知道為什么Applink需在安裝時聯網才有效，到這里其實就可以理解的差不多，后面其實就是針對配置跟App自身的配置進行校驗，如果通過就設置默認啟動，並持久化，驗證成功的話可以通過
adb shell dumpsys package d
查看結果:
Package: com.xxx
Domains: xxxx.com
Status: always : 200000002
驗證后再通過PackageManagerService持久化到設置信息，如此就完成了Applink驗證流程。
總結
其實關於applink有幾個比較特殊的點：
- applink第一它只驗證一次，在安裝的時候，為什么不每次啟動動檢測呢？可能是為了給用戶自己選怎留后門。
- applink驗證的時候需要聯網，不聯網的方案行嗎？個人理解，不聯網應該也可以，只要在安裝的時候，只本地驗證好了，但是這樣明顯沒有雙向驗證安全，因為雙向驗證證明了網站跟app是一對一應的，這樣才能保證安全，防止第三方打包篡改。