tajniak81andClaude Opus 4.8
33595c99e8
The fleet lived as a tab inside the Logbook, which buried it, and every
drone had to be typed in by hand — model, serial and firmware copied off
an airframe the app was already talking to.
Promote it to its own nav section above Logbook, and let a connecting
drone register itself. The Fly App already forwarded model, serial and
firmware upstream; the hub was keeping only the model. It now carries the
identity through to DeviceState, and the Web App offers it to a new
POST /api/drones/auto, which upserts keyed by serial. The auto path only
writes what the aircraft is authoritative about (model, both firmware
versions) and never touches what the pilot curates.
Serial and the firmware versions resolve on their own schedules after
connect — the serial in seconds, the aircraft firmware sometimes a minute
later — so nothing along the path treats an absent value as a cleared one,
and a later event filling firmware in still reaches the server. The auto
call rides every telemetry frame, so the client remembers the identity
tuple it last sent and only a change goes out; a 4xx is the server's
settled answer and is not retried, or one drone connected for an hour
would mean one request per frame for an hour.
New fields on drones: firmware, controller_firmware, and registration for
the FAA/CAA aircraft number — distinct from operator_number, which stays
the EU operator ID. Controller firmware is the remote controller's own
version, read from its component; the flight controller's version is a
different quantity and stays off this field (see 002e484). name becomes
optional and is now the pilot's custom name: auto-added drones arrive
unnamed, so the API serves a computed displayName (name, else model +
serial) for the fleet table, the flight picker and the CSV export. A
unique index on serial is what keeps the find-then-create path from
forking a drone's history across two records.
The schema is applied to the remote PocketBase; the migration is here for
fresh deployments, which the remote does not read.
Verified against a simulated device over the real socket with identity
resolving late: one record from four events, both firmware versions
filled, curated fields intact across re-registration, and a drone deleted
while connected coming back on the next frame.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
DJI MSDK Sample (Flutter)
A sample app demonstrating how to drive the DJI Mobile SDK V4 from Flutter.
DJI does not ship an official Flutter SDK — the Mobile SDK is a native Android/iOS library. This project therefore puts a Flutter UI on top of a thin native Android (Kotlin) bridge that talks to the DJI MSDK over platform channels. It covers the core "sample app" flow: SDK registration, product connection, and live telemetry (battery, GPS, flight status).
Android only. The DJI MSDK V4 native libraries here are wired up for Android. iOS would need a parallel Swift/Obj-C bridge (and a Mac to build).
Architecture
┌────────────────────────┐ platform channels ┌─────────────────────────┐
│ Flutter (Dart) │ dji_msdk/methods (MethodChannel)│ Android (Kotlin) │
│ lib/main.dart │ ───────────────────────────────▶ │ DjiSdkBridge.kt │
│ lib/dji_service.dart │ dji_msdk/events (EventChannel) │ └─ DJI Mobile SDK V4 │
│ │ ◀─────────────────────────────── │ DjiApplication.kt │
└────────────────────────┘ └─────────────────────────┘
| File | Responsibility |
|---|---|
lib/dji_service.dart |
Dart wrapper over the method/event channels |
lib/main.dart |
UI: registration / connection / telemetry cards |
android/app/.../DjiApplication.kt |
Installs the Secneo Helper (required by MSDK V4) |
android/app/.../MainActivity.kt |
Hosts the bridge, requests runtime permissions |
android/app/.../DjiSdkBridge.kt |
Registration, product lifecycle, telemetry callbacks |
android/app/build.gradle |
DJI deps, native-lib packaging, multidex, ABI filters |
Prerequisites
- Flutter (stable) and Android SDK with a connected Android device (the DJI SDK does not work on emulators).
- A DJI drone + remote controller supported by MSDK V4 (Phantom 4, Mavic 2 / Air / Mini 1, Spark, Inspire 2, etc.). The RC connects to the phone over USB.
- A DJI App Key (see below).
Set your DJI App Key
SDK registration will fail without a valid App Key bound to this app's application id.
-
Sign in at https://developer.dji.com/user/apps/ and create a new app.
- Package name must be exactly:
com.dji.flutter.dji_msdk_sample - SDK: Mobile SDK
- Package name must be exactly:
-
Copy the generated App Key.
-
Paste it into
android/gradle.properties:DJI_API_KEY=your_real_app_key_hereThe key is injected into
AndroidManifest.xmlat build time via amanifestPlaceholder(com.dji.sdk.API_KEY).
Run
flutter pub get
flutter run # device must be plugged in
# or just build the APK:
flutter build apk --debug
Using the app
- Launch it and grant the location / phone / mic permissions it requests.
- Tap Register app — needs internet on first run; status turns green on success.
- Connect the drone's remote controller to the phone over USB and power on the aircraft. The app auto-starts a connection on successful registration; you can also tap Connect to product.
- Once an aircraft connects, the Telemetry card streams battery %, GPS satellite count, flight mode, altitude, and position.
Notes & gotchas
- MSDK V4 version is pinned to
4.18(com.dji:dji-sdk/dji-sdk-provided). android.enableJetifier=trueis required — the SDK still uses legacy support libraries.- The native
.sofiles are kept unstripped and de-duplicated via thepackaging { }block inandroid/app/build.gradle; onlyarmeabi-v7aandarm64-v8aABIs are bundled (the only ABIs DJI provides). - This sample uses the core SDK, not the DJI UX SDK (its native UI widgets don't embed cleanly in Flutter).