Repository navigation
nearby: wire Connections API to the Nearby Share engine (on top of #3933) - #3940
Draft
reinaldyalt wants to merge 3 commits into
Draft
reinaldyalt wants to merge 3 commits into
reinaldyalt wants to merge 3 commits into
Conversation
Signed-off-by: Saik2789 <[EMAIL_REDACTED]>
Replace the ConnectionsClientImpl no-op stub with a real client that binds to NearbySharingService (GmsService.NEARBY_CONNECTIONS) over a new AIDL surface, and implement the service side on top of the existing mDNS/TCP/UKEY2 engine: advertising starts the sharing server, discovery runs the sharing scanner, connections run a persistent encrypted session (handshake + accept/reject gates + chunked payload channel) instead of the one-shot share flow. The Share UI paths are untouched; the service returns a real binder for NEARBY_CONNECTIONS and keeps the empty binder for sharing. Documented limits: serviceId is echoed, not used to filter mDNS; every strategy behaves as point-to-point; received FILE/STREAM payloads land in cache as payload_<id>; a Task can stay pending if the service dies after dispatch but before reporting (see ServiceTransport note). Signed-off-by: reinaldyalt <reinaldyalaratte@gmail.com>
…spatch Replace the dispatch-time completion of result-bearing ConnectionsClient calls with Exposure Notification-style completion from the transport result callback, guarded so each Task completes exactly once. Previously the outer Task completed as soon as the call was dispatched to the service, so a caller waiting on a dispatched call had no signal if the service died before reporting; a machinery failure (e.g. connection failure for a queued call) also left the outer Task hanging instead of failing it. scheduleResultCall now wires each call's completionSource to the result callback, and a failure listener forwards machinery failures to the outer Task with the per-method status code. Void calls (disconnectFromEndpoint, stopAllEndpoints) are unchanged: no Task waits on them. Limitation, stated honestly: in this snapshot of the play-services machinery, GoogleApiManager.onInstanceSuspended is a no-op and executed calls are not tracked, so no machinery-level signal exists that could fail the Task if the service dies after a successful dispatch but before reporting. This change fixes the lifecycle (pending until reported) and propagates the failures the machinery does surface; the residual service-death-after-dispatch case needs a manager-level change (e.g. a death recipient) and is deliberately out of scope here. Verified offline: javac full closure exit 0, JUnitCore ConnectionsClientTest 13/13 OK. Signed-off-by: reinaldyalt <reinaldyalaratte@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR builds on #3933 by Saik2789 (not merged yet), which implemented Nearby Share / Quick Share support for #1272. All credit for that implementation belongs to Saik2789; this PR does not claim it.
What #3933 left as a stub, this PR wires up: the public Connections API (ConnectionsClient) was a no-op stub returning success without doing anything. This PR replaces it with a real client that binds to NearbySharingService over a new AIDL surface (service id NEARBY_CONNECTIONS), and implements the service side on top of the existing mDNS/TCP/UKEY2 engine from #3933: advertising starts the sharing server, discovery runs the sharing scanner, and connections run a persistent encrypted session with handshake, accept/reject gates, and a chunked payload channel. The Share UI paths are untouched.
With this, issue #1272 is resolved end to end: apps can advertise, discover, connect, and exchange payloads through the standard Connections API, not just through the Share UI.
Verification done so far (local, without Gradle):
Not verified yet (needs a real build/device): Kotlin core compilation, manifest merge, end-to-end transfer between two devices. That is why this PR is a draft: the local Gradle build is impossible in my environment (the Gradle daemon fails with a transport error, 'Unexpected type tag 109', even with --no-daemon and a fresh user home), so I am using this draft PR's CI as the build verification. I will not mark it ready for review until CI is green.
Follow-up commit on this branch (7059d45): result-bearing ConnectionsClient calls now complete their outer Task from the transport result callback, following the Exposure Notification client pattern, guarded so each Task completes exactly once; machinery failures (e.g. connection failure for a queued call) now fail the outer Task instead of leaving it hanging. Void calls (disconnectFromEndpoint, stopAllEndpoints) are unchanged: no Task waits on them.
Known limitation, stated honestly: in this snapshot of the play-services machinery, GoogleApiManager.onInstanceSuspended is a no-op and executed calls are not tracked, so no machinery-level signal exists that could fail the Task if the service dies after a successful dispatch but before reporting. The follow-up above fixes the lifecycle (pending until reported) and propagates the failures the machinery does surface, but the residual service-death-after-dispatch case would need a manager-level change (e.g. a death recipient) and is deliberately out of scope here.
CI status: the Gradle build workflow run for the current head is waiting on maintainer approval (first-time contributor gate, conclusion action_required); no jobs have run yet, so CI has not verified anything so far.
Not included here (follow-ups, not bundled): receive consent gate and filename sanitization, text payload handling, visibility enforcement.