Storage: support external volumes, existing image import, and relocation

[zennnez]

This PR adds support for external container storage, importing existing sparse rootfs images, and relocating existing containers, along with the Android storage plumbing required to make these workflows reliable.

Previously, containers were restricted to internal storage and could only be created from a tarball.

1. Custom storage location for new containers

• Added StorageLocationScreen / StorageDestinationPicker to let users select an SD card or USB-OTG path via root-shell browsing or SAF.

• ContainerManager.getRootfsPath() / getSparseImagePath() now accept an optional customStorageDir.

• Container metadata (config, .env, PID file, etc.) remains under the internal CONTAINERS_BASE_PATH; only the rootfs / rootfs.img is relocated.

• Directory-mode rootfs now requires a POSIX-compatible filesystem such as ext4/f2fs.

  • StorageChecker.inspectFilesystemCapabilities() probes:

    • chmod / chown
    • symlink support
    • noexec
    • read-only mount state

  • Incompatible filesystems such as FAT32/exFAT are rejected.

  • Advanced users can explicitly bypass the check through a "dangerous territory" override.

• ContainerInstaller:

  • Creates the external parent directory before extraction.
  • Checks free space at the actual destination.
  • Rejects sparse images >= 4 GiB on FAT32 destinations up front, avoiding failures later due to FAT32's single-file size limit.

2. Import an existing sparse rootfs image

SparseImageConfigScreen now supports three modes:

1. New sparse image
2. Existing image
3. Directory

Existing .img files can be selected through the root browser, SAF, or by choosing an .img tarball during the naming step.

The selected image is processed through ExistingImageManager.inspect(), which:

• Loop-mounts the image read-only.
• Runs e2fsck.
• Detects filesystem/image size.
• Reads /etc/os-release.
• Detects an embedded container.config, when present.

If the image contains an embedded configuration, its settings can be used to prefill the setup wizard. ContainerConfigScreen displays an override banner when this occurs.

ContainerInstaller.installFromExistingImage():

• Copies the image to the selected destination or uses it in-place.
• Runs e2fsck.
• Re-embeds the current container configuration at /etc/droidspaces.config.

This keeps imported images portable across devices.

ContainerManager.updateContainerConfig() also re-embeds the configuration whenever the container configuration is edited, keeping the embedded copy synchronized.

3. Move an existing container's storage

ContainerCard now provides a Move storage location action.

ContainersScreen displays a MoveStorageDialog that supports moving between internal and external/custom storage while reusing the same destination picker and filesystem validation used during creation.

ContainerManager.moveContainerStorage() performs a safe stop-and-move operation:

1. Verifies that the container is not running.
2. Checks destination free space.
3. Validates FAT32's 4 GiB file-size limitation.
4. Attempts a same-filesystem rename first.
5. Falls back to copy-then-delete when a rename is not possible.
6. Rewrites the container configuration to the new path.
7. Removes the old copy only after the configuration successfully points to the new location.

This ordering ensures that a crash during the move does not leave the container referencing missing data.

ContainerOperationsViewModel.executeMoveStorage() handles the UI flow, including:

• Stopping the container.
• Showing move progress.
• Surfacing errors and operation logs.

---

Supporting Android External Storage Infrastructure

RootNamespace

Root-shell commands targeting /storage or /mnt/media_rw are now routed through the volume's live physical mount point whenever possible.

When that is not possible, commands are executed inside the app's own mount namespace using nsenter. The app namespace already has a working FUSE view of external storage.

This avoids relying on root's namespace, which may not see external volumes unless a same-process bind mount happens to succeed. That behavior varies across devices and ROMs.

StorageMountManager

• Resolves SD/USB volume IDs to their current physical kernel mount points:

  • /mnt/media_rw/<volId>

• Bind-mounts them into:

  • /storage/<volId>

• Detects stale bind mounts after USB disconnect/reconnect.

• Compares device IDs instead of relying solely on mountpoint(1).

SafPathResolver

Converts Android Storage Access Framework document/tree URIs into plain filesystem paths.

This is particularly important for USB drives that are visible to SAF before the root browser can access them.

Automatic external-path recovery

ContainerManager.autoDetectAndRemapContainerPath() runs during container start/restart.

If an external rootfs path no longer exists—for example, because a USB drive was disconnected and later remounted with a different mount instance—it searches currently connected volumes for the matching rootfs and automatically rewrites the container configuration to the new path.

service.sh

The boot script now:

• Pre-creates /dev/loop0–/dev/loop7.
• Bind-mounts /mnt/media_rw/* volumes into /storage/*.
• Performs this setup before containers are started.

This allows sparse images stored on external volumes to work during boot without depending on Android having already refreshed its storage views.

---

Additional Reliability Fixes

• SparseImageInstaller now performs the complete mount/extract/postfix sequence as one atomic root-shell script with a trap-based cleanup handler.

  • Previously, these operations were split across multiple Shell.cmd calls.
  • An exception between commands could leave a loop device or mount attached.

• Export, migrate, and resize commands are now invoked explicitly through sh.

  • This avoids SELinux / noexec mount denials encountered on some devices.

Result

This PR expands container storage from a fixed internal-only model into a more flexible system supporting:

• Internal storage
• SD cards
• USB-OTG storage
• Existing sparse image imports
• In-place image usage
• Container storage relocation
• Automatic recovery after external-volume remounts

while keeping container metadata internal and adding filesystem validation and failure-safe storage operations.