Tévhitek és Valóság #14: A MyDroneSpace (MDS) mély rejtelmei – Az Android kíméletlen csapdái vs. a WEB API stabilitása
Utolsó látogatás dátuma: 2026.08.07.
⚡ Utolsó módosítás és frissítés: 2026.08.07. 17:00
Tévhitek és Valóság #14: A MyDroneSpace (MDS) mély rejtelmei – Az Android kíméletlen csapdái vs. a WEB API stabilitása
Üdvözlök minden drónpilótát az exkluzív UAS parancsnoki hídon! A digitális sötétszoba után most visszatérünk a hivatalos, kötelező repülésbejelentés rögös talajára. A hazai közösségben a mai napig tartja magát az a naiv tévhit, hogy az állami MyDroneSpace (MDS) mobilalkalmazás az egyetlen és kizárólagos eszközünk a légtér használatára. Amikor a szoftver hibaüzenetet dob vagy lefagy, a pilóták tehetetlenül állnak a réten. Ez óriási tévedés! Ebben a kötetben rendszerszervezői és hálózati szinten világítjuk át az MDS hátterét, bemutatjuk az Androidos memóriakezelés kíméletlen csapdáit, és lerántjuk a leplet a 100%-os mérnöki megváltást jelentő közvetlen böngészős WEB API felületről.
Ha iOs telefont használsz, akkor az Androidos őrületet ne is olvasd végig, maga a borzalom.
Ugye az világosan megvan, hogy a drón pilótának minden repülési helyszínen a felszállás előtt az MDS-be be kell jelölnie a tervezett repülés adatsorát, ha ezt nem teszi meg, akkor jogszabályt sért, ami egy ellenőrzés során, akár büntetést is vonhat maga után.
Viszont a pilótának fel kell készülnie arra is, ha az adott helyszínen nincs mobil Internetes elérhetőség, nos akkor oda hiába ment el, ott szabályokat betartva nem reptethet!
Tartalomjegyzék
- 1. Miért omlik össze és fagy le az Androidos mobilalkalmazás a kritikus pillanatokban, és hogyan zár le a háttérben a memóriakezelés?
- 2. Miért jelent 100%-os mérnöki megváltást a közvetlen böngészős WEB API felület használata?
- 3. Gyakorlati hálózati protokoll: Így biztosítsd a repülésedet, ha az állami szerverek elérhetetlenné válnak
1. Miért omlik össze és fagy le az Androidos mobilalkalmazás a kritikus pillanatokban, és hogyan zár le a háttérben a memóriakezelés?
A leggyakoribb tévhit a MyDroneSpace alkalmazással kapcsolatban, hogy ha a telefonunkon látszólag elindult az app, akkor a háttérben a repülésregisztrációnk is folyamatosan aktív és biztonságban van. A valóság az, hogy az Android operációs rendszer belső, agresszív memóriakezelő architektúrája (Low Memory Killer) a drónozás során kíméletlenül a pilóta ellen dolgozik. Amikor elindítod az MDS appot, majd átváltasz a DJI Fly applikációra, hogy lásd a Mini 4 Pro vagy DJI Neo élőképét, az MDS kénytelen a háttérbe vonulni. Mivel a DJI Fly és a valós idejű 4K videófolyam dekódolása hatalmas erőforrást emészt fel, az Android rendszer a stabil működés érdekében csendben lelövi a háttérbe kényszerített MDS GPS-követését és hálózati szinkronizációját, ha a belső kód nincs tökéletesen optimalizálva a folyamatos ébrentartásra (Foreground Service).
A közösségi visszajelzések és a gyakorlati tesztek azonban egy ennél is mélyebb szoftvertervezési hibára világítottak rá. Sokáig élt a tévhit, hogy az összeomlásokért kizárólag a gyártók egyedi szoftveres keretrendszerei a felelősek. A valóság cáfolja ezt: még a Google saját, gyári, vegytiszta Androidot futtató **Google Pixel** készülékein is rendszeresen „behal” és összeomlik az MDS app. A gyorsítótár (cache) törlése vagy az újratelepítés is csak néhány indításig segít. Ez kőkemény mérnöki bizonyíték arra, hogy az alkalmazás belső kódja nincs felkészítve a szabványos Androidos memóriakezelési életciklusok lekezelésére. Amíg más, rendkívül speciális és ritka appok zökkenőmentesen futnak éjjel-nappal ugyanazon a tiszta Android rendszeren, addig az MDS elvérzik a háttérben.
A helyzetet tovább fokozza a kijelző- és felületkezelés (UI) teljes hiánya, amely különösen a lebegő zónák, valamint a felső és alsó vezérlősávok renderelésénél kritikus. Egy modern, Androidot emuláló, HyperOS-t futtató **Xiaomi 14 Leica** csúcskészüléken az alapbeállításokkal az MDS gyakorlatilag használhatatlan. A szoftver nem képes lekezelni az operációs rendszer navigációs gombjait. A pilótáknak sokszor a telefon „Fejlesztői módjába” (Developer Options) kell belépniük, és átállítaniuk a rendszert legyintéses képernyővezérlésre, hogy az alsó három fix navigációs gomb eltűnésével az MDS felülete egyáltalán kezelhetővé váljon – de még ez a trükk is csak néhány percnyi „kínlódásos élvezetet” nyújt az újabb fagyás előtt. Ezzel szemben az Apple zárt ökoszisztémájában, ahol a hardver és az operációs rendszer fejlesztője ugyanaz a cég, az MDS (akár egy régebbi iPhone 12 Mini-n, a legfrissebb iOS verzión futtatva) stabilan, hiba és korlátozás nélkül teszi a dolgát. Ez a töredezett, optimalizálatlan kódkörnyezet az Androidos fronton állandó kockázatot jelent a réten, és ez az a pont, ahol a mobilapp elvérzik a böngészős megoldással szemben.
Most próbaként megpróbáltam elindítani az MDS-t, nos most éppen se az Androidon, se az iOs-en nem működik, tehát most a Hungaró Controlnál van a hiba, na, de éles helyzetben kint a réten, ezt ez azt eredményezné, hogy nincs repülés!
 |
| A WEB API |
2. Miért jelent 100%-os mérnöki megváltást a közvetlen böngészős WEB API felület használata?
Sok pilóta szentül hiszi, hogy az állami drónapplikáció szervereit kizárólag a hivatalos mobilalkalmazáson keresztül lehet elérni. Ez egy óriási tévhit. A háttérben futó informatikai rendszer valójában egy nyílt, szabványos hálózati felületen (úgynevezett WEB API-n) keresztül kommunikál, amelyhez bármilyen modern webböngészőből közvetlenül hozzá lehet férni. Amikor elhagyjuk az instabil mobilappot, és helyette közvetlenül a böngészőből lépünk be a HungaroControl hivatalos felületére, egy csapásra megszabadulunk az összes telefonos szoftverkonfliktustól.
A közvetlen WEB API használata azért jelent 100%-os mérnöki megváltást, mert a böngészőből küldött adatcsomagok közvetlenül az állami szerver adatbázisába futnak be, megkerülve a telefon instabil memóriakezelését. Nem kell aggódni amiatt, hogy a DJI Fly applikáció miatt a háttérben bezáródik a folyamat. Miután a böngészős felületen rögzítetted a repülési zónádat és az időtartamot, a rendszer a szerver oldalon fixálja azt. Ez a mozgóképes adatátvitel nemcsak golyóálló stabilitást biztosít, hanem drasztikusan csökkenti a telefon akkumulátorának terhelését és melegedését is a réten, ami a forró nyári napokon kritikus fontosságú a repülésbiztonság szempontjából.
3. Gyakorlati hálózati protokoll: Így biztosítsd a repülésedet, ha az állami szerverek elérhetetlenné válnak
A legveszélyesebb jogi és technikai tévhit az, hogy ha a MyDroneSpace központi szervere vagy hálózata leáll, akkor a pilóta mentesül a felelősség alól, és bejelentés nélkül is szabadon felszállhat. Ez nem igaz: a légtér jogszerű használatáért minden pillanatban a parancsnokló pilóta felel. Viszont a pilótának kőkeményen fel kell készülnie arra is, ha az adott helyszínen egyáltalán nincs mobilinternetes elérhetőség. Nos, ha a réten szembesülsz a térerő hiányával, akkor oda hiába mentél el: a szabályokat betartva ott és akkor nem reptethetsz! A törvény nem ismeri a „nincs netem” kifogást.
A hálózati és földrajzi csapdák elkerülésére létezik egy teljesen legális és biztonságos mérnöki protokoll: az előre tervezés. Óriási tévhit, hogy az MDS-t csak a repülés helyszínén lehet elindítani. Az alkalmazást vagy a közvetlen WEB API felületet otthon, a stabil otthoni Wi-Fi hálózatra csatlakozva, akár napokkal előre is használhatod! Pontosan bejelölheted a tervezett repülési zónádat és a várható időtartamot. Ha a helyszínen végül mégis elmaradna a repülés – rossz idő vagy egyéb technikai okok miatt –, a rögzített zónát utólag, otthonról is bármikor egyszerűen el tudod törölni az MDS-ben. Ezzel a megelőző lépéssel teljesen függetlenítheted magad a helyszíni térerő-ingadozásoktól.
Gyakorlati, élő példa: e cikk írásának szent pillanatában, 2026. augusztus 7-én délután a teljes állami rendszer megbénult – az Androidos és iOS alkalmazások „nincs kapcsolat” hibával elvéreztek, a WEB API és a HC kapcsolódó weboldalai pedig teljesen elérhetetlenné váltak. Ez a kíméletlen valóság: ilyenkor a hatályos szabályok szerint a felszállás tilos! Az egyetlen legális pajzsunk az azonnali képernyőmentés rögzítése, és a HungaroControl közvetlen értesítése.
Mivel a leállás során a szoftverekből a kontaktadatok is eltűnnek, íme a DroneJ blog életmentő listája, amit minden pilótának kötelező elmentenie a telefonjába a réten való katasztrófák esetére: A repüléstájékoztató szolgálat (FIC) közvetlen száma a +36 1 293 4122, a HungaroControl központi operatív száma a +36 1 293 4444, a hivatalos írásos bizonyítékot (a screenshotot) pedig a mydronespace@hungarocontrol.hu címre kell azonnal megküldeni. Soha ne hagyatkozzunk a vakszerencsére: a digitális lábnyom és a pontos dokumentáció az egyetlen pajzsunk a hatósági szankciókkal szemben!
Ha szeretnél részletesebben tájékozódni a drón-os reptetés jogi háttérről, olvasd el a blogomon található Szabályok és Bevezetés összefoglalót, vagy böngészd át a leggyakoribb kérdésekre adott válaszaimat a drónos GYIK oldalon. Találkozunk a réten!
 |
| FIGYELMEDBE ajánlom az Újdonságok bejegyzésemet, ahol a legújabb, letisztított cikksorozatom tartalomjegyzékét láthatod, gyors LINK elérésekkel! Ha szeretnél egy Országos érdekvédelmi csoporthoz tartozni keresd a DOE (Drónpilóták Országos Egyesülete) oldalát és jelentkezz egyesületünkhöz! |
Megjegyzések
Megjegyzés küldése