dtourolleandClaude Opus 5
09dddde594
FR-PLAT-AND-6 asks for two things this app did neither of: be a receiver for image view and share intents, and share exported results out through a FileProvider. The manifest declared one activity with one MAIN/LAUNCHER filter, so nothing on the device ever offered DarkRoom for a photograph, and there was no route out at all — Android has refused file:// URIs between apps since API 24, and a content:// URI needs a provider to be behind it. Inbound. Three filters now: VIEW for a gallery or a file manager, SEND and SEND_MULTIPLE for the share sheet, all on image/*. `android_main` reads the launch Intent before it gives `app` away to Slint, and what comes back is passed to `dr_ui::run` exactly as argv is on the desktop — `startup_action` already treats a non-empty list as "the user asked for these specifically", which is what a share is. The URIs are copied into the cache before the viewer opens, and that cost is real: a shared raw file is written once, in full, on the startup path. A content:// URI is a handle into another app's provider, not a path, and the decoders take paths; the alternative is teaching the whole read path about URIs, which is FR-PLAT-AND-1's SAF connector and is not built. Outbound. ExportProvider serves one directory — getFilesDir(), which is the same path `internal_data_path` gives the Rust side — and refuses everything else by canonicalising the request and checking it is inside that root, so `../` and a planted symlink fail the same test. Not AndroidX's FileProvider, because AndroidX is a Maven artefact and this build has no resolver; what it does is a hundred lines and they are here. The share half has no caller. The provider, the URI grant and the chooser are all in place, but the control that would invoke them belongs in `ui/dr-ui`, and wiring it needs an `AndroidApp` the interface can reach. It is documented as unwired and deliberately not tagged as covering the requirement. `launchMode="singleTask"` comes with the filters and is not decoration: another app can now launch this activity while it is running, and the default mode answers that by creating a second NativeActivity in the same process — a second android_main, a second Slint backend, a second wgpu device. The cost of the fix is stated in the manifest: a share arriving while DarkRoom is already open brings it forward without opening the image, because onNewIntent has no route through android-activity's event stream. The Java is Java because Android constructs it: a ContentProvider is instantiated by the system from its manifest entry, and getIntent() exists only on an activity object. Both directions live there rather than in JNI so that what crosses the boundary is two method signatures instead of forty, each of which is a string checked at run time and nowhere else. What a test can hold: the declarations. Nothing about an Intent or a ContentProvider is reachable from `cargo test`, but an intent filter that is deleted takes the app out of every "open with" menu silently, and an authority that stops matching its class raises a SecurityException inside somebody else's app. The tests in lib.rs read the manifest and ExportProvider.java through `include_str!` and hold both to that, on the host, which is the only place in the workspace that looks at either file from Rust. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
50 lines
2.1 KiB
TOML
50 lines
2.1 KiB
TOML
[package]
|
|
name = "darkroom-android"
|
|
version.workspace = true
|
|
edition.workspace = true
|
|
rust-version.workspace = true
|
|
license.workspace = true
|
|
|
|
# A cdylib, not a bin: Android loads the app as a shared library and calls
|
|
# `android_main` through android-activity's glue. Nothing execs a binary, so
|
|
# there is no `main` to provide.
|
|
[lib]
|
|
name = "darkroom"
|
|
crate-type = ["cdylib"]
|
|
|
|
[dependencies]
|
|
# No backend feature to select: dr-ui picks its Slint backend from the target,
|
|
# so building for aarch64-linux-android gets android-activity automatically.
|
|
dr-ui.workspace = true
|
|
# For `account::set_data_dir`: only the platform entry point knows where Android
|
|
# lets this app keep files, and it must be set before any store is opened.
|
|
dr-sync.workspace = true
|
|
# Directly, not just through dr-ui: `android_main` takes an `AndroidApp` and
|
|
# calls `slint::android::init`, both of which come from this crate. The backend
|
|
# feature comes from dr-ui's target-specific dependency.
|
|
slint.workspace = true
|
|
log.workspace = true
|
|
android_logger = "0.15"
|
|
|
|
# The launch Intent and the share sheet are Java-only surfaces — see `intents`
|
|
# — and JNI is the only way to reach them.
|
|
#
|
|
# Target-gated because the crate still has to compile on the host: it is a
|
|
# workspace member, `cargo test --workspace` builds it, and the manifest tests
|
|
# in `lib.rs` are the one part of it that runs there.
|
|
#
|
|
# 0.21 rather than the 0.22 that android-activity 0.6 uses. Both are already in
|
|
# the lock — Slint's Android backend depends on two major versions of
|
|
# android-activity and pulls both — so this adds nothing to the build either
|
|
# way, and every object here comes from a raw pointer rather than from a type
|
|
# android-activity handed over, so the two never have to agree.
|
|
[target.'cfg(target_os = "android")'.dependencies]
|
|
jni = "0.21"
|
|
|
|
[features]
|
|
# Mirrors darkroom-desktop: the CPU readback path is gone since S1 landed
|
|
# zero-copy. It mattered more here than on desktop — the same wrong path with
|
|
# far less memory bandwidth to absorb it (ARCH §6.1) — but it is untested on a
|
|
# device, since S1 was verified on desktop only.
|
|
default = []
|