FilmFrame on a Sony A7: PMCA Feasibility

Related: Projects/FilmFrame

A feasibility audit of porting Projects/FilmFrame — a modern Kotlin/CameraX/OpenGL camera app — to the Sony A7-generation cameras that have a real Android subsystem (PMCA: PlayMemories Camera Apps). Three questions: does it run native code at all, can you sideload without "jailbreaking," and can FilmFrame's signature feature (live-view film LUTs) actually work on that hardware.

TL;DR

You can run custom Android apps on the original A7, A7R, A7S, A7 II, A7R II, A7S II — not the A7 III or later. The Mark III generation switched to the CXD90045/CXD90057 SoCs with cryptographically signed firmware. Sideloading is gone there.
No jailbreak required. Sony's own app-install authentication was reverse-engineered. You use the sony-pmca-re toolchain over USB. The OpenMemories ecosystem is a turnkey path. Sony retired the official store but the auth flow it used still works.
The platform is Android 2.3.7 (Gingerbread), API 10, Java 1.6, no Kotlin, no NDK exposure, no OpenGL ES shaders. You don't port FilmFrame; you rewrite it. Roughly nothing from your current codebase transfers.
Live-view 3D LUTs (FilmFrame's headline feature) are effectively impossible on this hardware. The Sony preview pipeline writes pixels straight to the surface from the ISP. There's a PreviewAnalizeListener and a YUVPlaneExtractor, but driving a per-frame 3D LUT in pure Java 1.6 on a Cortex-A5 against a high-frame-rate preview is not realistic. You can overlay UI on top of the preview, you can install a 1D gamma curve via CameraEx.GammaTable, and you can run LUTs on captured JPEGs after the fact. That's the achievable subset.
The achievable subset is interesting on its own — XPan-style crop guides in the EVF, intervalometers, custom histogram/level overlays, post-capture LUT bake, tweak unlocks — but it's not FilmFrame. It's a different app.

The Platform

Sony's BIONZ X-era cameras are not "just an embedded camera." They run a Linux kernel with an Android 2.3.7 (Gingerbread, API level 10) userland on top, on a quad-core ARM Cortex-A5 SoC (CXD90027GF on the original A7, with the CXD4236 ISP doing the actual imaging work). The Android part is what PMCA apps target. The imaging pipeline is hardware/firmware that the apps poke at through Sony-specific Java classes.

The exposed Sony APIs live in three rough namespaces, all wrapped by the community OpenMemories-Framework:

com.sony.scalar.hardware.CameraEx — Extends android.hardware.Camera (the old camera API, not Camera2). Exposes Sony-specific controls: aperture, shutter, ISO, focus drive, focus areas, white balance, metering modes, picture review, NDFilter, GammaTable, IntervalRec, direct shutter, picture-review pipeline. About 80+ inner classes/listeners.
com.sony.scalar.graphics — JpegExporter, OptimizedImage, OptimizedImageFactory, ImageAnalyzer, and an imagefilter package of fixed effects (ContrastPlus, Crop, FaceNR, Miniature, RedEye, Rotate, Scale, SoftFocus, SuperResolution). No 3D LUT filter. No custom-shader filter.
com.sony.scalar.hardware.{DSP, DeviceMemory, DeviceBuffer, YUVPlaneExtractor} — Low-level memory and a YUV plane extractor. The most interesting tools for anyone who wants to read preview pixels, but undocumented and platform-specific.

Build-side: compileSdkVersion 10, targetSdkVersion 10, sourceCompatibility 1.6. Old Gradle. No AndroidX, no Jetpack, no Compose, no CameraX, no Kotlin runtime, no Hilt. Java 1.6 with a vendor framework.

Sources: the actual PMCADemo app's build.gradle, AndroidManifest.xml, and CameraActivity.java (github.com/ma1co/PMCADemo); the stubs tree of OpenMemories-Framework (github.com/ma1co/OpenMemories-Framework).

Sideloading: No Jailbreak Required

PMCA installation was reverse-engineered, not bypassed. Sony's pipeline goes:

Browser plugin → camera over USB sends an XPD file (ini + HMAC).
Camera contacts a portal URL over SSL-tunneled USB, sends serial number/firmware/battery/installed apps.
Portal returns a JSON with an SPK URL.
Camera fetches the SPK (AES-encrypted APK + RSA-encrypted decryption key), decrypts, installs.

ma1co's sony-pmca-re stands a local server in front of step 3, hands the camera an SPK pointing at whatever APK you built, and the camera installs it. Sony explicitly accepts both debug and release certificates. "No origin verification is performed in the whole process." This is the load-bearing fact that makes the whole community possible.

Practical install path:

build APK → pmca-gui (Mac/Win) → connect camera USB →
camera enters "MTP / mass storage" mode → tool drives the flow → app installed

Two important caveats:

Browser-plugin path is dead. It needed IE/Safari with the official Sony plugin, and Sony killed it. Use pmca-gui or pmca-console USB instead.
Firmware updates released June 2017 and later are not compatible with the browser-based installer. For A7-family cameras you'd want to be on the latest firmware that predates that block, or use the USB tools that bypass it. The community has working installs on A7R II up through at least firmware 4.0.
CXD90045 / CXD90057 SoCs are walled off entirely. That cutoff captures roughly every Alpha released from 2018 onward: A7 III, A7R III, A7R IV, A9, A9 II, A1, A7S III, A7 IV, A7C, A7C II, A9 III. None of these are sideloadable through this path. Sony has not been re-broken since.

The OpenMemories ecosystem usually pairs your app install with OpenMemories: Tweak, which adds telnet on port 23 and adb on 5555 over the camera's WiFi. That's the deeper jailbreak-adjacent layer — root shell on the Linux side. Useful for debugging your app, not required to install it.

Sources: github.com/ma1co/Sony-PMCA-RE, github.com/ma1co/Sony-PMCA-RE — AppInstallation.md, github.com/ma1co/OpenMemories-Tweak.

FilmFrame Feature-by-Feature on PMCA

What FilmFrame does today on a Pixel 10 Pro, and what each feature would look like on an A7:

FilmFrame feature	Modern Pixel stack	A7 / PMCA reality
Live-view 3D LUT (film simulation)	OpenGL `CameraEffect` shader on CameraX preview	No path. Preview surface is written directly by Sony's ISP; no shader hook into the preview. YUV plane access exists but pulling, color-managing, and uploading every frame in Java 1.6 on Cortex-A5 will not hit anything close to viewfinder framerate.
1D tone curve / B&W / contrast	Subset of the LUT shader	Achievable. `CameraEx.GammaTable` installs a custom gamma curve into the imaging pipeline. Maps to S-curves, B&W via desaturation + curve, contrast shaping. Not 3D color rotation.
Aspect ratios incl. XPan (65:24)	Letterbox overlay on viewport	Achievable. Camera always shoots 3:2; you draw black letterbox bars on a transparent `View` above the camera SurfaceView. Save-time crop uses `CropImageFilter` or post-processed JPEG.
Manual controls (ISO, shutter, focus, EV, WB)	CameraX `Camera2` interop	Achievable. `CameraEx` exposes nearly all of these as listeners and parameter modifiers. This is the original sell of PMCA — every "Smart Remote" / "Time-Lapse" / "Multiple Exposure" app is built on these primitives.
RAW/DNG export	CameraX `DNG_FORMAT` + GPU pipeline	Out of reach. The capture pipeline writes Sony ARW files at the firmware level. Apps don't insert custom RAW processing into that path.
Focus peaking (GPU LoG)	OpenGL shader on preview	Effectively out. Same preview-pixel problem. Sony already has its own focus-peaking on the A7 — better to expose that toggle than rebuild it.
Horizon level	Sensor fusion → overlay	Achievable. Sensors are reachable; overlay rendered on top of preview View.
Histogram	From preview pixels	Partially achievable. Sony exposes a `Histogram` meta class and the camera computes one on the imaging side. App reads, app draws. Don't try to compute one in Java.
Film grain (animated)	Per-frame noise on preview shader	No path on preview. Can be baked into post-capture JPEG only.
Rule-of-thirds / golden ratio grids	Overlay	Achievable. Plain Android `View` draw.
Settings persistence	SharedPreferences	Achievable. Same Android primitive.
LUT-on-captured-JPEG	Same shader applied to capture	Achievable but slow. Read JPEG, apply LUT in Java/Bitmap, write JPEG. Cortex-A5 will take real time per shot. Cinestill 800T applied per shot in ~2–5s is plausible.

The honest summary: most of the "manual rangefinder camera with film aesthetic and XPan crop" UX ports. The live-view part of "film simulation" does not. You'd ship something more like "FilmFrame-Lite: XPan finder, intervalometer, custom curves, post-capture film bake" on an A7 II.

Effort Estimate

Working backwards from FilmFrame's current Pixel-only state:

Re-platforming, not porting. Different Android version, different language version, different framework, different camera API, different graphics stack, different SoC. Reuse is conceptual, not literal — the LUT files (.cube, Hald PNGs) can carry over, the math of curve mapping carries over, the UI ideas carry over. The code does not.
Learning curve. PMCA development is a small, slow-moving community. OpenMemories-Framework is "still under development. Most wrappers aren't available yet." The PMCADemo is your primary tutorial. There is no Stack Overflow tag. You'll be reading decompiled Sony Java and forum posts from 2016–2019. Plan for the first weeks to be sense-making rather than building.
Tooling. You need pmca-gui for installs, a supported A7-series camera (preferably A7 II / R II / S II for the Mark II ISP and EVF), and patience with USB connection flakiness. Optional: install OpenMemories: Tweak for telnet/adb debugging.
Realistic milestones if you wanted to actually build it:
1. Build PMCADemo, install it, get "Hello World" rendering on the rear screen of an A7 II. (Half a weekend if everything works.)
2. Draw an XPan letterbox overlay on top of the live view, with a toggle button mapped to the camera's hardware button. (One weekend.)
3. Install a custom GammaTable and ship a "B&W finder" mode. (One weekend to prove out, more to polish.)
4. Post-capture LUT bake on JPEGs with progress UI. (Real work — image read/write loops, performance tuning, RGB conversion.)
5. Full app with intervalometer, brackets, level, histogram, grid overlays. (Several weekends.)
What you will not be able to do. A live-view film simulation that looks like FilmFrame's current preview. Stop wanting this on this hardware. The closest you'll get is GammaTable + a post-capture bake of the LUT to the saved JPEG, with the preview showing only the gamma shape.

Architecture Notes Worth Remembering

A few things that are easy to get wrong on first reading:

"It's Android" is misleading. The userland is Android, but the camera is not a phone with an attached sensor. The sensor → ISP → encoder pipeline runs on dedicated Sony hardware below the Android layer; the Java apps decorate, control, and consume the outputs of that pipeline. The closest mental model is "Sony built a Java SDK on top of an embedded camera DSP, and shipped it on a vendor-frozen Android 2.3 base." Sony's own apps (Smart Remote, Time-Lapse, Sky HDR) are nothing more than UI layers and parameter automation over the same CameraEx you'd be using.
Preview is not a surface you can read from. It's a surface the ISP writes to. PreviewAnalizeListener gives you analyzed data (face detection, etc.) on a parallel path. The actual preview pixels, in a form a 3D LUT could chew on at framerate, are not where the API meets you.
GammaTable is the entire LUT story. That's the only place you can perturb the imaging pipeline before it hits the preview. A 1D table per channel is a real tool — it gives you tone curves, B&W conversion, color casts — but it can't rotate hues across the cube the way a 3D LUT does. The Fuji Astia look isn't reachable via gamma alone.
Capture happens through Sony's pipeline, period. You can name the file. You can post-process the JPEG. You can't intercept between sensor and JPEG.
No GPU compute. Cortex-A5 has no NEON-equivalent SIMD path exposed through API 10 the way modern Android does, and the GPU on these cameras is not addressable as a general compute device. Everything you do in software is single-threaded Java by default. Use the imaging hardware (CameraEx, ImageFilter) where you can; don't try to be CameraX on a 2014 chip.

What This Analysis Can't Resolve

A few unknowns I didn't pin down and that would matter if you actually started building:

Exact frame rate hit of PreviewAnalizeListener data on the A7 II. It's the only candidate path to a live preview-pixel hook, even at reduced resolution. Worth measuring before declaring live LUTs fully impossible — there might be a 5–10fps "Polaroid finder" mode that's acceptable as a different product.
Does GammaTable apply to preview, capture, or both? The class name lives in CameraEx, but the actual write-through behavior isn't documented in the wrappers. Need to test.
What firmware versions on which A7-series body are easiest right now in 2026. The June 2017 cutoff matters; the question is which used bodies on the market today happen to be sitting on pre-cutoff firmware vs. which need a downgrade. Active community knowledge, not stable docs.
Whether anyone has published a working live-view overlay PMCA app (not just intervalometer/time-lapse). I couldn't find a community example doing what the XPan crop guide would do; might be a first.

A Smaller, More Honest Project

If the actual question under the question is "I have a film-aesthetic camera app and I want it on real glass with a viewfinder," the realistic PMCA project isn't FilmFrame-the-port. It's something like:

XPan Finder for A7 II — letterbox overlay, hardware-button-bound, optional GammaTable for B&W or warm-tone preview, post-capture bake of a chosen LUT to JPEG, intervalometer. Maybe a level overlay and rule-of-thirds. Ships as a single PMCA app installable via OpenMemories.

That's the version that can actually exist. It uses what PMCA gives you and stops fighting it. The Pixel version of FilmFrame stays the place where the GPU-shader film simulation lives. The A7 version is a different artifact with the same aesthetic DNA — viewfinder framing and post-capture film color — running on glass that Sony stopped maintaining.