Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit d25944e1 authored by Chong Zhang's avatar Chong Zhang
Browse files

Use user id 0 to get missing appId for debugger 

When forceStopPackageLocked is used to kill existing app process for
relaunching with debugger, user id could be -1 and getPackageUid will
already return -1. This results in killPackageProcessesLocked() not
able to find and kill the app, and wait for debugger will.

This also revert commit 55c9d739 (ag/969408) which tried to fix the
same problem but got it wrong. It's valid to -D when the process is
already running, as we're supposed to kill it. The really problem is
that the killing fails because of bad appId.

bug: 28980761
Change-Id: Ibebdcc26865464216a1f4b6773e540921cdad7d2
parent c0b602c4

services/core/java/com/android/server/am/ActivityManagerService.java

+1 −1
Original line number Diff line number Diff line
@@ -6036,7 +6036,7 @@ public final class ActivityManagerService extends ActivityManagerNative 
        if (appId < 0 && packageName != null) {

            try {

                appId = UserHandle.getAppId(AppGlobals.getPackageManager()

                        .getPackageUid(packageName, MATCH_DEBUG_TRIAGED_MISSING, userId));

                        .getPackageUid(packageName, MATCH_DEBUG_TRIAGED_MISSING, 0));

            } catch (RemoteException e) {

            }

        }

services/core/java/com/android/server/am/ActivityStackSupervisor.java

+1 −15
Original line number Diff line number Diff line
@@ -1097,21 +1097,7 @@ public final class ActivityStackSupervisor implements DisplayListener { 
            // Don't debug things in the system process

            if (!aInfo.processName.equals("system")) {

                if ((startFlags & ActivityManager.START_FLAG_DEBUG) != 0) {

                    final ProcessRecord app = mService.getProcessRecordLocked(

                            aInfo.processName, aInfo.applicationInfo.uid, true);

                    // If the process already started, we can't wait for debugger and shouldn't

                    // modify the debug settings.

                    // For non-persistent debug, normally we set the debug app here, and restores

                    // to the original at attachApplication time. However, if the app process

                    // already exists, we won't get another attachApplication, and the debug setting

                    // never gets restored. Furthermore, if we get two such calls back-to-back,

                    // both mOrigDebugApp and mDebugApp will become the same app, and it won't be

                    // cleared even if we get attachApplication after the app process is killed.

                    if (app == null || app.thread == null) {

                    mService.setDebugApp(aInfo.processName, true, false);

                    } else {

                        Slog.w(TAG, "Ignoring waitForDebugger because process already exists");

                    }

                }



                if ((startFlags & ActivityManager.START_FLAG_NATIVE_DEBUGGING) != 0) {