<?xml version="1.0" encoding="utf-8"?>
<!--
  The FileProvider's roots. This file OVERRIDES the one `tauri android init`
  generates (gen/android/app/src/main/res/xml/file_paths.xml, gitignored),
  through the whole-tree res overlay copy in build.sh and dev.sh.

  The generated file's two roots are kept here VERBATIM, names included.
  Nothing in this repo calls getUriForFile today, so neither is in use — but
  a tauri plugin update could start using either, and a root that quietly
  changed name would break it with an IllegalArgumentException nobody
  expects.

  The two new roots are round fifty's: Android Auto browses the library with
  the app not running, and every cover it shows has to be a `content://` URI
  (Auto supports that scheme and android.resource:// and no other — not
  file://, not http). The covers live in two places and NEITHER is under any
  of the tags that were here:

    <download_dir>/.soulstream/art/…      the masters
    <cacheDir>/art-thumbs-v1/…            the 360 px thumbnails

  and `download_dir` is `<dataDir>/Library` by default — `dataDir` being
  Android's getDataDir(), /data/user/0/com.soulstream.app — or a folder the
  user picked, which the storage plugin resolves to a real path under
  /storage.

  NOT `files-path`. That tag maps getFilesDir(), which is dataDir + "/files",
  and nothing the library keeps is under it: `paths::app_data` is tauri's
  app_data_dir(), which on Android is PathPlugin.getDataDir ->
  activity.dataDir, the PARENT. A files-path root would make getUriForFile
  throw for every single cover, in both the private-default and picked-folder
  configurations — and the symptom is a car full of grey squares with nothing
  in any log.

  Narrow on purpose, rather than root-path ".". `ss_app_data` is exactly this
  app's own data directory; `ss_volumes` is the storage mount point, which
  covers a picked folder on an SD card as well as on the built-in volume.
  Neither widens what the existing roots reach: the provider is
  android:exported="false", getUriForFile picks the LONGEST matching root (so
  /storage/emulated/0 still resolves through `my_images` and the cache
  through `my_cache_images`), a URI is readable only by a package the app
  called grantUriPermission for, on that exact URI — and the only paths ever
  handed to it came out of the app's own database.
-->
<paths xmlns:android="http://schemas.android.com/apk/res/android">
  <external-path name="my_images" path="." />
  <cache-path name="my_cache_images" path="." />
  <root-path name="ss_app_data" path="data/user/0/com.soulstream.app" />
  <root-path name="ss_volumes" path="storage" />
</paths>
