Three of plan 016's four blockers. Each is a different reason the app could not work at all on a phone. **It had no permission to read anything.** The generated manifest asked for INTERNET, VIBRATE, biometrics, location and a camera, and nothing whatever about storage -- so at targetSdk 35 the app could see its own private directory and no music. It now declares READ_MEDIA_AUDIO, the two capped legacy storage permissions, and MANAGE_EXTERNAL_STORAGE. That last one is deliberate and is the load-bearing choice. This app is a library manager: audio_files.file_path is the primary key of ownership, the scanner walks a directory the user chose, and tagwriter rewrites files in place. MediaStore offers no stable directory to walk and no in-place write, so scoped storage is not "more work" here, it is a different application. MANAGE_EXTERNAL_STORAGE is Play-restricted, which is acceptable only because this ships as an APK through the package registry -- if it ever targets Play, that line is what has to go, and plan 016 says what replaces it. It is granted on a Settings screen rather than in a dialog, so it cannot be requested with requestPermissions(). MainActivity opens that screen on every cold start until access exists -- there is no degraded mode worth offering -- and re-checks in onResume, because the way back from another task is a resume, emitting android:storageAccess so the frontend can react. **The first-run flow could not complete.** All three call sites asked for a folder through the Wails dialog, which returns an error on Android: SAF yields tree URIs and this app is keyed on paths. So the app browses the filesystem itself, which it can now do. ListDirectories lists directories only (the thing being chosen is a library root), skips what it cannot stat rather than failing the listing (Android's storage root holds directories no app may enter), follows symlinks (os.DirEntry reports the link, so a symlinked music folder would silently vanish), and hides dotted entries. utils/pick-directory.ts is the one place that chooses between the two, so the three call sites changed by one line each. **Which platform is asked of the backend**, not of System.IsAndroid(): the dialog is backend code, so the backend is what knows whether it can open one; it answers for iOS at the same time; and it keeps the fallback testable through the ordinary transport fake rather than a module mock of the Wails runtime, whose platform helpers read build constants. **And MPRIS was compiled into the Android build**, because android implies the linux build tag, so it went looking for a session bus that does not exist. mpris_linux.go is `linux && !android` now and the stub covers Android, which means no lock-screen transport there yet -- a missing feature rather than a broken one, and the remaining blocker. The foreground service is typed mediaPlayback rather than the scaffold's dataSync, with the matching permission, so playback can survive the screen locking once there is a MediaSession to drive it. The type in the manifest and the one passed to startForeground must agree or startForeground throws.
112 lines
4.7 KiB
XML
112 lines
4.7 KiB
XML
<?xml version="1.0" encoding="utf-8"?>
|
|
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
|
|
xmlns:tools="http://schemas.android.com/tools">
|
|
|
|
<!-- Internet permission for WebView -->
|
|
<uses-permission android:name="android.permission.INTERNET" />
|
|
<uses-permission android:name="android.permission.VIBRATE" />
|
|
<!-- Observe network connectivity / type for android:NetworkChanged events -->
|
|
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
|
|
<uses-permission android:name="android.permission.USE_BIOMETRIC" />
|
|
<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />
|
|
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
|
|
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
|
|
<uses-permission android:name="android.permission.CAMERA" />
|
|
<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
|
|
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_DATA_SYNC" />
|
|
|
|
<!--
|
|
Playback has to survive the screen locking, and that needs a
|
|
foreground service typed mediaPlayback rather than dataSync. The
|
|
type in the <service> element and the permission here must agree,
|
|
or startForeground throws at runtime.
|
|
-->
|
|
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_MEDIA_PLAYBACK" />
|
|
|
|
<!--
|
|
Reading the user's music.
|
|
|
|
READ_MEDIA_AUDIO is the Android 13+ grant and READ_EXTERNAL_STORAGE
|
|
is its predecessor, capped so it is not requested where it no
|
|
longer applies. Both give access through **MediaStore**.
|
|
|
|
MANAGE_EXTERNAL_STORAGE is what gives access through the
|
|
*filesystem*, and this app needs it rather than merely preferring
|
|
it: `audio_files.file_path` is the primary key of ownership, the
|
|
scanner walks a directory the user chose, and every
|
|
GetFilePathsBy... query exists to hand a path to the player.
|
|
MediaStore offers no stable directory to walk and no way to write
|
|
a tag back in place, so the alternative is not "more work" but a
|
|
different application.
|
|
|
|
It is a Play-restricted permission, granted on a Settings screen
|
|
rather than in a dialog. That is acceptable *here* only because
|
|
this app is distributed as an APK through the package registry and
|
|
not through Play — see docs/android-release.md. If it ever targets
|
|
Play, this is the line that has to go, and plan 016 says what
|
|
would replace it.
|
|
-->
|
|
<uses-permission android:name="android.permission.READ_MEDIA_AUDIO" />
|
|
<uses-permission
|
|
android:name="android.permission.READ_EXTERNAL_STORAGE"
|
|
android:maxSdkVersion="32" />
|
|
<uses-permission
|
|
android:name="android.permission.WRITE_EXTERNAL_STORAGE"
|
|
android:maxSdkVersion="29" />
|
|
<uses-permission
|
|
android:name="android.permission.MANAGE_EXTERNAL_STORAGE"
|
|
tools:ignore="ScopedStorage" />
|
|
|
|
<queries>
|
|
<intent>
|
|
<action android:name="android.media.action.IMAGE_CAPTURE" />
|
|
</intent>
|
|
<intent>
|
|
<action android:name="android.media.action.VIDEO_CAPTURE" />
|
|
</intent>
|
|
</queries>
|
|
|
|
<application
|
|
android:allowBackup="true"
|
|
android:icon="@mipmap/ic_launcher"
|
|
android:label="@string/app_name"
|
|
android:roundIcon="@mipmap/ic_launcher_round"
|
|
android:supportsRtl="true"
|
|
android:theme="@style/Theme.WailsApp"
|
|
tools:targetApi="31">
|
|
|
|
<activity
|
|
android:name=".MainActivity"
|
|
android:exported="true"
|
|
android:configChanges="orientation|screenSize|keyboardHidden|uiMode"
|
|
android:windowSoftInputMode="adjustResize">
|
|
<intent-filter>
|
|
<action android:name="android.intent.action.MAIN" />
|
|
<category android:name="android.intent.category.LAUNCHER" />
|
|
</intent-filter>
|
|
</activity>
|
|
|
|
<provider
|
|
android:name="androidx.core.content.FileProvider"
|
|
android:authorities="${applicationId}.fileprovider"
|
|
android:exported="false"
|
|
android:grantUriPermissions="true">
|
|
<meta-data
|
|
android:name="android.support.FILE_PROVIDER_PATHS"
|
|
android:resource="@xml/file_paths" />
|
|
</provider>
|
|
|
|
<!--
|
|
mediaPlayback, not the scaffold's dataSync: this app's reason
|
|
for staying alive in the background is that a song is
|
|
playing, and Android matches the declared type against what
|
|
the service actually does.
|
|
-->
|
|
<service
|
|
android:name=".WailsForegroundService"
|
|
android:exported="false"
|
|
android:foregroundServiceType="mediaPlayback" />
|
|
</application>
|
|
|
|
</manifest>
|