Przeciętny użytkownik Androida prawdopodobnie już dawno przestał przejmować się „problemem fragmentacji” Androida. Jednak problem nadal nie daje spokoju deweloperom.
Fragmentacja była kwestią sporną w systemie Android, dosłownie od czasu ogłoszenia mobilnego systemu operacyjnego.
Oprócz tego, że jest pałką dla trolli do wykorzystania w internetowych wojnach płomieni, różnorodność wynikająca z fragmentacji jest obecnie w dużej mierze postrzegana jako netto pozytywny dla konsumentów urządzeń z Androidem. Przecież mamy tak dużą swobodę w wyborze rodzaju urządzenia z rodzajem oprogramowania, jakie chcemy, że przeciętnemu konsumentowi trudno przejmować się fragmentacją. Wizualizacja niesamowitej różnorodności urządzeń z Androidem tworzy piękną mozaikę różnorodnych reprezentacji Androida.
Jednak fragmentacja sprzętu i oprogramowania nie oznacza szczęśliwego programisty. W rzeczywistości, wręcz przeciwnie. Tworzenie aplikacji na tak wielu różnych konfiguracjach sprzętu i oprogramowania może okazać się poważną uciążliwością podczas debugowania. Producenci OEM mogą wprowadzać poważne lub subtelne zmiany, które należy uwzględnić podczas opracowywania aplikacji, ale indywidualny programista naprawdę nie ma łatwego sposobu, aby upewnić się, że ich aplikacja będzie działać uniwersalnie. Choć przeciętny konsument już dawno zapomniał o debacie na temat fragmentacji, problem ten wciąż nie daje spokoju Androidowi twórców aplikacji i pozornie nie można z tym nic zrobić, poza wchłonięciem tego i naprawieniem błędów pojawić się.
Żałosny stan fragmentacji
Szczególnie jeden producent OEM spotyka się z dużą dozą nienawiści z powodu problemów, jakie powoduje podczas tworzenia aplikacji – Samsung. Programiści od lat narzekają na Samsunga, a niektórzy piszą nawet tak zjadliwe artykuły, jak „W piekle Androida jest specjalne miejsce dla Samsunga", który opisuje szczególnie frustrujący błąd wynikający z Urządzenia Samsung i biblioteka kompatybilna z aplikacjami pomocniczymi. Chciałbym zwrócić uwagę szczególnie na jeden akapit tyrady pana Ambriego, który doskonale opisuje, dlaczego programistom w dalszym ciągu zależy na fragmentacji:
Jeśli jesteś programistą Androida, twoja nienawiść do urządzeń Samsunga jest prawdopodobnie nieograniczona. Więcej niż przeciętny użytkownik, dla którego Samsung jest synonimem głupi Touchwiz I nadmierne oprogramowanie typu bloatwaregardzisz Samsungiem, bo nie masz wyboru. Z powodu Samsunga ogromny udział w rynku, po prostu nie możesz zrezygnować z obsługi urządzeń Samsung. I to właśnie boli najbardziej; fakt, że ten wybór został Ci odebrany!
To też nie jest tyrada z dawnych lat istnienia Androida – ten post ukazał się w połowie grudnia ubiegłego roku. Od razu powiem, że nie jestem pewien, czy problem ten został już oficjalnie rozwiązany, jednakże, panie ministrze. Ambri w swoim poście zapewnił rozwiązanie dla każdego, kto natknie się na jego tyradę w wyszukiwarce Google dla hasła błąd. Wszystko, co musisz zrobić, to użyć ProGuard z następującą pojedynczą linijką kodu:
# 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.** {*;}Nie jest tak źle, prawda? Problem polega jednak na tym, że ta poprawka została usunięta z Stack Overflow. Nie zrozumcie mnie źle, Stack Overflow to świetna witryna. Jednak nie jest to idealne źródło do wyszukiwania poprawek dla aplikacji. Znalezienie czegoś na Stack Overflow często wymaga głębokiego przeglądania linków po wielu wyszukiwarkach Google metodą prób i błędów. Czasami nawet inny użytkownik wspomni o tym samym błędzie, który miałeś, ale bez widocznego rozwiązania. Jeszcze bardziej frustrujące są sytuacje, w których znajdujesz wątek, w którym twierdził autor oryginalnego plakatu znaleźli rozwiązanie, ale już dawno porzucili swój wątek, nie instruując innych, jak to naprawić wydanie.
Przykład subtelnego problemu fragmentacji
Sam nie jestem programistą, ale po latach majsterkowania w Taskerze jestem na tyle zaznajomiony z możliwościami Androida, że zacząłem pseudoprogramować własne rozwiązania problemów, które napotkałem. A kiedy nie mogę czegoś rozgryźć, wrzucam to do Google, tak jak wszyscy inni. Kiedy pisałem mój poprzedni artykuł nt przeszukując aplikację Ustawienia w telefonie w poszukiwaniu ukrytych działań, natknąłem się na dość dziwny błąd, którego nie potrafiłem wyjaśnić. Błąd charakterystyczny dla urządzeń Huawei.
Ilekroć próbowałem rozpocząć określone czynności (takie jak menu „Testowanie”, które zawiera statystyki użytkowania aplikacji) w aplikacji Ustawienia, zawsze pojawiał się błąd uprawnień. W szczególności aplikacja, której używałem do rozpoczęcia działania, nie miała pozwolenia huawei.android.pozwolenie. HW_SIGNATURE_OR_SYSTEM. Żadne inne testowane przeze mnie urządzenie nie wymagało żadnych unikalnych uprawnień do uruchomienia tych ustawień, a jedynie telefony z wersją Androida (EMUI) firmy Huawei. Analiza com.android.settings ujawniło, że niektóre działania w aplikacji Ustawienia rzeczywiście znajdowały się poniżej poziomu ochrony wymagającego: podpis lub uprawnienia systemowe.
Niestety dla mnie oznacza to, że tylko aplikacje zainstalowane w /system lub aplikacje podpisane tym samym podpis, ponieważ aplikacja Ustawienia byłaby w stanie otworzyć te działania przy użyciu mojej metody próbować. Kiedy przeszukałem Google ten błąd w poszukiwaniu odpowiedzi, (zgadłeś) natknąłem się na Wątek przepełnienia stosu. Programista zgłaszający swój problem natknął się na ten sam problem co ja (chociaż był w trakcie tworzenia aplikacji). Problem pojawił się, gdy próbował uruchomić następujący kod:
<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>Sądząc po treści intencji i stronie internetowej programisty, prawdopodobnie próbował pozwolić użytkownikowi wybrać aplikację innej firmy, w której będzie mógł odtwarzać niektóre multimedia. Poprawka dostarczona przez doświadczonego programistę CommonsWare, było całkiem proste: użyj Zamiar. UtwórzChooser zamiast ACTION_PICK_ACTIVITY. Jednakże, Dlaczego czy powinniśmy wdrożyć tę poprawkę? Dlaczego czy Huawei wymaga w pierwszej kolejności tego pozwolenia? Dlaczego czy musieliśmy znaleźć odpowiedź na StackOverflow, korzystając z bardzo szczegółowej wyszukiwarki Google?
Paradoks wyboru
Aby znaleźć odpowiedź, CommonsWare złożyło raport o błędzie w narzędziu do śledzenia błędów systemu Android, prosząc Google o zbadanie problemu. W szczególności programista zażądał, aby Google zakazał wymaganiom nieudokumentowanych zezwoleń uniemożliwiających aplikacjom innych firm dostęp do ACTION_PICK_ACTIVITY. Wpisując te wymagania w CTS, Huawei byłby zmuszony zastosować się do tych zmian.
Jednak szczerze mówiąc, ten błąd sam w sobie nie jest wielkim problemem. Mimo że żadna inna aplikacja, którą wypróbowałem (taka jak Tasker), nie była w stanie obejść tego uprawnienia wymagań i uruchomić określone czynności w aplikacji Ustawienia, nie byłem do końca rozczarowany Wynik. Kiedy jednak przypomniałem sobie tyradę pana Ambriego, zdałem sobie sprawę, że takie drobne zmiany muszą być bardzo frustrujące, zwłaszcza ponieważ bez względu na to, jak małe mogą być, niewątpliwie sądodać, czasami tak, że powoduje ból głowy. Jedna drobna zmiana w aplikacji Ustawienia może skutkować niezasłużoną negatywną oceną programisty. Jedna drobna zmiana, która jest raczej słabo udokumentowana i wymagała od mnie przeszukania Internetu w poszukiwaniu wątku Stack Overflow. Ile innych drobnych błędów występuje na innych urządzeniach?
Zwiększona konkurencja w przestrzeni mobilnej okazała się świetna dla konsumenta, ale po zobaczeniu, jak te subtelne zmiany tak wielu różnych linii produktów może mieć wpływ na programistów, zacząłem doceniać punkt widzenia programistów podział. Nie chodzi o to, że sam wybór jest problemem, ale raczej o to, że społeczność nie robi wystarczająco dużo, aby skatalogować te problemy. Jak zasugerował Ambri w swoim artykule, być może programiści Androida potrzebują własnej wersji caniuse.com Lub sdkcritic.com aby zebrać wszystkie mało znane błędy w jednej bazie danych. Jedyną inną alternatywą jest nakłonienie producentów OEM do odpowiedniego udokumentowania tych zmian lub zaprzestania ich wprowadzania Powodzenia z tym.
Autorzy obrazu fabularnego: OtwórzSygnał