APKS upload failure with no message or feedback

[deckerst]

I just tried to upload an update, but nothing happens at the end of the upload.
Checking the console in the developer tools (in Firefox), I just see the request yielded a 500:

error: null
message: "Http failure response for https://developer-api.accrescent.app/api/v1/apps/deckers.thibault.aves.libre/updates: 500 OK"
name: "HttpErrorResponse"
ok: false
redirected: undefined
status: 500
statusText: "OK"
type: undefined
url: "https://developer-api.accrescent.app/api/v1/apps/deckers.thibault.aves.libre/updates"

Is it a temporary server failure? Or something wrong with the APKS?
By the way, the APKS is about 140 MB. This is higher than the requirement, but it has always been the case.

[deckerst]

I just tried the upload for deckers.thibault.aves and it worked.
But I retried the upload for deckers.thibault.aves.libre and it still fails.

[lberrymage]

Most likely a temporary server failure or a bug. Could you try again now?

[deckerst]

Same issue. Would you like me to share the apks so you can inspect it and try for yourself?

edit: I sent an email with links to the AAB/APKS.

[deckerst]

Since then I have tried updating the packages on Accrescent for several new versions of Aves. Every time, the upload works fine for deckers.thibault.aves but fails for deckers.thibault.aves.libre. I would appreciate some guidance.

[lberrymage]

It took me a while, but I've been able to reproduce the issue with the APK set you sent both with the currently deployed version of Parcelo and the main branch, and I think I've figured it out. Aves Libre has a meta-data tag in its manifest that looks like this:

<meta-data
    android:name="com.google.android.geo.API_KEY"
    android:value="<NONE>" />

The problem is the <NONE>. According to the XML standard:

the left angle bracket (<) MUST NOT appear in their literal form...

If they are needed elsewhere, they MUST be escaped...

Parcelo uses BinaryXmlParser from com.android.tools.apkparser:apkanalyzer which in turn uses com.android.xml.XmlBuilder whose class documentation says:

Arguments are not validated or escaped.

After Parcelo has converted a binary Android manifest into its text representation, attempting to parse that text as an XML document fails because of the literal "<".

So ultimately, this behavior originates as a bug in Parcelo. I don't know for sure if the currently deployed version of Parcelo fails for this same reason (it's much harder to test and so is being replaced by the refactor in the main and refactor branches), but it's likely.

There are a couple things that need to happen to resolve this issue entirely:

1. The console needs to display these kinds of errors in a friendly way instead of silently failing. This is WIP locally but probably won't be deployed until the Parcelo refactor is deployed.
2. Parcelo needs to properly parse Android manifests. There are a few decent options here:
   1. Keep parsing mostly the same, but escape illegal characters where appropriate: simple in theory, but difficult to get right without risking some sort of injection vulnerability.
   2. Restructure parsing to avoid the string conversion step in the current binary -> string -> domain pipeline, parsing binary XML directly: less hacky, but still a bit difficult to do correctly.
   3. Accept app bundles instead of APK sets while retaining Accrescent's security properties meta#53 should avoid this issue entirely, but will take a lot more work and isn't planned until much later.

In the meantime, are you able to try removing that meta-data attribute or updating it to not include "<" characters to see if that's really the issue here?

[deckerst]

It took me a while, but I've been able to reproduce the issue with the APK set you sent both with the currently deployed version of Parcelo and the main branch, and I think I've figured it out.

Thank you for spending time on this issue.

In the meantime, are you able to try removing that meta-data attribute or updating it to not include "<" characters to see if that's really the issue here?

Yes, I used this <NONE> to make it obvious it was a default invalid value, but I didn't think it was not properly formatted. I will change that value to something innocuous for the next version.

[deckerst]

Publishing Aves Libre v1.14.9 worked fine.