Skip to content

[Feature][Android] Add page resource fetchers - #123

Open
Huxpro wants to merge 1 commit into
tiktok:agent/android-thread-strategyfrom
Huxpro:agent/android-resource-fetchers
Open

[Feature][Android] Add page resource fetchers#123
Huxpro wants to merge 1 commit into
tiktok:agent/android-thread-strategyfrom
Huxpro:agent/android-resource-fetchers

Conversation

@Huxpro

@Huxpro Huxpro commented Aug 8, 2026

Copy link
Copy Markdown
Collaborator

Summary

Add typed page-level Android Lynx resource fetchers while preserving Sparkling template and SSR lifecycle reporting.

This is the fifth layer of the Android compatibility stack and depends on the typed thread-strategy layer.

Changes

  • Add Java-friendly generic, media, and template fetcher configuration.
  • Support per-page override and optional global per-page factory.
  • Automatically enable generic fetching when configured.
  • Wrap typed template/SSR fetchers so start/finish/error forwarding remains exactly once.
  • Preserve the existing template-provider path when unset.
  • Add Kotlin and Java API tests plus lifecycle success/failure/duplicate-callback coverage.

How to test

  • Focused SDK tests passed on SG1/JDK 11.
  • Kotlin lint passed.
  • Cloud-device fetch invocation and first-screen verification will be attached before completion.

Stack

#119 -> #120 -> #121 -> typed thread strategy -> this PR

Checklist

  • I read CONTRIBUTING.md.
  • I ran relevant checks.
  • I updated docs and tests.

Device validation complete

The durable SG1 + Lynx Sandbox acceptance matrix is now available in #131. Exact validated commit: 8a2b3ea99eaa342e2f1ebfe716aefbb44f411fbb. On a fresh aries_10 device (Android 10 / API 29), all 9 tests passed, including real first-screen rendering, fixed 320x480, shared density 3.25 across two independent Lynx views, PART_ON_LAYOUT, typed template fetch invocation, orientation, retry recovery, and unsafe configuration rejection. The runner dynamically leases/releases the device and archives logs/screenshots/hashes. Evidence archive on SG1: /tmp/sparkling-android-device-acceptance-8a2b3ea.tar.gz (SHA-256 09acd64b4b63988b61e7f4f2ff11f3f7b4b4770bd3ef74a973db6dda0c9e242c).

Expanded durable device validation

The checked-in SG1 + Lynx Sandbox matrix in #131 now validates exact commit df875a87541d587ab8aa84a86600c0610f9e44c7 with 10/10 PASS on aries_10 (Android 10 / API 29). Added runtime coverage includes: the pre-load listener observing a ready bridge before template fetch; the global per-page fetcher factory; real first-screen rendering for ALL_ON_UI, MOST_ON_TASM, PART_ON_LAYOUT, and safe MULTI_THREADS; and full-page fixed-viewport + MULTI_THREADS rejection before Activity launch or transfer-station save. The runner requires a clean exact HEAD and fails closed unless Sandbox release confirms the leased serial. Evidence: /tmp/sparkling-android-device-acceptance-df875a8; archive SHA-256 712a3b83dbd78eabeae9afc0766b5b191cee0bff10e515967b3ae9f46c4feb98.

Summary of change:
- Add Java-friendly typed generic, media, and template resource fetcher configuration.
- Support a per-page override with an optional global per-page factory.
- Preserve Sparkling template and SSR lifecycle callbacks with exactly-once forwarding.
- Keep the existing template-provider path unchanged when typed fetchers are absent.

TEST: ./gradle-8.2/bin/gradle :sparkling:testDebugUnitTest --tests com.tiktok.sparkling.SparklingResourceFetcherConfigTest --tests com.tiktok.sparkling.hybridkit.lynx.SparklingResourceFetcherConfiguratorTest --tests com.tiktok.sparkling.hybridkit.lynx.SparklingTemplateResourceFetcherTest --no-daemon
TEST: PATH=/tmp/sparkling-ktlint-bin:$PATH scripts/lint.sh kotlin

Co-authored-by: TRAE CLI <noreply@bytedance.com>
@Huxpro
Huxpro force-pushed the agent/android-resource-fetchers branch from 7de7d47 to 225483a Compare August 8, 2026 20:30
@Huxpro
Huxpro requested a review from YJ-Hao August 11, 2026 10:34
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.

1 participant