Skip to content

wearable: restore ClientIdentity population in WearableLocationService#3478

Open
js360000 wants to merge 1 commit into
microg:masterfrom
js360000:bountybox/issue-2843
Open

wearable: restore ClientIdentity population in WearableLocationService#3478
js360000 wants to merge 1 commit into
microg:masterfrom
js360000:bountybox/issue-2843

Conversation

@js360000
Copy link
Copy Markdown

Summary

wearable: restore ClientIdentity population in WearableLocationService

generateClientIdentity has been returning null since the
ClientIdentity constructor was retired in favour of the
AutoSafeParcelable public-field layout. The callsite still wraps the
result into request.clients, so every per-client entry in the
forwarded LocationRequestInternal was a null reference — anything
downstream that branched on client.uid / client.packageName
silently lost the package association coming from the watch.

Restore the original behaviour against the current ClientIdentity:

  • Look up the supplied package name via PackageManager, populate
    uid and packageName from the resolved ApplicationInfo.
  • On NameNotFoundException, fall back to the host process's own
    UID/package (matching the historical fallback that was commented
    out alongside the null return) and log a warning.

Touches one file, ~10 LOC of behavioural change. Non-overlapping with
the WearOS transport work in PR #3473 — that PR keeps the watch link
alive; this restores the per-client identity needed for the relayed
location requests to do anything useful once they arrive.

Relates to #2843

Diff

 .../wearable/location/WearableLocationService.java   | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

Claim

/claim #2843

`generateClientIdentity` has been returning `null` since the
`ClientIdentity` constructor was retired in favour of the
AutoSafeParcelable public-field layout. The callsite still wraps the
result into `request.clients`, so every per-client entry in the
forwarded `LocationRequestInternal` was a null reference — anything
downstream that branched on `client.uid` / `client.packageName`
silently lost the package association coming from the watch.

Restore the original behaviour against the current ClientIdentity:

  - Look up the supplied package name via `PackageManager`, populate
    `uid` and `packageName` from the resolved `ApplicationInfo`.
  - On `NameNotFoundException`, fall back to the host process's own
    UID/package (matching the historical fallback that was commented
    out alongside the null return) and log a warning.

Touches one file, ~10 LOC of behavioural change. Non-overlapping with
the WearOS transport work in PR microg#3473 — that PR keeps the watch link
alive; this restores the per-client identity needed for the relayed
location requests to do anything useful once they arrive.

Relates to microg#2843
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants