Added native Windows ARM64 build and installer to Fladder

[talynone]

Pull Request Description

Added native Windows ARM64 support to Fladder, including build configuration, CI/CD integration, and installer setup. This enables the application to run natively on Windows ARM64 devices (e.g., Surface Pro X, Windows 11 ARM).

With the rising popularity of Windows ARM64 devices, such as the latest Surface / Snapdragon X laptops, and soon to be released Snapdragon X2 devices and Nvidia N1X SOC users are increasingly expecting native applications.

Currently this is in Draft mode due to several reasons:

• The Flutter ARM64 SDK is only available in Flutter master channel ([Windows Arm64] Create Flutter SDK for Windows Arm64 flutter/flutter#136417)
• media_kit_libs_windows_video had no Windows ARM64 build. This presented the main challenge. I noticed Fladder's version (https://github.com/DonutWare/media-kit) is forked from https://github.com/media-kit/media-kit. I forked the upstream version and added Windows ARM64 support (https://github.com/talynone/media-kit/tree/WINARM64) with a pending pull request (Add Windows ARM64 support for CI/CD and flutter-windows-ANGLE-OpenGL-ES Windows ARM64 binaries  media-kit/media-kit#1381). That fork depends on the flutter-windows-ANGLE-OpenGL-ES binaries, which I also had to fork (https://github.com/talynone/flutter-windows-ANGLE-OpenGL-ES/tree/WINARM64) to add Windows ARM64 support (Added native Windows ARM64 support alexmercerind/flutter-windows-ANGLE-OpenGL-ES#6). Once all pull requests are merged upstream I can move them up the line. For now it's pointing to my forks while in draft form.

Key Changes:

• Added Windows ARM64 build job to GitHub Actions workflow
• Created ARM64-specific Inno Setup installer configuration with unique AppId
• Configured dependency override for media_kit_libs_windows_video to use ARM64-compatible fork
• Fixed RepeatMode import conflicts in playback models

Issue Being Addressed

Windows ARM64 devices could not run Fladder natively and had to rely on x64 emulation. This PR enables native ARM64 builds for optimal performance on ARM-based Windows devices.

Technical improvements:

• Native ARM64 execution eliminates emulation overhead
• Separate AppId ({D573EDD5-117A-47AD-88AC-62C8EBD11DC8}) prevents installation conflicts between x64 and ARM64 versions
• Both architectures can be installed side-by-side for testing
• ARM64 installer clearly labeled as "Fladder (ARM64)" in Windows Settings

Automated Test Builds

A build, both in portable and installer versions, are available from the GitHub Actions artifacts here:
https://github.com/talynone/Fladder/actions

Screenshots / Recordings

Checklist

• If a new package was added, did you ensure it works for all supported platforms? Is the package well maintained
  • Updated media_kit_libs_windows_video dependency to use ARM64-compatible fork (talynone/media-kit ref: WINARM64)
• Check that any changes are related to the issue at hand.
  • All changes support Windows ARM64 native builds
  • Fixed unrelated RepeatMode import ambiguity issues discovered during ARM64 build testing

Files Changed:

• .github/workflows/build.yml - Added build-windows-arm64 job using windows-11-arm runner
• windows/windows_setup_arm64.iss - New ARM64 installer configuration with unique AppId
• pubspec.yaml- Updated media_kit_libs_windows_video dependency override
• lib/models/playback/direct_playback_model.dart - Fixed RepeatMode error import errors when building locally. Error was: (is imported from both 'package:fladder/jellyfin/jellyfin_open_api.enums.swagger.dart' and 'package:flutter/src/widgets/repeating_animation_builder.dart'. ) by providing JellyFin alias
• lib/models/playback/transcode_playback_model.dart - Fixed RepeatMode import (see above)

[talynone]

@PartyDonut I contacted the maintainer of the media-kit and flutter-windows-ANGLE-OpenGL-ES repos after a month of no responses. He said he has no bandwidth to deal with maintaining those repos. So I'm moving this out of draft and just pointing to my fork for now.

Currently this pull request grabs from my fork of media-kit in ‎pubspec.yaml (https://github.com/talynone/media-kit). This fork is based on latest official media-kit with my changes for Windows ARM, and I also manually added your changes from your fork for newer mpv versions.

Maybe copy my media-kit fork wholesale would be easiest since it also has all your changes?

[PartyDonut]

I appreciate all the work, but I'm kind of reluctant to merge this.

Until the other projects provide direct support this would give us a lot to maintain for what is probably a pretty small portion of users.

So my suggestion for now would be let's to at least wait for Flutter to support arm natively?

[talynone]

I appreciate all the work, but I'm kind of reluctant to merge this.

Until the other projects provide direct support this would give us a lot to maintain for what is probably a pretty small portion of users.

So my suggestion for now would be let's to at least wait for Flutter to support arm natively?

Up to you, the code base is 99% the same/shared. The GitHub build directive is really the only code that needs to be possibly updated at some point since it's pinned to particular Flutter master branch commit (newer commits break the build even for x64/other platforms right now as they're moving things around in master right now). The way the GitHub action is defined only the Windows ARM build is pointed to the Flutter master branch. The only other maintainance point is just pointing to newer mpv builds in media-kit once in a while, but that's super easy and needs to be done for all platforms anyways.

A lot of the Flutter team was relocated/laid off so who knows how long it will take them to release to beta/stable channels.

Other projects such as Plezy are just using the master Flutter branch for their Windows ARM build like like in this merge. You could also list the download as beta if you wish. Otherwise I can try to maintain the fork with downloads for ARM only on my fork. There aren't really good native rich clients for JellyFin for Windows ARM so I've been actually using this fork for several weeks.

Status of Flutter to stable channel can be monitored here:

flutter/flutter#176385