LSFG-Android brings frame generation to Android through screen capture

The Android port problem is the implicit layer

The lsfg-vk project is a Vulkan frame generation layer for Linux, and LSFG-Android brings that pipeline to Android. The difficulty is stated in the README in the first paragraph: because Android 12 and later block loading external code into non-debuggable processes, the layer cannot hook another app's swapchain the way the Linux implicit layer does.

The workaround defines the whole architecture. Instead of intercepting the game's frames at the Vulkan level, the app runs frame interpolation on a MediaProjection capture and composites the generated frames in a system overlay sitting on top of the target game. The README says end to end frame generation works today on Adreno 7xx-class GPUs and newer.

So the pipeline that Linux implements in the compositor, Android implements with a screen capture and an overlay window. That is a structural difference rather than a missing feature, and it explains the rest of the project's design, including the settings drawer, the per-app overlay arming, and the Shizuku timing mode for pacing diagnostics.

The repository has two top level directories. LSFG-Android is the Android Studio project with a Kotlin and Jetpack Compose UI plus a JNI and C++ render loop, and lsfg-vk-android is a submodule holding a branch of lsfg-vk 1.0.0 with Android specific patches layered on top, using AHardwareBuffer based image sharing, createContextFromAHB and waitIdle. All the patches sit behind #ifdef __ANDROID__, so the original Linux build path still works unchanged.

The native library is compiled, not shipped

There is no separate prebuilt .so in the release. The Android app pulls framegen/ directly from the submodule through CMake add_subdirectory(), so building the app builds the frame generation library transparently for both arm64-v8a and x86_64.

The build itself is a Gradle invocation:

cd LSFG-Android
./gradlew :app:assembleDebug         # or :app:assembleRelease

The APK lands at LSFG-Android/app/build/outputs/apk/debug/app-debug.apk, and the README says to install it with adb install. That is the first indication of the distribution model.

The toolchain is pinned closely. Android Studio Ladybug or later, NDK 27.0.12077973, CMake 3.22.1, JDK 17 and C++20, with arm64-v8a for production and x86_64 for the emulator only. The SDK floor is minSdk 29, which is Android 10, and the target is targetSdk 35, which is Android 15.

One layout constraint catches people out. CMake resolves the submodule through the relative path ../../../../../lsfg-vk-android from the JNI sources, so the two folders have to stay side by side as they are in the repository. Moving or renaming either one breaks the native build.

What the in-game drawer actually controls

The live settings drawer is the feature list of the project, and it is long enough to read as a specification.

The frame generation itself runs as LSFG_3_1 and LSFG_3_1P, on the GPU, using AHardwareBuffer sharing between the app's Vulkan session and the internal device of framegen. The drawer exposes a multiplier from 2x to 8x, a flow scale from 0.25 to 1.0, performance and HDR mode, anti-artifacts, bypass, vsync alignment with slack control, pacing presets, a target FPS cap, queue depth, and EMA jitter smoothing.

The README draws an important line inside that list. Most parameters re-initialise the native context on the fly, but bypass, pacing and Shizuku timing have hot-apply paths that do not drop the session. That is a real usability difference, because re-initialising a Vulkan context mid-game is a visible hitch and a dropped session is not.

The overlay is per app. You pick target apps and the overlay arms when one of them comes to the foreground, with two entry modes, a draggable launcher dot or an icon button on a configurable screen edge.

Permissions, and why the app is sideload only

The platform limits section is the part of the README to read before anything else, and it is blunt about the consequences.

There is no equivalent to the Linux Vulkan implicit layer mechanism on non-rooted Android, because Android 12 and later explicitly blocks loading external code into non-debuggable processes. Frame generation therefore runs on a MediaProjection screen capture stream and the result is composited in a system overlay over the target.

The costs of that design are stated as facts. It adds roughly 50 to 80 ms of latency against the Linux Vulkan layer, which is a platform constraint rather than a bug. MediaProjection also requires explicit user consent on every session start and surfaces a persistent system indicator. And the combination of SYSTEM_ALERT_WINDOW, screen capture and AccessibilityService violates Google Play policy, so the app is distributable only as a sideloaded APK.

A Magisk module that installs a Vulkan implicit layer into /system/etc/vulkan/implicit_layer.d/ is named as the only realistic path to matching the Linux experience, and it is explicitly out of scope for this project.

The licensing arrangement, stated carefully

The README carries an important notice that is easy to skim past and worth reading closely.

You need a legitimately purchased copy of Lossless Scaling. The Lossless.dll is not shipped, downloaded or bundled by anything in the repository. The user picks their own DLL through the Storage Access Framework, the app extracts the shaders on device into its private storage, and then deletes the DLL copy. Nothing about the project distributes Lossless Scaling assets.

The credits section repeats the same point from the other direction, crediting THS and Lossless Scaling as the original authors of the frame generation shaders, and saying the shaders are extracted on device from the user's own legitimately purchased copy and are never redistributed by the project.

So the arrangement is: the pipeline and the Android port are open, the shaders are yours, and the user does the extraction. That is a clearly different position from a repository that ships the proprietary bits, and anyone reading the project should be clear which half they are getting.

Touch handling is the other hard part

An overlay that draws over a game also has to get out of the way of the game's own input, and that is what the touch passthrough work is about.

The overlay can be hosted as a SYSTEM_ALERT_WINDOW, or, when the user enables LsfgAccessibilityService, as a TYPE_ACCESSIBILITY_OVERLAY. The README describes the latter as the opt-in path for OEMs with strict untrusted touch filters, and says touch passthrough works at full opacity in both modes.

The first-launch tutorial walks through the Accessibility setup, covering both the touch passthrough service and the Restricted-Settings unblock that sideloaded apps trigger on Android 13 and later. That second point is a real practical hurdle for anyone installing the APK, and the tutorial existing is a sign the author has hit it.

The rest of the feature list is more conventional. There are capture sources, with MediaProjection as the default used for the visible frames on every session, and a Shizuku metrics mode that adds a privileged target-UID-filtered timing side channel for pacing diagnostics without ever feeding Shizuku buffers into the visible video path. On the post-processing side there are NPU presets through NNAPI covering sharpen, detail boost, chroma clean and game crisp, a GPU upscaling stage, and CPU enhancement with LUT, vibrance, saturation and vignette. There is a frame graph HUD with a real versus total FPS counter, a frame time graph and pacing diagnostics, a crash reporter that captures both Java and Kotlin uncaught exceptions and native signals such as SIGSEGV and SIGABRT with stack walking and a one tap share through ACTION_SEND, a Vulkan swapchain output path for efficient presentation on top of a CPU blit fallback, and overlay components that are aware of rotation and immersive mode.

Editorial conclusion

LSFG-Android suits a developer or enthusiast who wants the lsfg-vk frame generation pipeline running on an Adreno 7xx or newer device and is comfortable sideloading a build and granting screen capture and accessibility permissions. It is the wrong tool if you need the Linux experience of a true Vulkan implicit layer, since there is no Android equivalent and the project says so directly. Before building it, read the platform limits section, confirm your GPU is in the supported range, and note the licensing requirement that you supply your own purchased copy of Lossless.dll for the shaders.

Frequently asked questions

Official sources

1. FrankBarretta/LSFG-Android on GitHub
2. Issues
3. README
4. Releases