Android/frameworks_base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

DO NOT MERGE Return the preferred home activity first to honor persistent preferred activity.

Browse Source 
Bug: 237330774
Test: manual
Change-Id: Ieb8c6b7307338149b87f1b84968f6c1ccaac1d91
This commit is contained in:
Hai Zhang
2022-09-21 01:49:41 +00:00
parent 7359d3218a
commit bb478f97a8
1 changed files with 20 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
services/core/java/com/android/server/pm/ComputerEngine.java
View File

@@ -1192,24 +1192,27 @@ public class ComputerEngine implements Computer {
}
allHomeCandidates.addAll(resolveInfos);
String packageName = mDefaultAppProvider.getDefaultHome(userId);
String packageName = null;
// Workaround for b/237330774 in T: return the preferred activity first to honor
// persistent preferred activity.
// Role changes are not and cannot be atomic because its implementation lives inside
// a system app, so when the home role changes, there is a window when the previous
// role holder is removed and the new role holder is granted the preferred activity,
// but hasn't become the role holder yet. However, this case may be easily hit
// because the preferred activity change triggers a broadcast and receivers may try
// to get the default home activity there. So we need to fix it for this time
// window, and an easy workaround is to fallback to the current preferred activity.
final int appId = UserHandle.getAppId(Binder.getCallingUid());
final boolean filtered = appId >= Process.FIRST_APPLICATION_UID;
PackageManagerService.FindPreferredActivityBodyResult result =
findPreferredActivityInternal(intent, null, 0, resolveInfos, true, false,
false, userId, filtered);
ResolveInfo preferredResolveInfo = result.mPreferredResolveInfo;
if (preferredResolveInfo != null && preferredResolveInfo.activityInfo != null) {
packageName = preferredResolveInfo.activityInfo.packageName;
}
if (packageName == null) {
// Role changes are not and cannot be atomic because its implementation lives inside
// a system app, so when the home role changes, there is a window when the previous
// role holder is removed and the new role holder is granted the preferred activity,
// but hasn't become the role holder yet. However, this case may be easily hit
// because the preferred activity change triggers a broadcast and receivers may try
// to get the default home activity there. So we need to fix it for this time
// window, and an easy workaround is to fallback to the current preferred activity.
final int appId = UserHandle.getAppId(Binder.getCallingUid());
final boolean filtered = appId >= Process.FIRST_APPLICATION_UID;
PackageManagerService.FindPreferredActivityBodyResult result =
findPreferredActivityInternal(intent, null, 0, resolveInfos, true, false,
false, userId, filtered);
ResolveInfo preferredResolveInfo = result.mPreferredResolveInfo;
if (preferredResolveInfo != null && preferredResolveInfo.activityInfo != null) {
packageName = preferredResolveInfo.activityInfo.packageName;
}
packageName = mDefaultAppProvider.getDefaultHome(userId);
}
if (packageName == null) {
return null;