Jártál már így? A szoftver amit fejlesztettél, nálad simán megy, a felhasználónál viszont úgy borul, hogy öröm nézni.

Hát az állítólag megy a fejlesztőnél és a tényleg megy a fejlesztőnél között is van némi különbség :)

--
Desktop: Windows10 | Server: CentOS

Javaslom a windows minidump fgv használatát: crash esetén még ki tudja menteni a dmp fájlt, abból megnézhető a crash helye, változók, threadek stb

a lokalizált felhasználónevekkel rendszeresen szívóznak még a nagyok is... anno, naiv ifjú koromban még ékezetes windows nevem volt. Aztán többek között a real rhapsody és a win-es safari böngészőből is jött ki olyan verzió, ami nem tudott vele mit kezdeni. Azóta inkább nem használok ékezetet, mert szinte biztos, hogy valahol átcsúszik a teszteken valami hiba valamelyik programnál és szívás a vége :)

Mindig kiderült = mindig kimagyráztátok.

Mikor supportos voltam, rendszeresen kaptam a fejlesztőtől, hogy nála működik, nincs hiba.
Aztán kiderült, hogy a fejlesztőkörnyezete valami lib/dll ből más verziót használ, mint az ügyfél egyszerű vindóza. Csak a szükséges dll-eket, és azok verzióit a fejlesztés vezető nem kívánta dokumentálni, mondván hogy neki fogalma sincs, meg ideje se, derítse ki a support.
Szerencsére már nem dolgozom ott, mert ez a legkisebb baj volt a hellyel. :)

---
"A megoldásra kell koncentrálni nem a problémára."

hehe... huawei telefonoknál több különböző alkalmazás kapcsán futottam már rá problémára. Jellemzően nem azzal az android verzióval van baj, amivel a gyártó kihozza, hanem ha egy főverzió frissítést adnak ki rá.

Volt ilyesmim, ahogy te is írod. A play storeból való telepítés indításakor a készülék újraindult. Egyik fapadosabb huawei/honor és még 2-3 durván noname készülék. Semmi log, semmi használható adat, néhány felhasználó készített videót a történésről, hogy lássuk egyáltalán mit tapasztalnak valójában. A play store értékelések kapcsán és a supportot hívó ügyfelektől tudtuk meg, hogy történik ilyen.
Berendelt a management több gagyi készüléket és az egyik fajta fapados huawei esetén sikerült reprodukálni. De csak release apk-val, a debug kulccsal aláírt apk esetén nem történt meg. Másik build, ugyanúgy publikálva meg működött. Valószínűleg valami bug volt az anrdoid rendszerben, amit használtak azok a készülékek. Pontosan azonos verziószámúak voltak. Arra tippelek, hogy a huawei lehet némelyik fapados készülék szoftveres supportját valami csunka alvállalkozónak adják ki és azt felhasználják többféle márkanévhez, más ügyfelekhez is.

Másik eset, régebben, talán 5-ről 6-ra frissítéskor az ugyanolyan alaprendszert használó készülékekre nem működött a megvásárolt tartalom letöltése. A különböző fázisokból gyűjtött atinternet statisztikából szépen látszott, hogy melyik készülékeket érintette főleg és hogy a modell numberben ugyanaz a postfix van, ugyanarrazt a buildet vehetik alapul hozzá. Később ritkul a probléma, valsz adtak ki updateket és azok valamelyest orvosolhatták. Mivel nem volt olyan szoftverezésű készülékünk (más ország szolgáltatóinál voltak), így nem tudtuk megfejteni.

Még régebbi eset: Az ügyfél folyton tajtékzott, hogy egyik készülékükkel sem megy jól az alkalmazás, széthullik a felület. Kiderült, hogy az egész telefon flottájuk sony ericsson xperia, amelyket a kiadáskori 2.3-ról 4.0.4-re frissítettek. Sikerült egy próbára egy kollégától szerezni egy minit, azon reprodukálható volt és meg sikerült fejteni az okát. Azért apróról egy összetört készüléket is szereztem tesztelésre, egy xperia neo mt15i-t. Az volt a probléma oka, hogy a nyomorult gyártó nem a végleges 4.0.4-es rendszerből készítette a rendszer buildjét, hanem egy javítatlan bugokat tartalmazó bétából. A setterek csak legelső értékadáskor működtek a gui elemeknél, így az ügyfél által kért animációk beállítása nem ment megfelelően. A workaround az lett, hogy minden gui elem módosításakor egy új pélrányt kellett létrehozni, átmásolni a paramétereit a réginek, s kicserélni... ahelyett, hogy setterrel egyszerűen lett volna átállítva.

Az is szokásos történet, hogy fejlesztői verziót apk-ból telepítve sokszor nem enged az ügyfél telefonjára telepíteni a rendszer. Mindenféle workaroundokról regélnek a neten, google driveről próbálni telepíteni meg hasonlók. Teljesen random fordult elő hogy melyik készülékeknél tiltakozott. Természetesen engedélyezve volt a harmadik féltől való telepítés. Viszont ez nem szokott probléma lenni play storeból telepítéskor.

Persze volt olyan misztikus hiba is, amiről később kiderítettem, hogy én voltam idióta és emellett a release folyamatunk hibás volt, mert nem bukott ki. Így egyszer kikerül egy olyan app verzió, ami bizonyos oldalára lépve kresselt - mint utóbb kiderült a bináris méretét csökkentő mókából kimaradt egy kivétel bejegyzés annál a változatnál. És nem pontosan azt a binárist teszteltük, hanem az elvileg azonos, de más kulccsal aláírtat... s persze így már nem is volt azonos. Release után play storeból telepítéssel kipróbálva rögtön észrevettem, de persze akkor akart az új kolléga nagyon alapos lenni... a személyi változások miatt nem tudta, hogy neki is tesztelnie kellett volna a zöld jelzés előtt. És a másik csapatnak pont akkor jött egy hetes nemzeti ünnepe... akiknek csupán az az egyetlen feladata volt, hogy feltegyék a storeba. Így egy hét után sikerült valakit keríteni, aki hozzáfért a kulcsokhoz, s ki tudta tenni a javított binárist...... brrr

erre bug report is van, úgy látom insteller körül volt bug
https://bugs.python.org/issue25450

+1
____________________
echo crash > /dev/kmem

A kress reprodukálós témában voltak szintén jópofa esetek. Android appban remekül lehet backend kommunikációval összekötött gui művelettel ilyeneket csinálni. Minden jó, míg reszponzív a net. Ha lassú, akkor kiderül, hogy az asszinkron hívások kezelése, activity lifecycle kezelése hátba lett szúrva, mielőtt lábon lett lőve :D

Temékfejlesztéskor igencsak termékeny volt, amikor a fejlesztők valódi, utcán mozgós próbahasználatot toltak, s sorban buktak ki azok a dolgok, amik az irodában ülve nem. A legalaposabb tesztelés, ha használják valós körülmények közt is az alkalmazást/szolgáltatást.