Extract the receive-content manifest and add a navDeepLink snippet by hamen · Pull Request #18 · StellarElements/android-dac-snippets

hamen · 2026-09-04T13:28:00Z

Snippets for Receiving simple data. The matching receive.md edit is up on the google3 staging environment.

Both branches live in this fork. The base, snapshot/android-snippets-main, is a copy of android/snippets@14ba993, so this diff shows only the two files this change touches. This fork's main diverged at b026e52 and would add six unrelated files to the view.

Why

The routing block was written at the page owners' request, not invented here. A written brief went to them first, naming three findings on this page: the prose contradicting its only snippet, the two-step process being incomplete because navDeepLink routes but does not deliver EXTRA_STREAM or EXTRA_TEXT, and two sentences of View system text with no snippet behind them. They were offered two ways out, the code following the prose or the prose following the code, and chose the first. This branch is that decision.

The guide told the reader to route the incoming ACTION_SEND intent with Compose Navigation's deep link support, "instead of manually intercepting and parsing the Intent". No navDeepLink code appeared anywhere on the page, and the one snippet did exactly the manual interception the prose says to avoid. The manifest block was still inline rather than included from here.

What changed

Region tag	File	State
`android_receive_data_nav_deeplink`	`sharesheet/SharesheetSnippets.kt`	New. The missing routing step. Tagged around the `composable(...)` call alone.
`android_handle_intent_action_data_sent`	`sharesheet/SharesheetSnippets.kt`	Edited. Published region, currently pinned at `b026e52#L35-L77`.
`android_handle_intent_handle_extra_text`	`sharesheet/SharesheetSnippets.kt`	Edited. One comment, so it matches the three the page edit reworded.

The manifest block stays on the page. An earlier revision of this branch extracted it into sharesheet/AndroidManifest.xml. On review that was the wrong direction: manifest snippets are not migrated, so the file is deleted and the block stays hardcoded in receive.md. That also settles an inconsistency this fork had in public, since the shortcuts extraction had left its own manifest block inline.

One thing for the page while that block is being edited: the activity declares intent filters and no android:exported, so as printed it will not install on API level 31 or higher. It wants android:exported="true" to receive incoming share intents.

Deviations from the published page

android_handle_intent_action_data_sent no longer matches the live page. It carries the rewrite that ships with the receive.md edit: private handlers, Intent.ACTION_SEND in place of the bare imported ACTION_SEND, ?.let on the nullable results, and reworded comments. The page and this region land together.
The deep link snippet declares a third link, ACTION_SEND_MULTIPLE with image/*. The manifest declares that filter and SharesheetHandler handles it, so leaving it out would give a reader who follows steps 1 and 2 no route for multiple images.
android_handle_intent_handle_extra_text moves from 6/6 verbatim to 5/6. Its comment is reworded to match the three the rewrite already changed, which collapses the page's two comment lines into one. That wording ships in receive.md with the rest.
The deep link region is tagged around the composable(...) call itself, with no exclude blocks. Rendered, it publishes that call and nothing else. An earlier revision tagged the whole SharesheetNavHost() function and hid the NavHost frame in silent excludes, which published a composable(...) call with no NavGraphBuilder receiver — code that does not compile.

Checks

assembleDebug and spotlessCheck pass. check-snippets.mjs reports both remaining regions as differing from the live page by exactly the rewrite above, which lands with the receive.md edit.

Region tag	Page section	Verbatim	Lines ours/page
`android_handle_intent_action_data_sent`	Handle the incoming content, block 0	no, by the rewrite above	46/43
`android_handle_intent_handle_extra_text`	Screenshot URL sharing, block 0	no, by the reworded comment	5/6
`android_receive_data_nav_deeplink`	new block, not on the live page	not comparable yet	19/—

The deep link region cannot be compared against the live page, and that is not an oversight. The page publishes no block for it — that is the gap this change exists to close — so the check lists the tag as unplaced and never compares it. It can only be checked against the staged receive.md, and it should be, by whoever lands that edit. Every other region on the page is compared above. The mapping for this page is kept in google-dac-team so the comparison can be re-run by somebody who did not write it.

The "Receive simple data" guide describes a two-step process: declare the intent filters, then route the incoming intent with Compose Navigation's deep link support, "instead of manually intercepting and parsing the Intent". No navDeepLink code appeared anywhere on the page, and the only snippet did the manual interception the prose tells the reader to avoid. Add the missing routing snippet so the code matches the prose. The deep links only route the user to the destination; they do not carry EXTRA_STREAM or EXTRA_TEXT, so SharesheetHandler stays as the step that reads the extras. Declare a link for ACTION_SEND_MULTIPLE too, which the manifest block already declares and the handler already handles. Extract the manifest block, which was still inline on the page. It lives in a stand-alone file under src/main/java so Gradle does not merge it: it declares .ui.MyActivity, which does not exist, and three live ACTION_SEND filters would put the snippets app into every share sheet on the device. Signed-off-by: Ivan Morgillo <imorgillo@gmail.com>

hamen · 2026-09-04T13:47:30Z

@kkuan2011 this is ready for review

kkuan2011

Looks good once comments are addressed

**The manifest file is gone.** The reviewer's ruling is that manifest snippets are not migrated and stay hardcoded on the page, so extracting one was work in the wrong direction. That also settles an inconsistency this fork had in public: the shortcuts extraction left its manifest block inline on the same reasoning, and the two branches disagreed until now. Her second manifest note is for the page rather than for this branch, and it is a real defect there: the activity carries intent filters and no `android:exported`, so as printed it will not install on API level 31 or higher. That goes to the page owners with the receive.md edit. **The deep link region published code that does not compile.** The tags sat around `SharesheetNavHost()` with the `NavHost` frame inside silent excludes, so the rendered block was a `composable(...)` call floating in a `@Composable` function body with no `NavGraphBuilder` receiver, at eight spaces inside a four-space scope. The description claimed the page showed the `composable(...)` block alone; it did not, and nothing compared the tag, because the page has no block for it to claim yet. The tags now sit around the `composable(...)` call itself and both excludes are gone. Rendered, the block is that call and nothing else, at column zero. Three reviewers reached this independently and each rendered it to prove it. **One comment now matches its siblings.** The page edit reworded the three handlers to "Update UI state with the shared ...", and `android_handle_intent_handle_extra_text` was left on the old wording. It is a published region, so this moves it from 6/6 verbatim to 5/6 against the live page and the wording has to ship in receive.md with the rest. Two review questions are answered rather than changed. `Intent.ACTION_SEND` and `intent.type == "text/plain"` are both part of the rewrite that ships with the page edit, not local preferences: the file does import the bare constant, and `==` is null-safe in Kotlin, so neither is required by the compiler — the page is what decides them, and the page is changing to match. Claude-Session: https://claude.ai/code/session_01P9x2zonc8Jow9hajZw96pn

hamen · 2026-09-11T09:36:25Z

Closing — this is now upstream as android/snippets#1085, opened off upstream/main with every review round here applied. Thanks for the review.

The branch stays, so the rounds on this PR remain readable.

hamen self-assigned this Sep 4, 2026

hamen marked this pull request as ready for review September 4, 2026 13:46

hamen mentioned this pull request Sep 4, 2026

Extract the shortcuts snippets from the create, manage and capabilities guides #19

Closed

kkuan2011 approved these changes Sep 9, 2026

View reviewed changes

kkuan2011 approved these changes Sep 11, 2026

View reviewed changes

hamen closed this Sep 11, 2026

Navigation Menu

Extract the receive-content manifest and add a navDeepLink snippet - #18

Extract the receive-content manifest and add a navDeepLink snippet#18
hamen wants to merge 2 commits into
snapshot/android-snippets-mainfrom
sharesheet-receive-deeplink

hamen commented Sep 4, 2026 •

edited

Loading

Uh oh!

hamen commented Sep 4, 2026

Uh oh!

kkuan2011 left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

hamen commented Sep 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

hamen commented Sep 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why

What changed

Deviations from the published page

Checks

Uh oh!

hamen commented Sep 4, 2026

Uh oh!

kkuan2011 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

hamen commented Sep 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

hamen commented Sep 4, 2026 •

edited

Loading