[eugene-mux]

Description

Release Android Upload SDK 1.1.0 with HEVC-aware input standardization and reliable generated-file resume.

Changes

• Preserve H.264/HEVC on supported conversions, validate generated output, and upload originals when preparation is unsupported or fails.
• Default to 1080p generated output; offer 1440p/2160p limits, eligible HDR preservation and opt-in tone mapping.
• Require Android API 23+, Kotlin 2.1+, AGP 8.10+ and compileSdk 36+. Android 6 uploads originals; local conversion requires Android 7 (API 24)+ and a supported input/device.

Validation

• Merge NAT-551: Capability checks and acceptance fixes #176 into this branch before release. It contains the final-tested capability, Builder, diagnostics, packaging and sample fixes, plus the accepted Android 6 compatibility wording.
• The combined implementation passes 323 debug + 323 release unit tests, SDK/sample release builds, vital lint analyses and packaged-consumer/R8 checks. Fixture, physical-device, sample-UI and real Mux upload/recovery evidence is summarized in NAT-551: Capability checks and acceptance fixes #176.
• Full lint on that candidate remains at 102 errors / 33 warnings versus this branch's 103 / 34. Performance acceptance is owner-deferred.

---

Note

High Risk
Large changes to on-device transcoding, resumable upload persistence, and HTTP resume semantics directly affect what bytes reach Mux and whether interrupted uploads can safely continue.

Overview
Android Upload SDK 1.1.0 raises the platform floor (API 23+, compileSdk 36, Kotlin/AGP bumps) and documents default 1080p standardization plus 1440p/2160p, HdrHandling, and dependency 1.1.0.

The legacy TranscoderContext MediaCodec path is removed in favor of a Media3 Transformer–based Standard Input pipeline (metadata/sample inspection, optional SDR/HDR export, validated generated files). MuxUpload.Builder gains hdrHandling and clearer standardization docs; InputStandardization now carries HDR settings and Preset2560x1440.

Upload behavior is reworked around UploadAttempt, UploadSession, and UploadProtocol: stricter 308/Range acknowledgement, chunk retries with backoff, pause/cancel/restart/replace semantics (including awaitSuccess and listener deduping), and durable resume for standardized payloads via PayloadIdentity, destination block lists, and richer UploadPersistence. MuxUploadManager restores paused jobs differently on cold start vs resumeAllCachedJobs, and failed uploads stay discoverable for retry.

ChunkWorker uses async OkHttp and one-shot counting bodies; UploadJobFactory ties preparation, transport, and cleanup together.

^{Reviewed by Cursor Bugbot for commit be9c63f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit be9c63f. Configure here.}

[daytime-em]

I did some manual testing, and it looks like something important is missing. No files are ever standardized, even when standardization is requested. All capabilities are always missing: missing capabilities [SourceDecode, SourceTimeline, VideoEncode, Remediation(requirement=AverageBitrate), Remediation(requirement=MaximumGopBitrate), Remediation(requirement=VideoResolution), AacAudioPreparation, ToneMapping]

On closer inspection, it looks like standardization is attempted despite the lack of planning capabilities. StandardInputAction.Fallback is always returned from StandardInputPlanner.plan(), but the Action's StandardInputConversion object is used. Fallback appears to be ignored as a value through the rest of the standardization process.

Outside of tests, it doesn't look like PlanningCapabilities values are ever set, leaving the default false/empty values for all the relevant fields. StandardInputPlanner.plan() has an empty capabilities as a default param, so everything still builds, but capabilities are never actually validated or provided to plan(), and the fallback behavior is always chosen.

1. avoid a default value for that parameter: there is no situation where you'd want to call plan() while also assuming no capabilities (aside from unit tests)
2. If you no longer plan on probing for device capabilities, consider deleting the Fallback Action, as it's treated the same as Convert. You can probably also delete PlanningCapabilities since it's never populated with read data.

[eugene-mux]

@daytime-em Thanks for the review - good catch! Addressed in #176: capabilities are checked before final planning, and only Convert starts conversion; Fallback uploads the original. Includes device testing and logcat evidence.