Fix external app parameters not resolving relative references

[grzesiek2010]

Closes #4580

Why is this the best possible solution? Were any other approaches considered?

All three inputs - absolute paths, relative paths and functions are just XPath, but the old code special-cased them into separate branches and only unpacked the function branch's result, so relative references (../name) never resolved. Instead of adding yet another branch, this collapses everything into one path: parse → evaluate against the current node's context → unpack.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Relative references in external app parameters (e.g. ../name inside a repeat) now resolve to the correct value instead of failing. Absolute paths, functions, instanceProviderID(), and literal/constant values are unchanged.
Populating data for external apps is at risk here, so please test all the forms you have that launch external apps and pass data to them.

Do we need any specific form for testing your changes? If so, please attach one.

As said above, any form that launches external apps and passes data to them.

Does this change require updates to documentation? If so, please file an issue here and include the link below.

No.

Before submitting this PR, please make sure you have:

• added or modified tests for any new or changed behavior
• run ./gradlew connectedAndroidTest (or ./gradlew testLab) and confirmed all checks still pass
• added a comment above any new strings describing it for translators
• added any new strings with date formatting to DateFormatsTest
• verified that any code or assets from external sources are properly credited in comments and/or in the about file.
• verified that any new UI elements use theme colors. UI Components Style guidelines

[seadowg]

I'm doing "needs testing" on this early as I think it'll be good to see if we can validate this approach. It seems right to me, but I'm worried that I'm missing something and QA will just immediately break it 😆.

[dbemke]

Tested with success!

Verified on a device with Android 10

Verified cases:

• the form from the forum
• sending email and text messages in repeats ( to a specific email/number)
• printing widget in repeats
• regression checks in printing widget, launching external apps, sending text messages and emails
• regression checks in counter widget
• regression check in Collect answer provider populating multiple field
• Collect Intents Tester

[WKobus]

Tested with success

Verified on android 16

[seadowg]

So it looks like we have both ExternalAppsUtils (in org.odk.collect.android.dynamicpreload) and ExternalAppUtils (in org.odk.collect.externalapp). I'm not sure why the former is in dynamicpreload as it's unrelated right? Let's either combine these or give them more different names, and make sure they leave in a place that makes sense. The current situation already massively threw me off trying to review 😆.

[grzesiek2010]

There’s a bit of a mess there. ExternalAppsUtils shouldn’t be in org.odk.collect.android.dynamicpreload at all. It looks like it was moved there by accident.
I spoke with @lognaturel yesterday, and she wanted to include this fix in v2026.3.4, so I think it makes sense to limit the changes here to what we already have. I can create a separate PR for the refactoring later.