Vector bootrace

[Lycidias93]

SafetyCore still causes dex2oat / PackageManager errors after boot and may interfere with Zygisk/Vector startup

Device / environment

• Device: Google Pixel 10 Pro XL
• Android: Android 16
• Root: Magisk
• Zygisk: enabled
• Relevant modules/apps:
  • Anti SafetyCore module
  • Zygisk / Vector
  • LSPosed / DirtySePolicy
  • AshLooper 9.8
  • Pixel Boot Watch v0.1.5.1

Problem

Sometimes Vector does not load correctly after boot.

The boot itself completes successfully, but shortly after boot there are repeated SafetyCore / ART / PackageManager related errors. At the same time, the logs show Zygisk/Vector related red flags and LMKD activity.

This looks like a possible boot race or early boot pressure issue where SafetyCore-related install/dexopt failures may interfere with Zygisk/Vector initialization.

Evidence from Pixel Boot Watch

Two consecutive boot captures were checked.

Boot 1

• Boot Watch result: PASS
• Run ID: 20260605_104659_boot
• zygisk_vector: 17
• dex2oat: 114
• safetycore: 128
• Permission denied: 44
• LMKD: 98
• lowmemorykiller: 13
• avc: denied: 25

Boot 2

• Boot Watch result: PASS
• Run ID: 20260605_105319_boot
• zygisk_vector: 20
• dex2oat: 100
• safetycore: 246
• Permission denied: 40
• LMKD: 62
• lowmemorykiller: 37
• avc: denied: 24

Relevant log excerpts

The logs repeatedly show dex2oat failures involving SafetyCore and DirtySePolicy:

Abort message: 'Failed to execute (... /apex/com.android.art/bin/dex2oat64 ... com.google.android.safetycore ...): Permission denied'

[Lycidias93]

Additional evidence from the latest boot / post-boot check

I captured another boot with Boot Watch and then ran a post-boot Vector / Zygisk check after the issue appeared.

Boot Watch result:

pbw_result=PASS
pbw_version=0.2.4
pbw_versionCode=24
run_id=20260606_140422_boot
mode=boot

This was not a bootloop. The device booted successfully, but the boot showed repeated ART / PackageManager / dex2oat failures.

Relevant installed modules from the same boot:

id=anti_safetycore
name=Anti SafetyCore
version=1.3.0
versionCode=130
disable=absent
remove=absent
service.sh=present

id=rezygisk
name=ReZygisk
version=v1.0.0 (520-093dfaf-release)
versionCode=520
disable=absent
remove=absent
service.sh=present
post-fs-data.sh=present

id=zygisk_vector
name=Vector
version=v2.0 (3043)
versionCode=3043

id=dirtysepbypass
name=DirtySepolicy Bypass
version=v3.0.0
versionCode=30000
disable=present
remove=absent

Post-boot process check shows that ReZygisk / Vector are not completely dead:

zygisk-ptrace64
zygiskd64
zygote64
magiskd

Important new finding:

Boot Watch shows that Vector replaces / mounts dex2oat64:

/data/adb/modules/zygisk_vector/bin/dex2oat64
mounted over:
/apex/com.android.art/bin/dex2oat64

So Vector is directly involved in the ART dex2oat execution path.

At the same time, early boot logs show repeated dex2oat64 failures involving SafetyCore:

Failed to execute ... /apex/com.android.art/bin/dex2oat64 ... com.google.android.safetycore ... Permission denied

The same boot also shows dex2oat64 failures involving DirtySepolicy:

Failed to execute ... /apex/com.android.art/bin/dex2oat64 ... org.lsposed.dirtysepolicy ... Permission denied

This is notable because the Magisk module dirtysepbypass is disabled, but the package org.lsposed.dirtysepolicy still appears in the ART / dex2oat path.

Boot Watch red flag counters for this boot:

FinalizerWatchdogDaemon=430
Okio Watchdog=1
dex2oat=126
safetycore=114
zygisk_vector=20
Permission denied=40
Failed transaction=25
LMKD=97
lowmemorykiller=12
File name too long=0
avc: denied=23

The system services were present, but calls to Settings and PackageManager failed with Binder transaction errors:

Service settings: found
Service package: found
Service activity: found
Service power: found
Service dropbox: found

cmd: Failure calling service settings: Failed transaction (2147483646)
cmd: Failure calling service package: Failed transaction (2147483646)

Repeated package-related checks failed with the same error:

cmd package bg-dexopt-job status
cmd package list staged-sessions
cmd package get-stagedsessions
pm path com.google.android.safetycore
pm path com.google.android.gms
pm path com.google.android.gsf

Result:
cmd: Failure calling service package: Failed transaction (2147483646)

This suggests that the problem may not be that Vector is completely missing. Instead, Vector is running, but the Vector dex2oat64 replacement path seems to be involved in ART / PackageManager failures during early boot, especially around SafetyCore.

Question:

Could Anti SafetyCore avoid triggering SafetyCore-related dexopt / PackageManager activity during early boot, or otherwise prevent SafetyCore from entering this failing dex2oat path?

Could Anti SafetyCore also avoid leaving SafetyCore in a state where PackageManager / ART repeatedly tries to process it through the Vector-mounted dex2oat64 path and fails with Permission denied?