Porting an Estopia App to a Sony Camera

What would it take to put a modern service on a camera that was never designed to run modern mobile software?

That question started an experimental port of an Internal Estopia app to the Sony DSC-HX60. The goal was to make the camera interface with the Estopia ecosystem: browse information, select a photograph using the camera's own controls, and publish it to Estopia Files without first manually transferring it to another device.

It is not a finished product or a complete port of the mobile app. It is a working prototype with an installed camera application, an authenticated PC gateway, and an upload workflow whose end-to-end reliability is still being validated.

A Camera Is Not a Small Phone

Estopia's existing Android application uses Kotlin, Jetpack Compose and a modern Android SDK. The camera needs a separate approach: a legacy Android-compatible build, Java 7 source compatibility, a 640-by-480 interface and hardware-button navigation.

There is no touchscreen to fall back on. Selecting an item, going back, confirming an upload and recovering from an error all have to work with physical controls. A layout that looks reasonable on a phone can be awkward or unusable here.

Rather than downgrade the existing mobile app, the camera port lives separately. It uses ordinary Android views alongside Sony-specific functionality exposed through OpenMemories: Framework. The PMCADemo project provides an important reference for hardware input, Wi-Fi settings and camera power management.

Let the PC Handle the Modern Parts

The camera's old networking environment is another constraint. Expecting it to behave like a current phone, including modern HTTPS and authentication support, would make the project much harder before it had delivered anything useful. The prototype therefore uses a local PC gateway:

Sony camera -> local PC gateway -> Estopia API

The camera handles photo selection and the physical interface. The PC runs the current Estopia SDK, keeps the OAuth session and talks to Estopia over HTTPS. Sign-in is approved in a modern browser using the device-code flow, rather than asking someone to enter a password on the camera.

For this home-network experiment, camera-to-PC traffic deliberately uses plain HTTP. That is a limitation, not a security feature: a single network hop does not make traffic private or tamper-proof. Restricting the gateway to a configured camera address reduces exposure, but does not provide cryptographic authentication. This setup is not intended for public release or untrusted networks.

The First Storage Lesson

One of the most revealing failures was a simple message: "No space left on device."

The initial upload implementation copied the selected JPEG into the application's internal cache to determine its size. That is convenient on a modern computer, but it is a poor assumption on an older camera with limited internal storage, even when its memory card has plenty of room.

The replacement does not create a photo-sized temporary file. It opens the selected JPEG through Sony's media provider, measures the stream with a small buffer, then reopens the same image and streams it to the gateway with a known Content-Length.

That costs a second read from the memory card, but avoids needing a second copy of the photograph in internal storage or RAM. Cleanup is deliberately narrow: only temporary upload files created by earlier versions are eligible for removal from the app's private cache. Originals on the memory card are not changed or deleted.

Wi-Fi Is a State Machine

Enabling Wi-Fi is not the same as having a usable connection. The first version started network requests too soon after enabling the radio. It now waits for a connected Wi-Fi network and an assigned address.

Transfers exposed another weakness. A single disconnected-state snapshot could cancel an upload, even though a brief state transition does not always mean that the connection has been lost permanently. The app now rechecks connection state and applies a short grace period before treating the loss as sustained.

The transfer also holds temporary Wi-Fi and CPU wake locks, keeps the display on and uses Sony's application power-management mechanism to prevent auto-power-off. Those resources are released when the attempt finishes, fails, is cancelled or the app pauses.

There are still bounded timeouts. The aim is not to make a broken connection look alive forever, or to keep uploading after someone leaves the app.

When a Stream Error Is Really a Permission Error

An upload stopping near the beginning with "unexpected end of stream" initially looked like another transport problem. Checking both sides revealed a more specific cause.

The gateway was treating a missing profile field as proof that the signed-in account was not staff. The session had the admin scope, and a read-only request to the actual admin Files endpoint succeeded, but the local check still rejected it.

The correction was not to remove authorisation. It was to stop confusing an absent optional field with an explicit denial, require the admin scope, and verify access against the real admin endpoint.

The camera now performs a bodyless upload preflight before writing the JPEG. A permission failure can therefore arrive as a complete, useful response instead of the gateway closing the connection while the old HTTP client is still sending data. The upload itself repeats the checks; preflight is not a bypass.

Recovery Without Silent Repetition

A failed connection does not necessarily mean that nothing was saved. If the server stores a file but the response never reaches the camera, automatically retrying could create another copy.

For now, the app does not automatically replay an interrupted upload. It preserves explicit selection and confirmation, offers cancellation, and asks the user to inspect public files before trying again when the result is uncertain.

The photo picker also remains accessible when gateway sign-in fails. Local access to the memory card should not disappear simply because an unrelated account request has failed. Browsing locally and being authorised to publish are separate capabilities.

Where the Experiment Stands

The camera application has been built and installed on the HX60. Automated tests cover selection identity, byte preservation, size limits, cancellation, connection transitions, permission checks and rejection before an upload body is sent. Live read-only checks have verified authenticated access to admin public Files and upload-preflight readiness.

The useful lesson so far is that supporting old hardware is not just a matter of finding an old compiler. It means reconsidering where work happens, what can fit in storage, how network state is interpreted, and what an error actually tells the person holding the device.

The modern SDK belongs on the machine that can run it comfortably. The camera should do the part it is well suited to: let someone choose a photograph and decide what to do with it.

Thanks to the contributors behind OpenMemories, PMCADemo and Sony-PMCA-RE for making this kind of exploration possible. This is an independent experiment, not an official Sony application or a general compatibility claim for other camera models.