Pi SD Writer (Android): write Raspberry Pi images to microSD from your phone (USB OTG, cloud/local sources, chunked streaming)

Pi SD Writer (Android): write Raspberry Pi images to microSD from your phone (USB OTG, cloud/local sources, chunked streaming)

![img](vpz1txwa1kah1)

Hi folks, I’ve been building **Pi SD Writer**, an Android app focused on one workflow: preparing and flashing SD images for Raspberry Pi/SBC devices directly from a smartphone.

The goal is to remove the laptop/desktop requirement and keep the process reliable even on mobile hardware.

What it does

* Select image source from: * Google Drive * Local file storage * GitLab Releases (Premium) * GitHub Releases (Premium) * Raspberry OS catalog * Supports common formats: * `.img` * `.img.gz` * `.img.xz` * `.iso` * `.zip` * Writes directly to microSD over **USB OTG**. * Uses **streaming/chunked transfer** to reduce peak RAM usage during write operations. * Includes guided 3-step flow: * Source selection * USB/device validation * Write progress + live log output

Technical approach (high level)

* Cloud/release sources are validated before selection so users get a list of valid image assets first. * Write path is designed around block/chunk streaming rather than loading full images in memory. * UI exposes progress state, ETA area, and live diagnostic logs for visibility during long writes. * Connectivity-sensitive sources (Drive/GitLab/GitHub/Raspberry OS) are disabled when offline. * Google auth is used for account/session features and plan management. * Base plan has a monthly write quota; Premium unlocks unlimited writes and extra repository integrations.

Why I built it

The existing SD flashing flow is still desktop-first. I wanted a phone-first workflow that is practical when traveling or when you only have Android + OTG adapter + SD reader.

Known constraints

* OTG hardware quality matters (reader/cable stability can affect results). * For network-backed sources, internet connectivity must remain stable during transfer. * UX and recovery paths for interrupted writes are still being improved.

Feedback I’m looking for

  1. Which source integration matters most to you (Drive/local/GitLab/GitHub/Raspberry OS)?
  2. Would you prefer stricter pre-write validation (slower, safer) or faster start?
  3. What diagnostics are most useful in the live log when a write fails?
  4. Any must-have feature before wider release?

[https://play.google.com/store/apps/details?id=com.magix.sdcardimager&hl=en\](https://play.google.com/store/apps/details?id=com.magix.sdcardimager&hl=en)
Thank you!

u/xpistarlink — 6 days ago
▲ 23 r/Android+1 crossposts

Pi SD Writer (Android): write Raspberry Pi images to microSD from your phone (USB OTG, cloud/local sources, chunked streaming)

https://preview.redd.it/vpz1txwa1kah1.png?width=1536&format=png&auto=webp&s=f52f5075d2c090cbd78ea5cbbe278bdea33d60f3

Hi folks, I’ve been building Pi SD Writer, an Android app focused on one workflow: preparing and flashing SD images for Raspberry Pi/SBC devices directly from a smartphone.

The goal is to remove the laptop/desktop requirement and keep the process reliable even on mobile hardware.

What it does

  • Select image source from:
    • Google Drive
    • Local file storage
    • GitLab Releases (Premium)
    • GitHub Releases (Premium)
    • Raspberry OS catalog
  • Supports common formats:
    • .img
    • .img.gz
    • .img.xz
    • .iso
    • .zip
  • Writes directly to microSD over USB OTG.
  • Uses streaming/chunked transfer to reduce peak RAM usage during write operations.
  • Includes guided 3-step flow:
    • Source selection
    • USB/device validation
    • Write progress + live log output

Technical approach (high level)

  • Cloud/release sources are validated before selection so users get a list of valid image assets first.
  • Write path is designed around block/chunk streaming rather than loading full images in memory.
  • UI exposes progress state, ETA area, and live diagnostic logs for visibility during long writes.
  • Connectivity-sensitive sources (Drive/GitLab/GitHub/Raspberry OS) are disabled when offline.
  • Google auth is used for account/session features and plan management.
  • Base plan has a monthly write quota; Premium unlocks unlimited writes and extra repository integrations.

Why I built it

The existing SD flashing flow is still desktop-first. I wanted a phone-first workflow that is practical when traveling or when you only have Android + OTG adapter + SD reader.

Known constraints

  • OTG hardware quality matters (reader/cable stability can affect results).
  • For network-backed sources, internet connectivity must remain stable during transfer.
  • UX and recovery paths for interrupted writes are still being improved.

Feedback I’m looking for

  1. Which source integration matters most to you (Drive/local/GitLab/GitHub/Raspberry OS)?
  2. Would you prefer stricter pre-write validation (slower, safer) or faster start?
  3. What diagnostics are most useful in the live log when a write fails?
  4. Any must-have feature before wider release?

https://play.google.com/store/apps/details?id=com.magix.sdcardimager

Thank you!

reddit.com
u/xpistarlink — 1 day ago
▲ 1 r/VPN

Android app restoring L2TP/IPsec VPN support (beta access available)

![img](mlbqvutg3x5h1)

Hi everyone,

I recently worked on an Android application that restores support for L2TP/IPsec VPN connections on modern Android versions.

The project started because our company still relies on L2TP/IPsec in production environments, and we ran into the limitations introduced by newer Android releases, where native support has been reduced or removed despite many organizations continuing to maintain legacy VPN infrastructures.

The goal was to provide a way to keep existing L2TP/IPsec deployments usable on current Android devices without requiring changes to the VPN server infrastructure.

I'm interested in hearing from other IT administrators, network engineers, or organizations that still use L2TP/IPsec today.

  • Are you still running L2TP/IPsec in production?
  • How are you handling Android compatibility issues?
  • Have you migrated to another protocol, or are you maintaining legacy deployments?

I'm also looking for feedback on different deployment scenarios and edge cases that may not have been considered during development.

Happy to discuss technical details, implementation choices, and real-world use cases.

reddit.com
u/xpistarlink — 28 days ago