History

Kayos a13896f5e9 v0.1.0-W (vc=10): U-4 + U-5 — channels via rustypipe + rip NewPipeExtractor channel_info(url) UniFFI suspend fn. ChannelViewModel + SubscriptionFeedViewModel both swap. NewPipeExtractor (Java) is OUT — zero org.schabi.newpipe classes in the APK now. Cleanup: - NewPipeDownloader.kt deleted (was the OkHttp adapter) - Thumbnails.kt deleted (rustypipe returns full URLs) - NewPipe.init() dropped from StrawApp.onCreate - libs.newpipe.extractor removed from build.gradle.kts - STRAW_USER_AGENT + strawHttpClient() now live in net/Http.kt - RydClient + SponsorBlockClient + PlayerScreen + PlaybackService all read from net/Http.kt instead of the extractor package rustypipe API quirks beat: - channel_videos(id) is the right method (channel() doesn't exist) - ChannelInfo struct = basic metadata; Channel<T> wrapper carries name/avatar/banner + .content is the paginator of videos - description is String (not Option), subscriber_count is Option<u64> End state: strawApp Kotlin is ~UI + thin glue to strawcore. The Rust core handles search / streamInfo / channel / channel_videos via UniFFI suspend fns. Tokio + reqwest + rustls + rquickjs all packed in libstrawcore.so (~6MB per ABI). APK 40MB total.		2026-05-24 09:11:14 -07:00
..
strawcore	v0.1.0-W (vc=10): U-4 + U-5 — channels via rustypipe + rip NewPipeExtractor	2026-05-24 09:11:14 -07:00
Cargo.toml	v0.1.0-V (vc=9): U-3 — streamInfo via rustypipe drives VideoDetail+Player	2026-05-24 08:52:43 -07:00
README.md	v0.1.0-U (vc=8): Phase U-1 + U-2 — Rust core + rustypipe search	2026-05-24 08:36:50 -07:00

README.md

`rust/` — strawcore: Rust YouTube core for Straw

Phase U- of the Straw build. Goal: replace the Java NewPipeExtractor dependency with a Rust core (rustypipe + tokio + reqwest), exposed to the Kotlin/Compose UI via UniFFI. Compose UI stays in Kotlin — only the YouTube/Innertube fetching layer moves to Rust.

Phases

Phase	What
U-1	Toolchain + UniFFI smoke test (`hello_from_rust`) round-tripping through JNA. No real APIs yet.
U-2	rustypipe search. `SearchViewModel` calls the Rust core.
U-3	rustypipe streamInfo + streams. `VideoDetailViewModel` + `PlayerViewModel` use it.
U-4	rustypipe channel + tabs. `ChannelViewModel` + `SubscriptionFeedViewModel`.
U-5	Rip NewPipeExtractor Java dep. Measure APK + cold-fetch latency before/after.
U-6 (stretch)	SponsorBlock + RYD HTTP through reqwest + tokio in the same lib.

Build chain

crafting-table
├── rustup stable (target add: aarch64-linux-android, armv7-linux-androideabi,
│                  x86_64-linux-android, i686-linux-android)
├── cargo-ndk      (cross-compile helper)
├── android-sdk    (ANDROID_HOME, sdkmanager, build-tools, platforms)
└── android-ndk    (ANDROID_NDK_HOME, r27c LTS at /caches/android-sdk/ndk/...)

Gradle (strawApp/build.gradle.kts)
├── cargoBuild         Exec task → cargo ndk -t <abi>... -o jniLibs/ build --release
├── uniffiBindgen      Exec task → cargo run --bin uniffi-bindgen ... --library libstrawcore.so
└── source-set wiring  generated Kotlin lands in strawApp/src/main/java/uniffi/strawcore/

Runtime (StrawApp.onCreate)
├── System.loadLibrary("strawcore")
└── uniffi.strawcore.initLogging()

Why UniFFI (and not raw JNI / JNA bindings)

Hand-written JNI: tedious, error-prone, every type change is two files (Kotlin + Rust) that must stay in sync.
Raw JNA: better, but you still hand-write the Kotlin side and worry about string ownership.
UniFFI: write Rust, annotate with #[uniffi::export], get a Kotlin shim generated. Strings, structs, enums, Result types, async functions all cross the boundary transparently. The runtime is JNA under the hood.

When in doubt

cargo check -p strawcore --target aarch64-linux-android — fast iteration.
cargo run --bin uniffi-bindgen -- generate ... — regenerate Kotlin bindings.
adb logcat -s strawcore — Rust log::info!() lands here.
aapt dump badging strawApp/build/outputs/apk/debug/strawApp-debug.apk — inspect what ABIs/native-libs the APK carries.