tajniak81andClaude Opus 4.8
183c83c177
getSerialNumber() is a BaseComponent method, so every component answers for
itself — and the bridge reads it off the flight controller. A Mavic Pro reports
08RDE1J00103H1 (what DJI Go labels "Flight Controller SN") where the airframe
sticker, and the registration, say 08QDE3H012032E. We were publishing the former
as the drone's serial, onto records that exist to satisfy BEK 1649 §5.
Same trap as 002e484, where a component's own firmware stood in for the
aircraft's, but with no correct source to switch to: MSDK v4 exposes no
aircraft-level serial at all — BaseProduct offers only the model and the
firmware package version — so the registered serial can only be typed by hand.
So split the two rather than pick one:
serial the airframe's, hand-entered, and the only one that
reaches the logbook and the CSV export
flight_controller_serial what the aircraft reports; auto-filled on connect,
and what POST /api/drones/auto now upserts on
Keying auto-add on the flight controller's serial keeps the fleet recognising a
connected drone without typing — it is stable per airframe — while leaving the
compliance record's serial to the pilot. A flight controller swapped in a repair
now costs a duplicate fleet entry to merge, where before it would have quietly
rewritten what the logbook claimed the drone was.
Note droneInput.payload() is a whole-record write, so any UI editing a drone must
round-trip flightControllerSerial; blanking it forks the drone into a duplicate
on its next connect. Drones.vue carries it through the edit form for that reason.
The migration copies existing serials into flight_controller_serial rather than
moving them: every current value came from auto-add and is therefore a flight
controller's, but a pilot may since have corrected one by hand and this cannot
tell them apart. Copying keeps auto-add matching the airframes it matched before.
Applied to the remote PocketBase, where drones held no records, so the backfill
was a no-op there.
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).