What causes "getPatchUseEmergencyMode, but intent is null" in Tencent/tinker?

Guard onHandleIntent / custom call sites with a null-intent check that simply returns.

Tencent/tinker · error · TinkerRuntimeException

getPatchUseEmergencyMode, but intent is null

Error message

getPatchUseEmergencyMode, but intent is null

What it means

TinkerPatchService.getPatchUseEmergencyMode reads the boolean extra indicating whether the patch should be applied in emergency mode (foreground, screen-on) from the starting intent. Like its sibling accessors, it throws on a null Intent instead of returning the default false.

Source

Thrown at tinker-android/tinker-android-lib/src/main/java/com/tencent/tinker/lib/service/TinkerPatchService.java:99

        resultServiceClass = serviceClass;
        //try to load
        try {
            Class.forName(serviceClass.getName());
        } catch (ClassNotFoundException e) {
            ShareTinkerLog.printErrStackTrace(TAG, e, "patch processor class not found.");
        }
    }

    public static String getPatchPathExtra(Intent intent) {
        if (intent == null) {
            throw new TinkerRuntimeException("getPatchPathExtra, but intent is null");
        }
        return ShareIntentUtil.getStringExtra(intent, PATCH_PATH_EXTRA);
    }

    public static boolean getPatchUseEmergencyMode(Intent intent) {
        if (intent == null) {
            throw new TinkerRuntimeException("getPatchUseEmergencyMode, but intent is null");
        }
        return ShareIntentUtil.getBooleanExtra(intent, PATCH_USE_EMERGENCY_MODE, false);
    }

    public static String getPatchResultExtra(Intent intent) {
        if (intent == null) {
            throw new TinkerRuntimeException("getPatchResultExtra, but intent is null");
        }
        return ShareIntentUtil.getStringExtra(intent, RESULT_CLASS_EXTRA);
    }

    @Override
    protected void onHandleIntent(Intent intent) {
        increasingPriority();
        doApplyPatch(this, intent);
    }

    /**

View on GitHub (pinned to 1b7ea02c23)

Solutions

Guard onHandleIntent / custom call sites with a null-intent check that simply returns.
Rely on the standard apply flow (TinkerInstaller.onReceiveUpgradePatch / onReceiveRetryPatchIfNotHandledWithInBackground) so intents are always populated.
Consider START_NOT_STICKY semantics for the patch service to avoid null-intent redeliveries.

Example fix

// before
boolean emergency = TinkerPatchService.getPatchUseEmergencyMode(intent);

// after
if (intent == null) return; // service restarted with null intent
boolean emergency = TinkerPatchService.getPatchUseEmergencyMode(intent);

Defensive patterns

Strategy: validation

Validate before calling

if (intent == null) return;
boolean emergency = TinkerPatchService.getPatchUseEmergencyMode(intent);

Prevention

Short-circuit null intents in onHandleIntent before reading extras.
Prefer the library-provided apply entry points, which construct complete intents.
In unit tests, always build a real Intent with extras instead of passing null.

When it happens

Trigger: Calling getPatchUseEmergencyMode(intent) with a null Intent, typically from custom service code or from TinkerPatchService.doApplyPatch itself when onHandleIntent received a null intent (service restarted by the system with null intent redelivery).

Common situations: The :patch process being restarted by the OS after a crash, delivering a null intent into onHandleIntent; custom wrappers around the patch service that pass through possibly-null intents.

Related errors

AI-assisted analysis of Tencent/tinker@1b7ea02c23 (2026-08-14). Data as JSON: /api/errors/b98e9e1d02fed613. Report an issue: GitHub.