Inżynierowie Google przeprowadzili pewnego dnia AMA na Reddicie. AMA dotyczyło wersji beta Androida Q. Oto podsumowanie tego, czego dowiedzieliśmy się z ich odpowiedzi.
W zeszłym roku zespół Google zajmujący się Androidem zorganizował ankietę Ask Me Everything (AMA) na subreddicie /r/AndroidDev serwisu Reddit, w ramach której zadawał pytania dotyczące Podgląd programisty Androida P. W tym roku zespół inżynierów pracujący nad wersją beta Androida Q odpowiadał na pytania na Reddicie. AMA rozpoczęło się 1 sierpnia o godzinie 12:00 czasu PST i zakończyło około półtorej godziny później. W AMA zaangażowanych było 33 inżynierów Google, którzy odpowiedzieli na mnóstwo pytań w krótkim czasie trwania AMA. Oto podsumowanie wszystkich nowych informacji, których się dowiedzieliśmy.
Android Q AMA: wszystkiego, czego nauczyliśmy się od Google
Uczestnicy zespołu beta Androida Q
- Adam Cohen: TLM w programie uruchamiającym Androida / interfejsie systemowym
- Adam Powell: TLM w zestawie narzędzi/frameworku interfejsu użytkownika; widoki, cykl życia, fragmenty, biblioteki pomocnicze
- Alana Viveretty: TLM, Jetpack/AndroidX
- Allena Huanga: PM dla interfejsu użytkownika, programu uruchamiającego, powiadomień, integracji wyszukiwania i nie tylko!
- Andrzej Sapirstein: TLM w ustawieniach Androida
- Brahima Elbouchikhiego: PM Director ds. uczenia maszynowego i aparatu Android (NN API, ML Kit, CameraX, platforma Camera)
- Chada Brubakera: Inżynier oprogramowania, bezpieczeństwo platformy Android
- Charmaine D’Silva: Premier ds. prywatności
- Cheta Haase’a: Główny rzecznik Androida, relacje z programistami
- Diana Wong: PM, zgodność aplikacji, użycie interfejsu API innego niż SDK, ART, NDK
- Dianę Hackborn: Menedżer zespołu frameworku Android (Zasoby, Menedżer okien, Menedżer aktywności, Wielu użytkowników, Drukowanie, Dostępność itp.)
- E.K. Chung: Dyrektor UX
- Jezioro Iana: Inżynier oprogramowania, Jetpack (fragmenty, nawigacja, komponenty architektury)
- Ilijan Malchev: Główny inżynier oprogramowania, Project Mainline
- Jakub Lehrbaum: Dyrektor ds. relacji z programistami dla systemu Android
- Jake’a Whartona: Inżynier oprogramowania, Jetpack
- Jamala Easona: PM, Android Studio
- Jeffa Baileya: TLM, projekt Android Open Source (AOSP)
- Jeffa Sharkeya: Inżynier oprogramowania, Android Framework
- Jeffreya van Gogha: Android Studio, kompilatory
- Jen Chai: PM, lokalizacja i kontekst, uwierzytelnianie, autouzupełnianie, użycie interfejsu API innego niż SDK, ART
- Karen Ng: Grupowy PM dla Android Developer Tools, Android Studio, Android Tookit i Jetpack
- Paul Bankhead: Dyrektor ds. zarządzania produktami, Google Play
- Rohan Shah: Menedżer produktu, interfejs użytkownika systemu Android
- Romain Guy: Menedżer zespołu Android Toolkit/Jetpack
- Sagar Kamdar: Dyrektor ds. zarządzania produktami, Android
- sobota K: Dyrektor ds. inżynierii ds. łączności z systemem Android
- Selim Cinek: Inżynier oprogramowania, interfejs użytkownika systemu Android
- Stephanie Saad Cuthbertson: Starszy dyrektor ds. zarządzania produktami, Android
- Sumir Kataria: Inżynier oprogramowania, Jetpack (WorkManager)
- Travis McCoy: PM, platforma Android
- Trystan w górę: Wybitny inżynier, kierownik ds. interfejsu użytkownika i inteligencji systemu Android
- Vinit Modi: PM, aparat z Androidem
Czytaj więcej
Producenci OEM nie mogą już zabijać aplikacji, gdy użytkownik przesunie je w ostatnio używanych aplikacjach
Jeśli kiedykolwiek korzystałeś ze smartfona chińskiej marki, prawdopodobnie miałeś do czynienia z irytującymi funkcjami „optymalizacji baterii”, które zabij wszystkie swoje ulubione aplikacje w tle. Takie zachowanie jest nie tylko irytujące dla użytkowników, którzy z jakiegokolwiek powodu oczekują, że niektóre aplikacje będą nadal działać w tle, ale ale jest to również denerwujące dla programistów, którzy muszą znosić słabe recenzje od użytkowników, którzy nie rozumieją, że to nie jest wina aplikacji wada. Podczas gdy Google jest Nadal nie zajmując się w pełni tą sprawą (machali ręką, stwierdzając, że takie zachowanie jest prawdopodobnie już naruszając wymagania dokumentu definicji zgodności Androida), firma Jest podjąć działanie przeciwko jednej zmianie zachowania polegającej na „oszczędzaniu baterii” stosowanej przez niektórych producentów OEM.
„Aby zaradzić tej sytuacji, dodaliśmy test CTS w Androidzie Q, aby upewnić się, że aplikacja nie zostanie zawieszona po przesunięciu z Niedawnych”.
Android R może przynieść więcej zmian w zrzutach ekranu, niż się spodziewaliśmy
Google planuje dodać przewijanie zrzutów ekranu w Androidzie R, ale jednocześnie Zespół Androida jest „przyglądamy się uważnie, jak [oni] mogą ulepszyć działanie całego ekranu — [X] w R.” Zatem możemy zobacz inne ulepszenia zachowania zrzutów ekranu (ORAZ screencastów) w następnej głównej wersji Androida.
Wyjaśnienie nowego trybu pulpitu Androida Q
The pierwsza publiczna wersja beta Androida Q wprowadziło interfejs trybu ukrytego pulpitu do AOSP i Pixel Launcher. Chociaż Google krótko poruszono tę funkcję podczas sesji Google I/O nigdy nie usłyszeliśmy bezpośrednio od Google, jak nowa funkcja wpisuje się w ekosystem Androida. Google teraz wyjaśnia:
„W Q AOSP „tryb pulpitu” to opcja programistyczna przeznaczona dla twórców aplikacji. Umożliwia im testowanie aplikacji w środowiskach wieloekranowych i w trybie okienkowym o dowolnym kształcie. Wcześniej nie było wygodnego sposobu testowania zachowania aplikacji na dodatkowym wyświetlaczu i przy dowolnie zmienianych rozmiarach okien w standardowym systemie Android. Ta funkcja nie jest dostępna samodzielnie i nie jest obecnie przeznaczona dla zwykłych użytkowników. Niemniej jednak dla producentów OEM stanowi podstawę platformy Android do wprowadzania innowacji i tworzenia świetnych produktów”.
Dlatego możemy spodziewać się, że producenci OEM będą korzystać z natywnego trybu pulpitu Androida Q. Na przykład OnePlus 7 Pro obsługuje wyświetlanie przez HDMI, więc jest to możliwe OxygenOS 10 oparty na Androidzie Q w przyszłości będzie miał własny interfejs w trybie pulpitu. Mamy również nadzieję, że Google w przyszłości rozwinie tę funkcję Piksel 4.
Tryb ciemny oparty na czasie
Android Q wreszcie oferuje szeroko pożądaną funkcję: tryb ciemny w całym systemie. Obecnie tryb ciemny można włączyć ręcznie w Ustawieniach lub za pomocą kafelka Szybkich ustawień, albo może on zostać aktywowany automatycznie po włączeniu Oszczędzania baterii. Przed Androidem Q istniała opcja włączenia trybu ciemnego w zależności od pory dnia, ale ta opcja została przestarzała. Według Chrisa Banesa:
„Jest kilka powodów, dla których jest to przestarzałe (nie usunięte) w AppCompat v1.1.0: wymaga, aby aplikacje żądały pozwolenia na lokalizację, aby były dokładne, a nawet przy prawidłowej lokalizacji można obliczyć czas wschodu/zachodu słońca powozik."
Zapytany o te błędy, pan Banes stwierdza, że „obliczanie wschodów i zachodów słońca jest niezwykle trudne, szczególnie w przypadku lokalizacji położonych blisko biegun północny/południowy.” Użytkownik przywołuje lampkę nocną, dostępną od wersji Androida 7.1 Nougat, która może być przełączana automatycznie w zależności od zachodu i wschodu słońca harmonogramy. Następnie pan Banes stwierdza, że skoro Night Light korzysta z CalendarAstronomer z ICU4J, używa „dużego fragmentu kodu, na którym nie chcielibyśmy, aby AppCompat polegał”. Jednak zespół to robi państwo że ta funkcja jest „czymś, czemu [będą] się przyglądać”.
Obowiązkowa obsługa interfejsu API Camera2/Camera HAL3 dla urządzeń z systemem Android Q
Firma Google wprowadziła interfejs API Camera2, aby lepiej zdefiniować sposób interakcji aplikacji z poszczególnymi kamerami podłączonymi do smartfona. Podczas gdy Google zachęca producentów smartfonów do „udostępniania programistom wszystkich swoich fizycznych kamer”, wielu dostawców decyduje się tego nie robić, mimo że „sam interfejs API nie jest uniemożliwiając im już dziś.” Oznacza to, że wiele aplikacji aparatu innych firm nie może korzystać z dodatkowych lub trzeciorzędnych modułów kamery w nowoczesnych modelach smartfony. Postęp jest jednak zauważalny wraz z udoskonalaniem Androida Q LOGICAL_MULTI_CAMERA, interfejs API zapewniający programistom lepszy dostęp do wszystkich kamer w urządzeniu i zapewniający producentom OEM kontrolę nad zużyciem energii i zarządzaniem stanami wielu kamer.
Ponadto Google twierdzi, że dodał wymagania dla wszystkich urządzeń uruchamianych z systemem Android Q, aby natywnie obsługiwały API Camera2/Camera HAL3. Zdaniem Vinita Modiego:
„Począwszy od Androida P, nowe urządzenia dostarczane z 1 GB lub więcej pamięci RAM muszą natywnie korzystać z HALv3/camera2. Wszystkie nowe urządzenia z systemem Android Q i nowszym muszą natywnie obsługiwać HALv3/camera2. Niestety uaktualnienia z HALv1 do HALv3 są dość skomplikowane bezprzewodowo i mogą mieć nieoczekiwane konsekwencje, dlatego musieliśmy ograniczyć zakres do nowych urządzeń.
Co ciekawe, oświadczenie Modiego na temat urządzeń uruchamiających normalną pamięć RAM Android P zaprzecza co nam wcześniej powiedział Google i co opublikowano na stronie internetowej pakietu Image Test Suite.
Dynamiczne motywy aplikacji za pomocą Jetpack Compose
Struktura tematyczna OMS firmy Sony została dodana do AOSP kilka wydań wcześniej, ale to tylko jedna z nich przeznaczone dla producentów OEM na czym budować. Już to wiemy Google jest przeciw wykorzystanie nakładek zasobów wykonawczych przez użytkowników do aplikacji tematycznych, ale w przypadku programistów firma tak mając nadzieję to jest to Interfejs tworzenia Jetpacka Framework zaproponuje „interesujące podejście do dynamicznego motywowania”.
Backend Vulkan dla Skia do renderowania interfejsu użytkownika
Ostatni rok, zauważyliśmy dyskusję wśród inżynierów Google mówiących o swoich planach wykorzystania frameworku Android do interfejsu graficznego Vulkan do renderowania interfejsu użytkownika. Chociaż teraz można włączyć przyspieszany sprzętowo backend Vulkan bez telefonu zawiesza się, nie otrzymaliśmy od Google żadnych konkretnych planów dotyczących daty wdrożenia zmiany. To AMA nie odpowiada na to pytanie, ale przynajmniej mamy potwierdzenie, że nadal nad nim pracujemy. Według Romaina Guya:
„Zespół pracował nad backendem Vulkan dla Skia, renderera 2D używanego przez Androida, ale obecnie nie jest on domyślnie włączony. Interfejs użytkownika i płótno nadal przechodzą przez OpenGL ES.”
Zwiększanie dynamiki paska gestów w Androidzie Q
Niektórzy na XDA nadal tak myślą Nowe gesty w Androidzie to bałagan, ale osobiście uważam, że są w porządku. Jeśli jednak pobawisz się przez chwilę nowymi gestami w Androidzie Q, zauważysz, że pasek gestów nie porusza się wraz z palcem. Pojawia się także na ekranach, gdzie nie jest potrzebny, np. na ekranie głównym lub w przeglądzie ostatnich aplikacji. Allena Huanga mówi że „całkowicie zgadzają się, że istnieją możliwości”, aby uczynić „linię nawigacyjną mniej statyczną”. Mówi dalej że „jest to coś, nad czym pracujemy, ale także równoważymy to, aby nie rozpraszało pojawianie się/znikanie.”
Ulepszenia struktury dostępu do pamięci masowej
Wiele zmian w Androidzie Q znacznie poprawiło bezpieczeństwo i prywatność platformy. Jedna z takich zmian, zwana „Scoped Storage”, ogranicza dostęp aplikacji do plików w pamięci zewnętrznej w sensowny sposób; aplikacje muzyczne nie powinny na przykład widzieć Twojej galerii. Aplikacje do zarządzania plikami działające w systemie Android Q muszą korzystać z interfejsu API zwanego strukturą dostępu do pamięci masowej, aby móc normalnie działać, ale niektórzy programiści uważają ten interfejs API za gorszy do tego, co było wcześniej dostępne. Jeff Sharkey z Google’a mówi zespół zajął się niektórymi skargami programistów:
„W najnowszych wersjach Androida Q Beta wprowadziliśmy pewne ulepszenia wydajności SAF; czy mógłbyś sprawdzić swoje testy porównawcze z najnowszą wersją beta? Upewnij się także, że używasz ContentProviderClient podczas wykonywania jakichkolwiek operacji zbiorczych.
Project Treble poprawił adaptację Androida Pie w porównaniu z Androidem Oreo
Widzieliśmy już, jak Project Treble, główna niskopoziomowa przebudowa platformy Android, usprawniła przyjęcie nowszych wersji systemu operacyjnego Android. Google przypisuje firmie Treble udział w dołączeniu wielu dostawców smartfonów Beta Androida P w zeszłym roku i Beta Androida Q W tym roku. Iliyan Malchev, główny projekt Treble i Linia główna inżynier, mówi że przyjęcie Androida Pie było „3 razy” większe niż Androida Oreo pod koniec 2018 r.
W tym samym komentarzu Dick Dougherty oznajmia, że trwają prace nad bardziej przydatnymi wskaźnikami dotyczącymi wykresu dystrybucji wersji Androida. Wykres był ostatnia aktualizacja w maju, ale zawarte w nim dane są bardziej przydatne dla dziennikarzy niż twórców aplikacji.
Nagrywanie ekranu to wciąż WIP
Wczesne wersje beta systemu Android Q dodały flagę funkcji podstawowego rejestratora ekranu, ale sama platforma znacznie poprawiła użyteczność nagrywania ekranu poprzez umożliwiając aplikacjom przechwytywanie dźwięku z innych aplikacji. Stephanie Saad Cuthbertson powiedziała, że zespół jeszcze wczoraj rozważał, „w jaki sposób moglibyśmy lepiej sprostać potrzebom związanym z nagrywaniem ekranu”. Inne marki smartfonów, takie jak OnePlus, ASUS, Huawei i Samsung mają solidne rejestratory ekranu, które mogą nagrywać wewnętrzny dźwięk, więc Google będzie tutaj nadrabiać zaległości.
Ciemny motyw Wszystkie rzeczy!
Jeśli to przegapiłeś, Google dodaje tryb ciemny do większości swoich aplikacji. Stephanie Saad Cuthbertson mówi oczekiwać, że wszystkie „główne aplikacje” będą obsługiwać ciemny motyw „w oficjalnej wersji [Android Q]”. Nawet Google Chrome, który obecnie wymusza ponowne załadowanie strony, gdy włączony jest ciemny motyw w całym systemie, zostanie zaktualizowany, aby nie był już odświeżany, gdy motyw jest włączony zmieniony.
Tak, programy uruchamiające innych firm będą działać z gestami (ostatecznie)
Gesty Androida są w pewnym sensie uszkodzony podczas korzystania z programu uruchamiającego innej firmy. Dzieje się tak dlatego, że interfejs użytkownika najnowszych aplikacji jest zawarty w aplikacji uruchamiającej giełdę, a Google jeszcze tego nie zrobił wypracowaliśmy sposób na płynne przejścia, jakie widzimy podczas korzystania z gestów na standardowym Pixelu Wyrzutnia. Adama Cohena potwierdza Google planuje rozwiązać te problemy „tak szybko, jak to możliwe po wydaniu”. Dalej tak twierdzi niezgodność „zostanie rozwiązana w aktualizacji po Q i przeniesiona ponownie dla nowych urządzeń uruchamianych za pomocą Q."
Partycje dynamiczne/logiczne nie służą do zabijania niestandardowych ROM-ów
Aby wesprzeć Dynamiczne aktualizacje systemu w systemie Android Q niektóre urządzenia, takie jak Google Pixel 3 i Pixel 3 XL, korzystają z partycji logicznych. Rozmiar tych partycji można dynamicznie zmieniać. Ta zmiana ma okazało się trudne w uzyskaniu dostępu do roota, a niektórzy programiści obawiają się, że celem są niestandardowe ROMy. Iliyan Malchev zapewnia nas, że naszym zamiarem nie jest ograniczanie niestandardowych ROM-ów. Jak on tłumaczy:
„Partycje dynamiczne nie mają na celu ograniczania możliwości niestandardowych pamięci ROM. Są po prostu rozwiązanie problemu stałych rozmiarów partycji i braku bezpiecznego sposobu ponownego partycjonowania urządzeń OTA. Przed partycjami dynamicznymi, jeśli producent OEM popełnił błąd przy doborze rozmiaru, np. partycję systemową, a następnie one byłby ograniczony takim wyborem, co praktycznie uniemożliwiałoby modernizację urządzenia po pewnym czasie punkt. Niektórzy producenci OEM w ramach praktyki dzielą swoje urządzenia na partycje poprzez OTA, ale jest to a) nieobsługiwane oficjalnie w systemie Android oraz b) zmiana tabeli partycji jest uważana za dość ryzykowną. Partycje dynamiczne mają na celu złagodzenie problemu poprzez wprowadzenie poziomu pośredniego między fizyczną tablicą partycji a systemem operacyjnym. To z kolei pozwala nam bezpiecznie dostosowywać rozmiary partycji w OTA. Jeśli chodzi o niestandardowe ROMy, nie powinieneś być wcale bardziej ograniczony tym, co możesz zrobić. Obsługa niestandardowych pamięci ROM jest i nadal będzie czymś, na co decyduje się każdy indywidualny producent OEM.
Główna linia projektu — moduł ART i długość wsparcia
Mainline to nowa inicjatywa Google, której celem jest ujednolicenie niektórych bibliotek i pakietów, aby można je było aktualizować niezależnie od aktualizacji platformy. Niektórzy zastanawiali się, dlaczego środowisko wykonawcze systemu Android (ART) nie jest jeszcze modułem Mainline, ale podczas Google I/O powiedziano mi, że złożoność związana z modularyzacją ART uniemożliwiła im włączenie go jako jednego z początkowych pakietów APEX. Jak wyjaśnione zarówno przez Iliyana Malcheva, jak i Dianę Wong:
„Wprowadzanie aktualizacji środowiska wykonawczego (zwłaszcza poprawek wydajności i GC oraz bibliotek podstawowych) to zdecydowanie coś, co badamy w kontekście głównego nurtu. Widzimy wiele korzyści w zapewnieniu spójności tych aktualizacji na wszystkich urządzeniach i w wielu wersjach w wersji głównej. Jest to także ogromne wyzwanie techniczne, ponieważ zastanawiamy się, jak zrobić to najlepiej dla programistów, i prawdopodobnie będzie to wysiłek wieloletni. Nie jest to coś, co Mainline może obecnie zrobić, ale z pewnością jest to coś, o czym myślimy.
Jeśli podążasz za AOSP Gerrit, zobaczysz, że Google mimo to był ciężko w pracy tworzenie APEX-u środowiska wykonawczego. Obecnie wydaje się, że tak rozdzielenie Bionic i ART/libcore na osobne moduły APEX.
Jeśli chodzi o korzyści płynące z Project Mainline, jeden z użytkowników zapytał o długość aktualizacji Mainline. W odpowiedzi Ilijan Malchev mówi że „jest to kwestia polityczna, którą wciąż oceniamy, ale chcemy aktualizować moduły Mainline na urządzeniu tak długo, jak to możliwe”. Uznany programista XDA Luca020400 zapytano, czy zostaną dostarczone gotowe moduły Mainline, aby programiści niestandardowych pamięci ROM mogli łączyć aktualizacje, i w odpowiedzi Jeff Bailey powtarza że „moduły oddzielające się od AOSP będą miały wydania źródłowe odpowiadające każdemu wydaniu modułu”. Widzimy już rozwój nowych modułów APEX w AOSP, takich jak jeden dla API sieci neuronowych.
CameraX spełnia ML Kit
Podczas tegorocznej konferencji I/O firma Google przedstawiła technologię Biblioteka CameraX Jetpack. Ta biblioteka została zaprojektowana, aby ułatwić programistom obsługę interfejsu API Camera2 systemu Android przy jednoczesnym zachowaniu zgodności z systemem Android Lollipop. Vinita Modiego dokucza z którymi firma pracuje nad integracją CameraX Zestaw ML, pakiet SDK Firebase do uczenia maszynowego firmy Google, dzięki któremu programiści mogą przesyłać ramki obrazów do narzędzia ML Kit w celu analizy.
Rozszerzenia dostawcy CameraX i data wydania
Twórca aplikacji aparatu ubolewa nad faktem, że zaawansowane funkcje aparatu, takie jak celownik nocny Google Pixel, nie są dostępne dla aplikacji aparatu innych firm. Ma to zostać rozwiązane za pomocą rozszerzeń dostawcy CameraX, do których doszedł Jeff Sharkey z Google mówi że „wszystkie urządzenia Pixel są zoptymalizowane pod kątem CameraX Core”. Dokucza, że „aspekt Rozszerzenia będzie obsługiwany na nowych i nadchodzących urządzeniach”. Co więcej, Google jest „współpracuję z kilkoma producentami, aby móc udostępnić możliwości ich urządzeń zarówno programistom, jak i użytkownikom”. Chociaż nie zostało to bezpośrednio potwierdzone, możliwe, że zobaczymy nowe funkcje tak jak Nocny widok na Google Pixel 4 staną się dostępne dla aplikacji aparatu innych firm korzystających z biblioteki CameraX.
Sharkey twierdzi, że Google planuje wydanie wersji beta pod koniec tego roku.
Ulepszenia zarządzania pamięcią w systemie Android Q
Pixel 3 został skrytykowany za to, że go posiada liczne problemy po uruchomieniu, ale firma Google zrobiła wiele, aby rozwiązać te problemy, za pośrednictwem licznych aktualizacje po uruchomieniu. Zarządzanie pamięcią jest jednym z najsłabszych aspektów Pixela 3, ale w wersji Androida Q powinno być nieco lepiej. Według Selima Cinka:
„Na przykład w SystemUI podejmowaliśmy różne duże wysiłki w zakresie refaktoryzacji w Q, aby zmniejszyć wykorzystanie pamięci RAM przez powiadomienia i inne powierzchnie”.
Czy w końcu otrzymamy bezprzewodowe ADB?
Jeśli chcesz bezprzewodowo debugować swój telefon, musisz zrootować swoje urządzenie. Jamal Eason z zespołu Android Studio mówi że obecnie zajmują się wykonalnością tej funkcji.
Czy Google nadal testuje na tabletach?
Uznany programista XDA Łuk1337 zapytano, czy Google nadal testuje AOSP UX na tabletach. To rozsądne pytanie, biorąc pod uwagę brak dobrych tabletów z Androidem i obecne błędy w bieżących wydaniach. Allena Huanga mówi że Google nadal „co roku testuje i wprowadza poprawki” oraz że ściśle współpracuje z partnerami, „aby zapewnić dobre działanie tabletu z Androidem”.
W pełnym wątku na Reddicie znajduje się znacznie więcej postów. To, co tutaj omówiłem, podsumowuje wszystkie nowe informacje, których się nauczyliśmy, ale kilku pracowników Google (zwłaszcza Dianne Hackborn) przedstawiają swoje uzasadnienie wycięcia funkcji X lub niezaimplementowania Y pozwolenie. Jeśli chcesz lepiej zrozumieć proces decyzyjny zespołu Androida, polecam przeczytać całe AMA.
Przeczytaj całe AMA na /r/AndroidDev