Pracuję nad Androidem od 2012 roku, na początku były to telefony komórkowe znanej marki. Wtedy pracowałem w bardzo niskich warstwach systemu, Linux Kernel, sterowniki, rdzeń systemu, czyli część odpowiedzialna za init, montowanie partycji i kolejne kroki aż do całkowitego odpalenia się systemu. Potem pracowałem przy modemie, czyli fragment odpowiedzialny za komunikację z zamkniętymi binarkami, aby dało się korzystać z dzwonienia, wifi i tego typu rzeczy, chociaż w tym czasie byłe też zespół SIM/SAT, który bardziej ingerował w te części.
Potem przyszedł czas na Android Wear i robiłem jakiś tam zegarek dla znanej firmy. W sumie odpowiedzialny byłem wtedy już za całość systemu i nawet aplikację, która pokazywała wskazówki. Na sam koniec przyszedł Automotive. Czyli moda na pakowanie Androida do samochodów — i w tej działce pracuję obecnie. Miałem też po drodze kilka epizodów niezwiązanych z AOSP, ale nie było ich zbyt wiele.
Nie mogę wymienić nazw klientów ani nie mogę pisać co dokładnie robię z wiadomych względów, ale używając bardzo generalnego porównania, mogę powiedzieć, że przychodzi klient, mówi, że chciałby coś specyficznego na Androidzie, a ja implementuję. Oczywiście zazwyczaj zespoły są dość duże, ale zdarzało mi się robić pewne rzeczy samemu. Po tylu latach pracy z Androidem często już po chwili da się przedstawić klientowi kilka potencjalnych rozwiązań oraz jakieś wady i zalety poszczególnych z nich.
Pamiętam jak kilka lat temu robiliśmy wsparcie dla kilku ekranów, ale na bardzo niskim poziomie tak aby Android (dokładniej to SurfaceFlinger) sądził, że ma podpięty tylko jeden fizyczny ekran albo przerobienie InputFlingera w taki sposób aby dało się robić gesty na kilku panelach dotykowych - czyli miały się zachowywać jak jeden duży panel. Dość niedawno przerabiałem też AudioPolicy czyli moduł odpowiedzialny za ustalenie tego, kto w danym momencie może używać mikrofonu. Tego typu PoC (Proof of concept) sprawiają, że człowiek ma okazję poznać różne mechanizmy w Androidzie i widać, że niektóre rzeczy były dobrze przemyślane, a inne są rozwiązywaniem problemów, które stworzono wcześniej decydując się na specyficzną architekturę - tak jak np. SELinux i uprawnienia aplikacji.
W panach mam co jakiś czas opisywać coś co napisałem, oczywiście w taki sposób, aby nie łamać umów z klientami. Po co o tym piszę? Otóż często rozwiązuję problemy, które już kiedyś rozwiązywałem. Po pierwsze zmieniając projekt muszę czyścić dysk z poprzedniego projektu - aby jakieś informacje nie wyciekły, więc czasem takie ogólne informacje mogą się przydać. Po drugie AOSP jest bardzo ciekawym projektem i mimo, że ten otwarty projekt jest kontrolowany przez Googla, czyli to oni decydują co się znajdzie w kolejnych wersjach to jego otwartość namnożyła sporo otwartych alternatyw.
Czy trudno być programistą AOSP? Raczej nie, do przyswojenia jest bardzo dużo informacji, ale magii nie ma. Każdy zdobywa doświadczenie z czasem i po kilku latach rozumie go na tyle, że czuje się w jego kodzie swobodnie.
Zarobki są w mojej opinii dobre, cały czas brakuje specjalistów. Firma, w której pracuję poszukuje osób nawet chętnych na szkolenia aby po 2-3 miesiącach mogli pracować w projektach (czyli są w stanie płacić, aby ktoś się nauczył). Oczywiście praca nie jest też bez wad. Jedną z nich jest na pewno specyficzna specjalizacja. Co z tego, że jesteś ekspertem, jeśli jest w PL tylko kilka firm, które poszukują takich ludzi.
Originally posted on Dotevo - developer. Hive blog powered by ENGRAVE.
