asLody/VirtualApp · error · java.lang.IllegalStateException

Failed to allocate session ID

Error message

Failed to allocate session ID

What it means

allocateSessionIdLocked picks a random positive int for a new install session and retries up to 32 times to find an ID not already used in mSessions. If all 32 attempts collide, it throws IllegalStateException("Failed to allocate session ID"). With the full int range this practically only happens when the session map is saturated or buggy.

Solutions

  1. Audit the install flow: ensure every created session is eventually committed or abandoned so entries are removed from mSessions
  2. Restart the VA/installer service process to clear the leaked session table, then retry the install
  3. Serialize createSession calls or cap concurrent installs so the session map cannot grow unbounded
  4. Update/patch the allocator to expand retries or use a monotonic counter instead of random IDs

Example fix

// before
int id = installer.createSession(params); // can throw IllegalStateException after 32 collisions
// after
try {
    int id = installer.createSession(params);
} catch (IllegalStateException e) {
    // session table saturated: clean up stale sessions / restart installer, then retry
    retryInstallAfterCleanup();
}
Defensive patterns

Strategy: try-catch

Validate before calling

// if the API exposes it, check session pressure first
List<PackageInstaller.SessionInfo> live = installer.getAllSessions();
if (live != null && live.size() > 500) { cleanupStaleSessions(); }

Try / catch

try {
    sessionId = installer.createSession(params);
} catch (IllegalStateException e) {
    restartInstallerService(); // clear leaked session table
    sessionId = installer.createSession(params);
}

Prevention

When it happens

Trigger: createSessionInternal is invoked when mSessions already holds a very large number of live sessions, or a pathological random seed makes 32 consecutive collisions with existing IDs; also reachable if sessions are leaked (never abandoned/removed) over a long-lived host process.

Common situations: A VA host process that installs thousands of APKs without cleaning up leaked sessions; repeated createSession calls that never commit or abandon, filling the in-memory map; an RNG misconfiguration making nextInt degenerate.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors


AI-assisted analysis of asLody/VirtualApp@666fefcb5d (2026-09-09). Data as JSON: /api/errors/8ca828010d773aa0. Report an issue: GitHub.

Appendix: source

Thrown at VirtualApp/lib/src/main/java/com/lody/virtual/server/pm/installer/VPackageInstallerService.java:270

            }
        }
    }

    private boolean isCallingUidOwner(PackageInstallerSession session) {
        return true;
    }

    private int allocateSessionIdLocked() {
        int n = 0;
        int sessionId;
        do {
            sessionId = mRandom.nextInt(Integer.MAX_VALUE - 1) + 1;
            if (mSessions.get(sessionId) == null) {
                return sessionId;
            }
        } while (n++ < 32);

        throw new IllegalStateException("Failed to allocate session ID");
    }

    private static class Callbacks extends Handler {
        private static final int MSG_SESSION_CREATED = 1;
        private static final int MSG_SESSION_BADGING_CHANGED = 2;
        private static final int MSG_SESSION_ACTIVE_CHANGED = 3;
        private static final int MSG_SESSION_PROGRESS_CHANGED = 4;
        private static final int MSG_SESSION_FINISHED = 5;

        private final RemoteCallbackList<IPackageInstallerCallback>
                mCallbacks = new RemoteCallbackList<>();

        public Callbacks(Looper looper) {
            super(looper);
        }

        public void register(IPackageInstallerCallback callback, int userId) {
            mCallbacks.register(callback, new VUserHandle(userId));

View on GitHub (pinned to 666fefcb5d)