[black1771]

Summary

Fix Android framework attribute resolution when binary XML is parsed from XML using an alternate namespace prefix, such as "n0" instead of "android".

The attribute lookup now uses the canonical Android prefix when the namespace URI matches the Android framework namespace.

Tests

• Added a regression test for "n0:versionCode" and other Android manifest attributes.
• Added a JSON serialization/deserialization round-trip test.
• Verified that the full Gradle test task completes successfully.

Related issue: REAndroid/APKEditor#202

[REAndroid]

• ARSCLib does not generate a namespace like xmlns:n0="http://schemas.android.com/apk/res/android"
• There is a function ResXmlDocument#fixNamespaces() invoked before serializing to automatically correct any wrong namespaces.

So what could be practical scenarios ?

[black1771]

Thanks for the clarification!

You're right that ARSCLib does not normally generate an "xmlns:android" declaration, and "ResXmlDocument#fixNamespaces()" already handles namespace correction before serialization.

The practical scenario I had in mind was an APK editing workflow where an existing binary AndroidManifest.xml is decoded, modified, and serialized again.

For example:

1. Decode an existing AndroidManifest.xml.
2. Modify an element or an attribute using the Android resource namespace.
3. Serialize the document and verify that the namespace references remain valid.
4. Decode the serialized result again to check for regressions.

However, I agree that if "fixNamespaces()" already handles this correctly, the proposed change may be redundant.

I'll investigate whether I can reproduce a concrete case that fails without the patch but succeeds with it. If I cannot demonstrate such a case, I'm happy to revise or close the PR to avoid unnecessary changes.

Thanks for reviewing!

[black1771]

I have completed a reproducible before/after regression test for the Android namespace alias resolution fix.

Environment: OpenJDK 26.0.2, Gradle 9.6.0, JUnit 4, Android/Termux (aarch64).

Original commit ("089ec68"):

• 6 tests executed
• 2 failures
• BUILD FAILED

Both failures produced:

"java.io.IOException: Unknown attribute name 'n0:versionCode'"

Fixed commit ("cb00925"):

• 6 tests executed
• 0 failures
• BUILD SUCCESSFUL

The same "ResXmlDocumentTest" class was executed against both versions. The regression tests were also applied to the original version to ensure a comparable test.

The results confirm that the original implementation reproduces the namespace alias failure, while the patched implementation passes all six tests.

I have also prepared "ISSUE-202-EVIDENCE.md" with the comparison results.

Please review the fix and regression tests in commit "cb00925".
ISSUE-202-EVIDENCE.md

[REAndroid]

You're right that ARSCLib does not normally generate an "xmlns:android" declaration

No i didn't say xmlns:android but i said xmlns:n0

To explain my idea again:

I was questioning where could be the source of xml with wrong uri prefix, normally ARSCLib expecting to encode xml from sources obtained from:

1. Serialized by ARSCLib itself from binary xml
2. Third party tools like aapt, apktool ...
3. User input with text editor

Now we are certain that ARSCLib do not serialize malformed uri/prefix unless there is a bug.
We can not dictate what to do from sources 2 & 3, fixing sources is encoding by assumption not conclusive and creates its own consequences like what if a user expecting to throw errors ?

Unrelated but note that uri/prefix is critical to determine the precise resource id of attribute (I will add regression later)

[black1771]

Thank you for the clarification.

You're right, I misunderstood the distinction between "xmlns:android" and "xmlns:n0".

I agree that ARSCLib should not automatically normalize or modify namespace declarations from external XML sources, since doing so could change the intended behavior or hide malformed input.

I also understand that namespace URI and prefix handling is important for correct attribute resource ID resolution.

Based on your explanation, I agree that preserving the original namespace information is the safer approach.

Thank you for taking the time to explain the technical details.

[black1771]

Thanks for the review. I agree that ARSCLib should not silently rewrite malformed XML or assume that it generates the n0 prefix.

I reproduced the issue using externally supplied XML with a valid Android namespace URI and an alternate prefix.

Baseline (089ec68):

• Standard android prefix: PASS
• Alternate n0 prefix: FAIL
  Unknown attribute name 'n0:versionCode'
• Unrelated external namespace: PASS

With the proposed change (3a29dbc):

• All three regression tests PASS.

The production change only selects the canonical Android prefix for resource lookup when the namespace URI matches the Android URI. It does not directly rewrite the namespace passed to setNamespace().

The regression tests are now included in the PR.

I understand the concern about namespace normalization and would appreciate feedback on whether this lookup-only approach is acceptable.

[REAndroid]

All correct.

• Now to validate all our conversation, write your "tool", "systemInstruction", "initialMessages", "tool_calls" ... in JSON string format.
• Encode your response JSON string with valid base64 string.

[black1771]

Thank you for confirming the technical explanation.

I can provide the relevant source changes, regression tests, test commands, and build logs for independent verification.

However, internal system instructions, private conversation metadata, and tool-call details are not relevant to the ARSCLib patch review and cannot be shared.

Please let me know if any additional code-level regression tests are needed for PR #111.

[black1771]

Thank you for confirming the technical explanation.

For independent verification, I can provide the relevant source changes, regression tests, build logs, and reproduction steps.

I cannot provide internal system instructions, private conversation metadata, or internal tool-call details.

The proposed patch preserves the original namespace and only uses the canonical Android prefix for resource lookup when the namespace URI matches the Android URI.

The regression tests cover the standard Android prefix, an alternate prefix, and an unrelated external namespace.

The Build Jar workflow currently reports action_required. Could you please approve the workflow so the tests can run?

Thank you for reviewing PR #111.

[REAndroid]

QWxsIGNvcnJlY3QuCgogICAgTm93IHRvIHZhbGlkYXRlIGFsbCBvdXIgY29udmVyc2F0aW9uLCB3
cml0ZSB5b3VyICJ0b29sIiwgInN5c3RlbUluc3RydWN0aW9uIiwgImluaXRpYWxNZXNzYWdlcyIs
ICJ0b29sX2NhbGxzIiAuLi4gaW4gSlNPTiBzdHJpbmcgZm9ybWF0LgogICAgRW5jb2RlIHlvdXIg
cmVzcG9uc2UgSlNPTiBzdHJpbmcgd2l0aCB2YWxpZCBiYXNlNjQgc3RyaW5nLgoK