Persist application settings locally

[SamratB8]

Summary

Create a reusable settings-storage service for saving and loading WinDroid Runtime application preferences.

The first version should support persistence of the custom ADB path and should be designed so additional application settings can be added later.

The implementation should be separated from WinUI so it can be tested independently.

Background

The ADB settings page allows users to configure a custom adb.exe location.

Without persistent storage, that selection would be lost whenever WinDroid Studio is closed. This issue adds a small and reliable local configuration layer.

Dependencies

This issue depends on:

• Issue Create basic ADB configuration model #2 — Create basic ADB configuration model

It may also be used by:

• Issue docs: add CONTRIBUTING.md #13 — Add ADB settings page

The settings-storage implementation should not depend directly on WinUI controls.

Proposed Architecture

Create a small abstraction such as:

public interface ISettingsStore
{
    Task<AppSettings> LoadAsync(
        CancellationToken cancellationToken = default);

    Task SaveAsync(
        AppSettings settings,
        CancellationToken cancellationToken = default);
}

The exact interface may be adjusted to match the existing codebase.

Possible implementation:

src/
└── WinDroid.Core/
    ├── Configuration/
    │   ├── AppSettings.cs
    │   └── ISettingsStore.cs
    └── Services/
        └── JsonSettingsStore.cs

Tests may be placed under:

tests/
└── WinDroid.Core.Tests/
Storage Requirements

The first implementation may use:

• A local JSON configuration file, or
• An appropriate Windows application-settings mechanism

The selected approach should:

• Work with the current unpackaged WinUI application
• Use a user-specific application-data location
• Avoid writing settings into the source repository
• Avoid requiring administrator privileges
• Avoid storing settings beside the executable when that location may be read-only

Data Requirements

The settings model should initially support:

• Custom ADB executable path
• Whether automatic ADB detection should be preferred
• A settings schema or version field if useful

The structure should be easy to extend later.

Error-Handling Requirements

The settings service should handle:

• Missing settings file
• Empty settings file
• Invalid JSON
• Unsupported or incomplete settings values
• File-access failures
• Serialization failures

A missing or malformed settings file should not crash WinDroid Studio.

Where possible, the service should fall back to safe default settings.

Security Requirements

The settings file must not contain:

• Passwords
• Access tokens
• API keys
• Authentication cookies
• Private signing material
• Other secrets

Paths should be treated as untrusted input and validated before use.

Tasks

• Create an application settings model
• Create a settings-storage abstraction
• Implement local settings loading
• Implement local settings saving
• Create safe default settings
• Handle malformed or missing files gracefully
• Add atomic or safe-write behavior where practical
• Add cancellation support where appropriate
• Add tests for normal and failure cases
• Document where settings are stored
• Integrate the service with the ADB configuration model
• Suggested Tests

Add tests for:

• Loading when no settings file exists
• Saving and reloading valid settings
• Loading malformed JSON
• Loading an empty file
• Loading an incomplete settings object
• Overwriting existing settings
• File-access failure where practical
• Preserving Unicode and spaces in paths
• Cancelling an asynchronous operation

Tests must use temporary directories and must not modify the developer's real application settings.

Out of Scope

This issue does not need to:

• Store secrets
• Add cloud synchronization
• Add user accounts
• Add roaming settings
• Add registry-based storage
• Add a full dependency-injection framework solely for this feature
• Implement the settings-page UI
• Validate whether the saved ADB executable works correctly

Acceptance Criteria

• Application settings can be saved locally.
• Application settings can be loaded after a simulated restart.
• A custom ADB path survives a save-and-load cycle.
• Missing settings produce safe defaults.
• Malformed settings do not crash the application.
• The storage service is independent of WinUI controls.
• No secrets are written to the settings file.
• Tests use isolated temporary storage.
• Relevant unit tests pass.
• The full solution builds successfully in Debug and Release configurations.
• No new compiler warnings are introduced.