[JingMatrix]

Four defects in the legacy resource hooks, found chasing one of them.

The borrowed TypedValue. XResources.getLayout needs the variant segment of a layout's resource path to label the XC_LayoutInflated callbacks registered for that id, and read it through the TypedValue sitting in Resources.mTmpValue, a field reached by reflection rather than one of ours. That field is a pool of one, in AOSP's own wording: declared beside the lock that guards it, handed out by obtainTempTypedValue, which leaves it null until releaseTempTypedValue "returns a TypedValue to the pool", and taken that way by fourteen methods of Resources — getLayout by way of loadXmlResourceParser, the one this override calls through to, among them. android10-release holds the same pool, so there is no API change to adapt to: the borrowed value has always been null whenever another lookup on the same Resources was in flight, and AssetManager.getResourceValue opens with Objects.requireNonNull(outValue, "outValue"). What changed is how often it overlaps: on the Android 17 QPR3 beta a module hooking SystemUI's shade layout meets it through an <include> — scene_window_root, absent from android14-release, wraps super_notification_shade and is inflated while SystemUIService and KeyguardService are created — and SystemUI crash-loops at boot until an inflation finds the slot full. That a later attempt on the same build and device comes up is the race showing itself.

Names a system-wide hook never received. A layout hook is filed under the resource directory it was registered for and a system-wide one under null. getLayout honoured both keys for the callbacks and only the first for the names, so a framework layout hooked through hookSystemWideLayout and inflated by an app — what that API is for — reached the callback with resNames null. Their registration also moves ahead of the callbacks', and a first callback now joins its set before the set is published, because an inflation reads the two in the other order and one that finds callbacks with no names records nothing against the document it returns.

ResourceNames built the other way round. The constructor takes (id, pkg, name, type) and spells a full name as pkg:type/name, the form getResourceName returns; both factories passed the type name as the name and the entry name as the type. Every layout callback has been receiving android:simple_list_item_1/layout for what is android:layout/simple_list_item_1, and ResourceNames.equals could match neither field. The swap is inherited — LSPosed's XResources has it too — so a module that worked around it will stop matching, which is the price of the fields meaning what they document.

A cache bit that could be missed or lost. A replacement's id is noted in a bitmap first and in sReplacements second, so a resource read whose bit is clear returns the original without taking a lock. The bitmap was a byte[] written under a monitor and read under none, which the memory model lets a reader miss for as long as it likes, and it was set outside the lock isFirstLoad clears it under, so a replacement registered as a module reloaded could keep its row and lose its bit — unreplaceable for the life of the process. It is now an AtomicIntegerArray, read with a volatile load, set with a compare-and-swap beside the row under the same lock, and held in a final field. The bits are exactly the ones the old key-and-offset arithmetic reached, 0x000700ff of a framework id and 0x0007007f of an app's, each named once as the bit an id stands for.

Three things in the same code were looked at and left alone: XTypedArray.peekValue keeps the field it borrows, since TypedArray.mValue is assigned only where it is declared and returning that instance is its contract; mParseState and mBlock are still spelled as XResources reads them in android10-release and android16-release alike, and the native side returns early on a null parse state; and every id-taking getter of Resources that Xposed documents as replaceable is still overridden, getQuantityString arriving through the overridden getQuantityText.

[JingMatrix]

@jiggs82 Thanks for reporting this issue, it should be fixed now in the CI build: https://github.com/JingMatrix/Vector/actions/runs/41059640616

Please confirm it so that I can merge.

[jiggs82]

Yup it seems to be working fine for me thanks for the quick fix 👍🏻