christopherandClaude Sonnet 5
a89e81983e
Adds Room + WorkManager-backed offline downloads: a bitrate picker (Low/Normal/High/Original) on track and album detail screens, a Downloads library screen, and Settings additions for Wi-Fi-only downloads and default quality. Bitrate tiers route through Subsonic's `stream` endpoint with `maxBitRate`; Original uses `download`, which always returns the untranscoded source file. Three real bugs found and fixed during on-device verification: - WorkManager was constructing DownloadWorker with its default reflection-based WorkerFactory instead of HiltWorkerFactory (NoSuchMethodException on the @AssistedInject constructor). The default androidx.startup auto-init ran before Hilt's field injection was guaranteed to have happened. Fixed by disabling the manifest's auto-init provider and calling WorkManager.initialize() manually in DeepwaveApplication.onCreate(), after super.onCreate(). - Crash on every download: WorkManager's own SystemForegroundService declares no foregroundServiceType in its manifest, but the worker requests dataSync at runtime via ForegroundInfo, which API 29+ requires to be a subset of what's manifest-declared. Fixed by manifest-merging that service with foregroundServiceType="dataSync". - Offline playback was completely broken: ResolvingDataSource only rewrites the DataSpec's URI (to file:// for a downloaded track) but always hands it to the same wrapped upstream DataSource to open. OkHttpDataSource can only open http(s) URLs, so the rewritten file:// URI failed with "Malformed URL" and playback silently fell through to the network. Wrapping the signed OkHttpDataSource.Factory in DefaultDataSource.Factory routes by scheme instead - this bug was latent since Phase 4, since LocalTrackFiles was always empty until now and the local-file path was never actually exercised. - Re-downloading a track at a different quality could produce a different file extension (Content-Type-driven), orphaning the previous file on disk with no cleanup path. DownloadWorker now clears any existing files for the track id before writing the new one. Verified on-device: downloads at all four tiers produce distinctly different, correctly-ordered file sizes (Low < Normal < High < Original); a fully downloaded track keeps playing with Wi-Fi and mobile data both disabled; killing and relaunching the app mid-download lets WorkManager resume the interrupted download to a correct, byte-exact final file. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
14 lines
774 B
XML
14 lines
774 B
XML
<?xml version="1.0" encoding="utf-8"?><!--
|
|
Sample backup rules file; uncomment and customize as necessary.
|
|
See https://developer.android.com/guide/topics/data/autobackup
|
|
for details.
|
|
Note: This file is ignored for devices older than API 31
|
|
See https://developer.android.com/about/versions/12/backup-restore
|
|
-->
|
|
<full-backup-content>
|
|
<exclude domain="sharedpref" path="deepwave_master_keyset_prefs.xml"/>
|
|
<exclude domain="file" path="datastore/deepwave_credentials.preferences_pb"/>
|
|
<!-- Restoring "downloaded" rows without the actual audio files (app-specific external
|
|
storage, never backed up) would be misleading state - the DB and files must move together. -->
|
|
<exclude domain="database" path="deepwave.db"/>
|
|
</full-backup-content> |