Az átlagos Android-felhasználók valószínűleg már régen nem törődnek az Android "töredezettségi problémájával". De a probléma továbbra is kínozza a fejlesztőket.
A töredezettség szó szerint vitatott probléma az Androidban a mobil operációs rendszer bejelentése óta.
Amellett, hogy a trollok bújója az online láng-háborúkban, a széttagoltságból fakadó sokszínűség ma már nagyrészt egy nettó pozitív a fogyasztók számára Android készülékek közül. Hiszen akkora szabadságot kapunk a kívánt szoftverrel rendelkező készülék kiválasztásában, hogy az átlagfogyasztót nehéz törődni a töredezettséggel. Az Android-eszközök hihetetlen sokféleségének megjelenítése gyönyörű mozaikot készít az Android változatos ábrázolásáról.
De a hardver és a szoftver töredezettsége nem tesz boldog szoftverfejlesztőt. Sőt, éppen ellenkezőleg. Egy alkalmazás fejlesztése sok különböző hardver- és szoftverkonfiguráción komoly kellemetlenségnek bizonyulhat a hibakeresés során. Az OEM-ek jelentős vagy finom változtatásokat hajthatnak végre, amelyeket figyelembe kell venni egy alkalmazás fejlesztése során, de valójában nincs egyszerű módja annak, hogy az egyes fejlesztők biztosítsák, hogy alkalmazásaik általánosan működjenek. Míg az átlagfogyasztó már rég megfeledkezett a töredezettségről szóló vitáról, a probléma még mindig kísérteti az Androidot alkalmazásfejlesztők, és látszólag nincs mit tenni ellene, csak felszívni és kezelni a hibákat megjelenik.
A töredezettség sajnálatos állapota
Különösen az egyik OEM-gyártó kap nagy gyűlöletet az alkalmazás fejlesztése során okozott fejfájás miatt – a Samsung. A fejlesztők már évek óta üvöltöznek a Samsungról, és néhányan még olyan megrázó darabokat is írnak, mint "Van egy különleges hely a Samsung számára az Android poklában", amely egy különösen frusztráló hibát ír le, amely ebből ered Samsung eszközök és a támogató appcompat könyvtár. Külön szeretném felhívni a figyelmet egy bekezdésre Ambri úr kiabálásából, amely kiválóan körvonalazza, hogy a fejlesztők miért törődnek még mindig a töredezettséggel:
Ha Ön Android fejlesztő, valószínűleg határtalan a gyűlölet a Samsung készülékek iránt. Több, mint egy átlagos felhasználó, akinek a Samsung a szinonimája buta Touchwiz és túlzott bloatware, megveted a Samsungot, mert nincs más választásod. A Samsung miatt hatalmas piaci részesedés, egyszerűen nem dönthet úgy, hogy nem támogatja a Samsung készülékeket. És ez az, ami a legjobban fáj; az a tény, hogy ezt a választást elveszik tőled!
Ez sem ricsaj az Android régebbi fennállásának éveiről – ez a bejegyzés tavaly december közepén jelent meg. Előre szólok, és kijelentem, hogy nem vagyok biztos abban, hogy ezt a problémát hivatalosan már megoldották-e, azonban Mr. Ambri a bejegyzésében javított mindenki számára, aki a Google-keresőn keresztül rábukkan a szóváltására bogár. Nincs más dolgod, mint használni ProGuard a következő egysoros kóddal:
# Samsung ruining all nice things-keep class !android.support.v7.view.menu.**, !android.support.design.internal.NavigationMenu, !android.support.design.internal.NavigationMenuPresenter, !android.support.design.internal.NavigationSubMenu, android.support.** {*;}Ez nem is olyan rossz, ugye? A probléma azonban az, hogy ezt a javítást kivonták a Stack Overflow-ból. Félreértés ne essék, a Stack Overflow egy nagyszerű webhely. De ez nem igazán ideális forrás az alkalmazások javításainak felfedezéséhez. Ha talál valamit a Stack Overflow-n, gyakran bele kell búvárkodni a linkekbe, miután sok próba-hiba Google-keresést végez. Néha még azt is tapasztalhatja, hogy egy másik felhasználó megemlíti ugyanazt a hibát, amely Önnél is előfordult, de javítás nélkül. Vagy még frusztrálóbbak azok az esetek, amikor találsz egy szálat, ahol az eredeti poszter azt állította találtak egy javítást, de már rég felhagytak a témakörrel anélkül, hogy utasítottak volna másokat a probléma kijavítására probléma.
Példa a finom töredezettség problémájára
Jómagam nem vagyok fejlesztő, de eléggé ismerem az Android képességeit a Taskerben való évekig tartó trükközés után, hogy elkezdtem álprogramozni a saját megoldásaimat azokra a problémákra, amelyekkel szembesültem. És ha nem tudok rájönni valamire, akkor a Google-on keresem, mint mindenki más. Amíg az előző cikkemet írtam róla ásni a telefon Beállítások alkalmazásában rejtett tevékenységeket, egy meglehetősen furcsa hibára bukkantam, amit nem tudtam megmagyarázni. A Huawei készülékekre jellemző hiba.
Valahányszor megpróbáltam elindítani bizonyos tevékenységeket (például az alkalmazáshasználati statisztikákat tartalmazó „Tesztelés” menüt) a Beállítások alkalmazásban, mindig engedélyhiba jelent meg. Különösen a tevékenység elindításához használt alkalmazásnak hiányzott az engedélye huawei.android.permission. HW_SIGNATURE_OR_SYSTEM. Egyetlen másik tesztelt eszköz sem igényelt egyedi engedélyeket a beállítások elindításához, csak a Huawei Android-verzióját (EMUI) futtató telefonok. Az elemzés com.android.settings felfedte, hogy a Beállítások alkalmazáson belül bizonyos tevékenységek valóban olyan védelmi szint alatt állnak, amely megköveteli vagy a aláírás vagy rendszerengedély.
Sajnos számomra ez azt jelenti, hogy csak a /system alá telepített vagy azzal aláírt alkalmazások aláírást, mivel a Beállítások alkalmazás képes lenne megnyitni ezeket a tevékenységeket az általam használt módszerrel megkísérelve. Amikor a Google erre a hibára kerestem választ, (kitaláltad) rábukkantam a Stack Overflow szál. A problémáját közzétevő fejlesztő ugyanazzal a problémával találkozott, mint én (bár az övé éppen egy alkalmazás fejlesztésén volt). A problémája akkor jelentkezett, amikor megpróbálta futtatni a következő kódot:
<span >Intentspan><span > mainIntent span><span >=span><span >newspan><span >Intentspan><span >(span><span >Intentspan><span >.span><span >ACTION_MAINspan><span >,span><span >nullspan><span >);span><span >mainIntentspan><span >.span><span >addCategoryspan><span >(span><span >Intentspan><span >.span><span >CATEGORY_LAUNCHERspan><span >);span><span >Intentspan><span > pickIntent span><span >=span><span >newspan><span >Intentspan><span >(span><span >Intentspan><span >.span><span >ACTION_PICK_ACTIVITYspan><span >);span><span >pickIntentspan><span >.span><span >putExtraspan><span >(span><span >Intentspan><span >.span><span >EXTRA_TITLEspan><span >,span><span >"Pick App to Play in"span><span >);span><span >pickIntentspan><span >.span><span >putExtraspan><span >(span><span >Intentspan><span >.span><span >EXTRA_INTENTspan><span >,span><span > mainIntentspan><span >);span><span >thisspan><span >.span><span >startActivityForResultspan><span >(span><span >pickIntentspan><span >,span><span > REQUEST_PICK_APPLICATIONspan><span >);span>A szándékban szereplő karakterláncok és a fejlesztő weboldala alapján valószínűleg megpróbálta lehetővé tenni a felhasználó számára, hogy egy harmadik féltől származó alkalmazást válasszon a média lejátszásához. A javítást a veterán fejlesztő biztosította CommonsWare, egészen egyszerű volt: használd Elszánt. CreateChooser ahelyett ACTION_PICK_ACTIVITY. Azonban, miért végre kell hajtanunk ezt a javítást? Miért a Huaweinek először is szüksége van erre az engedélyre? Miért meg kellett találnunk a választ a StackOverflow-n egy nagyon specifikus Google-keresés segítségével?
A választás paradoxona
Hogy választ találjunk, A CommonsWare hibajelentést nyújtott be az Android hibakövetőben, és arra kéri a Google-t, hogy vizsgálja meg a problémát. A fejlesztő különösen azt kérte, hogy a Google tiltsa le a nem dokumentált engedélykövetelményeket abban, hogy megakadályozzák a harmadik féltől származó alkalmazások hozzáférését a következőhöz: ACTION_PICK_ACTIVITY. Ezen követelmények beírásával CTS, a Huawei kénytelen lenne megfelelni ezeknek a változtatásoknak.
Őszintén szólva azonban ez a hiba önmagában nem nagy baj. Annak ellenére, hogy egyetlen más általam kipróbált alkalmazás (például a Tasker) sem tudta megkerülni ezt az engedélyt követelménynek, és elindíthat bizonyos tevékenységeket a Beállítások alkalmazáson belül, nem csalódtam benne az eredmény. De amikor eszembe jutott Mr. Ambri rikácsolása, rájöttem, hogy az ehhez hasonló kis változtatásokat nagyon frusztráló lehet kezelni, különösen mert bármilyen aprók is, kétségtelenülösszeadni, néha elég ahhoz, hogy fejfájást okozzon. A Beállítások alkalmazás egyetlen apró módosítása méltatlan negatív értékelést eredményezhet a fejlesztővel szemben. Egy apró változtatás, amely meglehetősen rosszul dokumentálva van, és megkívánta, hogy felkutassam az internetet egy Stack Overflow szálért. Hány egyéb apró hiba található más eszközökön?
A megnövekedett verseny a mobil térben nagyszerűnek bizonyult a fogyasztók számára, de miután láttuk, hogy ezek a finom változások Annyi különböző termékcsaládon keresztül, amelyek hatással lehetnek a fejlesztőkre, már kezdtem értékelni a fejlesztői nézetet töredezettség. Nem maga a választás a probléma, hanem az, hogy a közösség nem tesz eleget ezeknek a kérdéseknek a katalogizálásáért. Ahogy azt Ambri úr a cikkében javasolta, az Android-fejlesztőknek talán saját verzióra van szükségük caniuse.com vagy sdkcritic.com az összes homályos hibát egyetlen adatbázisba gyűjteni. Az egyetlen másik alternatíva az, hogy ráveszi az OEM-eket, hogy vagy megfelelően dokumentálják ezeket a változtatásokat, vagy először leállítsák azokat, de sok sikert azzal.
A szolgáltatás képei: OpenSignal