Wpisy

Uprawnienia użytkownika w Androidzie 10 i nowszych

Projektując kolejne wersje systemu Android, Google dodaje kolejne uprawnienia i zmiany w tym systemie operacyjnym związane z prywatnością i ochroną danych użytkownika. Od wersji 11 w podsystemie uprawnień użytkownika dzieje się jednak prawdziwa rewolucja, wpływająca na wszystkie aktywnie wpierane aplikacje dostępne w Google Play.

Zmiany są częste – wprowadzane z każdą kolejną wersją systemu – i komunikowane w sposób charakterystyczny dla Google, czyli niejasno. Dlaczego moja aplikacja na Androida nagle przestała działać? – to chyba najczęściej w ciągu ostatnich dwóch lat stawiane nam pytanie przez właścicieli różnych aplikacji dostępnych w Google Play. Odpowiedź jest prawie zawsze taka sama – jeśli aplikacja korzysta z usług lokalizacyjnych, zapisuje dane na dysku użytkownika, ma wbudowane funkcje związane z bluetooth – to, to co działało do Androida 10, od Androida 11 działać nie będzie o ile aplikacja nie zapyta użytkownika o zgodę na używanie tych funkcjonalności i jeśli użytkownik się na ich używanie nie zgodzi.

W najnowszym wydaniu systemu Android – wersji 13 – pojawiły się kolejne uprawnienia wpływające na funkcjonalność aplikacji – wzorem iOS, Android pyta teraz użytkownika o pozwolenie na pokazywanie powiadomień. Jeśli użytkownik się nie zgodzi, aplikacja powiadomień wyświetlać nie będzie, a co za tym idzie zostaną wyłączone wszystkie funkcje zależne od pokazywania powiadomień, takie jak np. usługi lokalizacyjne w tle.

Warto mieć świadomość, że wprawdzie właścicieli aplikacji opartych o wspomniane funkcjonalności, takich jak np. systemy monitoringu, zmiany te mogą irytować, gdyż aplikacje praktycznie co roku wymagają znaczących aktualizacji pociągających za sobą koszty, to jednak z punktu widzenia użytkownika są to zmiany jak najbardziej słuszne i wprowadzone o wiele za późno.

Oficjalnym powodem wprowadzania zmian w systemie Android jest dbałość o prywatność użytkowników. W rzeczywistości tak daleko idące zmiany ograniczające Google możliwość śledzenia użytkowników są dla tej korporacji wyjątkowo niewygodne, gdyż uderzają bezpośrednio w model biznesowy producenta systemu operacyjnego (reklama i profilowanie danych), jednak firma została do nich zmuszona gigantyczną karą finansową wynoszącą ok. 4,5 miliarda euro za naruszanie prywatności użytkowników.

Aby nieco uporządkować system uprawnień w Androidzie i mieć świadomość czego należy się spodziewać krótki przewodnik po kolejnych wersjach uprawnień użytkownika w kolejnych wersjach Androida:

Android 9

Usługi bluetooth, lokalizacja za zgodą użytkownika, zapis danych na dysku będą działały tak jak wcześniej. Jeśli aplikacja korzysta ze stałego śledzenia pozycji użytkownika w tle, od Androida 9 obowiązkowe jest wyświetlanie stałego powiadomienia w bloku  tzw. cichych powiadomień na belce systemowej, że aplikacja cały czas działa w tle i zbiera dane o lokalizacji. Powiadomienie musi być stale obecne pomimo, że użytkownik wydał zgodę na takie działanie – ma przypominać użytkownikowi o wyrażonej zgodzie i fakcie, że w każdej chwili może ją cofnąć.

Android 10

Pierwsza poważna zmiana dla aplikacji, które swoją główną funkcjonalność budują na znajomości stałego położenia użytkownika. Wyznaczanie pozycji użytkownika działa tylko po wyrażeniu przez użytkownika zgody i tylko, gdy aplikacja jest uruchomiona. Wprowadzono nowe uprawnienie lokalizacyjne „Lokalizacja w tle”. Pytanie o to uprawnienie jest zawarte bezpośrednio w oknie z pytaniem o lokalizację pod nazwą „Zawsze zezwalaj” – stałe wyznaczanie pozycji użytkownika jest możliwe tylko jeśli użytkownik zaakceptuje to uprawnienie.

Android 11 i 12

Ta wersja systemu Android z punktu widzenia właścicieli aplikacji jest najbardziej kłopotliwa – nie obejdzie się bez dostosowania kodu i aktualizacji aplikacji. Android 11 całkowicie zmienia sposób obsługi uprawnienia „Lokalizacja w tle” – nie jest ono już pokazywane w dymku z pytaniem o lokalizację, a należy odesłać użytkownika do ustawień systemu, aby mógł wybrać odpowiednią opcję ręcznie. Jednak można to zrobić dopiero po tym, gdy użytkownik przyzna jakiekolwiek inne uprawnienie do lokalizacji – uzyskiwanie uprawnień lokalizacyjnych odbywa się zatem dwuetapowo.

Ta wersja systemu Android zmienia również uprawnienia do zapisu danych oraz używania funkcji bluetooth, aparatu i mikrofonu. Aplikacje mają całkowicie cofniętą możliwość zapisu danych w różnych folderach systemowych – zapis danych może się odbywać wyłącznie w dedykowanym folderze aplikacji. Aby uzyskać możliwość zapisu i odczytu danych z folderów plików multimedialnych – szczególnie istotne dla aplikacji korzystających z funkcji fotograficznych i funkcji mikrofonu – wprowadzono dodatkowe, szczególne uprawnienia podlegające silnym restrykcjom ze strony systemu operacyjnego.

Część uprawnień związanych z lokalizacją, aparatem, mikrofonem i bluetooth została przeniesiona do tzw. uprawnień specjalnych newralgicznych – korzystać z nich mogą tylko aplikacje, których funkcjonalności uzasadniają korzystanie z tych uprawnień, a ich publikacja w Google Play jest poprzedzona uzyskaniem dodatkowej zgody od Google na publikację w procesie rozszerzonej recenzji.

Android 13

W Androidzie 13 wprowadzono nowe uprawnienie „Pokazuj powiadomienia”. Same uprawnienia do lokalizacji działają tak, jak w Androidzie 11 i 12. Należy jednak zwrócić uwagę, że aby włączyć lokalizację w tle, już od Androida 9 trzeba pokazywać stałe powiadomienie w tzw. bloku „ciche” na belce systemu, informujące użytkownika, że aplikacja działa i zbiera dane o lokalizacji. Zatem w Androidzie 13, aby włączyć lokalizację w tle, użytkownik najpierw musi wyrazić zgodę na pokazywanie powiadomień, a dopiero następnie wyrazić zgodę na lokalizację w procesie dwuetapowego uzyskiwania pozwolenia.

WearOS 3 – czas na zmiany

Nowa wersja systemu Android dla zegarków nosi nazwę WearOS 3 i jest przez Google reklamowana jako rewolucja na rynku smartwatchy. Na razie nie ma zbyt wielu modeli zegarków opartych o tą wersję systemu – obecnie jest to najnowszy Galaxy Watch od Samsunga oraz Pixel Watch od Google, jednak z czasem będzie się to w naturalny sposób zmieniać.

Przy okazji wprowadzania nowej wersji zegarkowego systemu na rynek, Google wywołało potężne zamieszanie twierdząc, że aplikacje napisane dla poprzedniej wersji systemu WearOS 2 nie będą kompatybilne z WearOS 3. W rzeczywistości tak nie jest – znakomita większość oprogramowania napisanego dla WearOS 2 działa bezproblemowo na WearOS 3. Trudno spodziewać się, żeby było inaczej skoro WearOS 3 to w istocie Android 11, a WearOS 2 to po prostu Android 9. Czym innym jednak są wymagania Google w przypadku aplikacji dla WearOS wydawanych w sklepie Google Play – tutaj rzeczywiście nastąpiły znaczące zmiany.

Wszelkie niekompatybilności programowe mogą wynikać jedynie z faktu, że nowsze wydanie WearOS jest oparte o wersję 11 Androida, zatem wszelkie mechanizmy znane z „dużej” wersji systemu są obecne i tutaj – w szczególności dotyczy to podsystemu uprawnień użytkownika do lokalizacji, zapisu danych na dysku, korzystania z aparatu, mikrofonu i bluetooth. Aplikacje korzystające z tych uprawnień podlegają takim samym ograniczeniom, jak aplikacje na telefonach i wymagają dostosowania.

W Google Play nastąpiła jedna istotna zmiana – aby wydać aplikację na zegarek w sklepie, musi ona być kompatybilna z WearOS 3, a konkretniej z wytycznymi Google dotyczącymi jakości określonymi dla tego systemu. Największą zmianą jest całkowita rezygnacja z poziomej obsługi kart na rzecz podejścia bardziej „telefonicznego” – ekrany aplikacji mają być przewijane pionowo. Dotychczas charakterystyczny dla WearOS layout poziomy oparty na gestach przesuwania w prawo i lewo jest według nowych wytycznych niemile widziany. To niekiedy implikuje konieczność wprowadzenia bardzo głębokich zmian w aplikacji.

O ile implementacja nowego systemu uprawnień z Androida 11 nie stanowi większej zmiany dla użytkownika – zegarek po prostu w odpowiednim momencie zadaje dodatkowe pytanie, czy użytkownik wyraża zgodę na daną czynność – o tyle często całkowita zmiana interfejsu użytkownika aplikacji wpływa na interakcję z aplikacją i doświadczenie z tego płynące. Pomijając koszy, które taka zmiana za sobą pociąga dla właścicieli aplikacji na WearOS, ma to szczególne znaczenie w przypadku aplikacji, które wykorzystywane są na co dzień i do których sposobu obsługi użytkownicy są przyzwyczajeni – całkowita zmiana sposobu używania aplikacji może spowodować jej porzucenie przez użytkownika. Dlatego planując rozwój swojej aplikacji na WearOS należy obecnie szczególną wagę przyłożyć do UX, zwłaszcza jeśli aplikacja była zaprojektowana zgodnie z dotychczasowym „flow” systemu wearOS.

Wsparcie Google Play dla deweloperów to fake

For the English translation please scroll the page down.


Dzisiejszy wpis będzie przeznaczony dla developerów i wydawców mających do czynienia z Google Play od strony „kuchni” – czyli konsoli Google Play. Wszyscy wiemy, że ostatnio dzieje się na tej platformie coś niedobrego, a relacje pomiędzy developerami, a Google Play są – delikatnie mówiąc – napięte. Trudno powiedzieć, czy to ze względu na braki kadrowe spowodowane pandemią, czy po prostu Google już tak urosło w pozycję monopolisty, że zaczęło ignorować podstawową zasadę jakichkolwiek relacji – wzajemny szacunek. Gorzej – zaczęło obrażać inteligencję partnerów.

Każdy deweloper wie jak trudne bywają relacje z Google Play. Ciągłe zmiany regulaminu, brak informacji z wyprzedzeniem o konieczności zmian, usuwanie aplikacji ze sklepu bez ostrzeżenia i dania możliwości dostosowania się do wymagań. Systemowy, instytucjonalny i intencjonalny brak jakiejkolwiek realnej drogi odwoławczej. I wieczne próby nieudolnego udowadniania, że wszystko zawsze jest winą dewelopera, który nie przestrzega zasad Google Play. Wszyscy przyzwyczailiśmy się do takiego stanu rzeczy – abstrahując od tego na ile jest zasadne i dlaczego pozwalamy się w ten sposób traktować – jednak takiego popisu niekompetencji jaki Google Play dało nam ostatnio nie sposób pominąć milczeniem.

W każdej komunikacji z developerami, Google twierdzi, że za ich działaniami stoją specjaliści. Tak niestety nie jest, a znakomitą większość korespondencji załatwia automat – nikt w Google nie czyta korespondencji, o czym jesteśmy przekonani. Ale na potrzeby opisu poniższej sytuacji przyjmijmy, że, zgodnie z treścią, jaką przekazuje Google w swoich komunikatach, za tym rzeczywiście stoi człowiek. A więc, jeśli tak jest drogie Google, ludzie zatrudnieni przez was jako support Google Play są na tyle skrajnie niekompetentni, że… nie potrafią poprawnie przepisać hasła w pole logowania.

Otóż ostatnio publikowaliśmy w Google Play aplikację dla jednego z samorządów. Aplikacja jest w języku polskim, dystrybuowana tylko na Polskę i wymaga aktywacji za pomocą loginu użytkownika. Podaliśmy potrzebne loginy w konsoli Google Play, aby osoby przeprowadzające sprawdzanie aplikacji przed opublikowaniem mogły ją aktywować. Dwa dni później przychodzi e-mail od Supportu Google, że aplikacja została odrzucona, gdyż podane dane są niepoprawne i nie można aktywować aplikacji. Do e-maila dołączono zrzuty ekranu mające obrazować nieudane próby aktywacji aplikacji. Pierwsza myśl – musieliśmy pomylić się wpisując dane w konsoli Google Play. Sprawdzamy – dane są poprawne. Zatem o co chodzi? Szybka analiza przesłanych przez Google zrzutów ekranu ujawniła jedno – ani razu nie wpisano poprawnie podanych loginów! Jak można aktywować aplikację, jeśli nie wpisze się poprawnego hasła? I żeby te hasła były jakieś skomplikowane… Nie, najprostsze, typowe, testowe frazy, aby nie utrudniać życia ludziom testującym aplikację. Aby nie być gołosłownym loginy brzmiały „StudentTestowy”, „InstruktorTestowy” i „InstruktorTestowyPanel”. To co wpisywał „recenzent” Google w pole logowania możecie zobaczyć na załączonych screenach – wielkie i małe litery nie miały dla niego jakiegokolwiek znaczenia… I nasze absolutnie ulubione – automatycznie przetłumaczone polskie słowo „Instruktor” na angielskie „instructor”. Hasło z pomylonymi wielkimi i małymi literami oraz z frazami przetłumaczonymi automatycznie na inny język, co zmienia w nich znaki, nie działa? To wina dewelopera! Serio? Drogie Google, powodzenia w udowadnianiu nam, że tą „recenzję” robił człowiek.

No cóż – uśmialiśmy się i skorzystaliśmy z możliwości odwołania – teoretycznie istnieje taka możliwość. Napisaliśmy grzecznie, że dane podane w konsoli Google Play są poprawne, proszę je po prostu dokładnie przepisać. Podczas wysyłania formularza odwołania jest komunikat: „Twoją sprawą zajmie się specjalista, ale musisz być cierpliwy, bo jest pandemia i nie wyrabiamy z ilością zgłoszeń”. Odpowiedź na owe odwołanie nawet nas nie zdziwiła. Cytujemy „Jak będziesz gotowy podać nam poprawne dane logowania, to to zrób”. No przecież właśnie Wam napisaliśmy, że podaliśmy poprawne dane…

Aby nie przedłużać – aplikacji w Google Play nie sprawdzają ludzie i nikt w Google nie czyta ewentualnych odwołań. Automat na podstawie powodu odrzucenia aplikacji wysyła predefiniowaną odpowiedź. Krótko rzecz ujmując, jakikolwiek support Google Play to fake.

Oczywiście możemy uznać, że nasze aplikacje są z punktu widzenia Google bezwartościowe – są bezpłatne, nie pokazują setek reklam i nie mają zakupów w aplikacji – z punktu widzenia Google Play nie przynoszą zatem zysków. Aplikacja samorządowa, opłacona z pieniędzy podatników, nie dokłada się bezpośrednio do wyniku finansowego platformy Google – to jest bezsporne. Niemniej jednak nie możemy przyjąć braku elementarnego poszanowania dla inteligencji partnerów. Tak drogie Google – developer mający dostęp do konsoli Google Play to Wasz partner, wspierający platformę swoją pracą i innowacyjnością. Chyba o tym całkowicie zapomnieliście.


Today’s post will be for developers and publishers dealing with Google Play from the „behind the scenes” – which is the Google Play console. We all know that recently something bad is happening on this platform, and the relationships between developers and Google Play is – to put it mildly – tense. It’s hard to say whether this is due to staff shortages caused by the pandemic, or simply Google has grown so much in the position of a monopolist that it began to ignore the basic principle of any relationship – mutual respect. Worse – it began to insult the intelligence of its partners.

Every developer knows how difficult the relationship with Google Play can be. Constant changes to the rules, no information in advance about the need for changes, removal of applications from the store without warning and giving the opportunity to adapt to the requirements. Systemic, institutional and intentional lack of any real way to appeal. And eternal attempts to ineptly prove that everything is always the fault of the developer who does not follow Google Play rules. We’ve all become accustomed to this state of affairs – regardless of how justified it is and why we allow ourselves to be treated this way – but the display of incompetence that Google Play has recently given us cannot be passed over in silence.

In every communication with developers, Google claims to have specialists behind their actions. Unfortunately, this is not the case, and the vast majority of correspondence is handled by an automaton – no one at Google reads correspondence, which we are convinced of. But for the purpose of describing the following situation, let’s assume that, according to the content Google communicates in its messages, there is indeed a human behind this. So, if this is the case dear Google, the people you employ as Google Play support are so extremely incompetent that…. can’t rewrite the password correctly into the login field.

Well, recently we published in Google Play an application for one of the local governments. The application is in Polish language, distributed only in Poland and requires activation with user login. We have provided the necessary logins in the Google Play console, so that people checking the application before publication could activate it. Two days later, we receive an email from Google Support saying that the application has been rejected because the data provided is incorrect and the application cannot be activated. The email is accompanied by screenshots supposed to illustrate the failed attempts to activate the app. The first thought – we must have made a mistake when entering the data in the Google Play console. We check – the data are correct. So what is it all about? A quick analysis of screenshots sent by Google revealed one thing – not once were the logins entered correctly! How can you activate the application if you do not enter the correct password? And if these passwords were somehow complicated… No, the simplest, typical, test phrases, so as not to make life difficult for people testing the application. To avoid being lip service, the logins were „StudentTestowy”, „InstruktorTestowy” and „InstruktorTestowyPanel”. You can see what the Google „reviewer” typed into the login field on the attached screenshots – uppercase and lowercase letters had no meaning for him… And our absolute favorite – automatically translated Polish word „Instruktor” into English „instructor”. Password with mixed up uppercase and lowercase letters and phrases automatically translated into another language, which changes characters in them, does not work? That’s the developer’s fault! Really? Dear Google, good luck proving to us that this „review” was done by a human.

Well – we laughed and took the opportunity to appeal – theoretically there is such a possibility. We wrote politely that the data given in the Google Play console is correct, please just transcribe it exactly. When sending the cancellation form there is a message: „Your case will be handled by a specialist, but you must be patient, because there is a pandemic and we can’t keep up with the number of requests”. The response to this appeal did not even surprise us. We quote „When you are ready to provide us with correct login details, please do so”. Well, we just wrote you that we gave you the correct data…

Conclusion – applications in Google Play are not checked by people and nobody in Google reads any appeals. Based on the reason for application rejection, the automaton sends a predefined response. In short, any Google Play support is fake.

Of course, we can consider our apps worthless from Google’s point of view – they are free, don’t show hundreds of ads and don’t have in-app purchases – so from Google Play’s point of view, they are not profitable. The local government app, paid for with taxpayers' money, does not contribute directly to the bottom line of Google’s platform – this is indisputable. Nevertheless, we cannot accept the lack of elementary respect for the intelligence of partners. Yes dear Google – a developer who has access to the Google Play console is your partner, supporting the platform with their work and innovation. You seem to have completely forgotten this.

Android 12 - zmiany kosmetyczne

Nowy Android został właśnie zaprezentowany – tym razem o numerze 12 i oznaczeniu kodowym Q. Jak co roku przyglądamy się becie, aby sprawdzić na co należy być przygotowanym i czy w ogóle trzeba coś robić, jeśli macie aplikacje na Androida opublikowane na platformie Google Play, czy też w innym sklepie. Ostateczna wersja systemu będzie dostępna jesienią i wówczas ewentualne zmiany zostaną wprowadzone w konsoli Google Play. Posiadacze aplikacji opublikowanych w HUAWEI AppGallery nie muszą się specjalnie zastanawiać, gdyż ta platforma jest oparta o AOSP (Android Open Source Project) i jako taka nie podlega zmianom i wymaganiom wprowadzanym przez Google w usługach i serwisach tej firmy.

Wydawcy mogą odetchnąć – nowa aktualizacja Androida nie wnosi praktycznie żadnych zmian w kwestiach kompatybilności. Ogólnie zmiany w systemie należą do kategorii kosmetycznych i optymalizacyjnych – znaczne korekty w wyglądzie, nowy wygląd powiadomień, zmiany estetyczne typu dopasowywanie koloru wyróżnień do koloru tapety, uporządkowanie belki systemowej, porządki w szufladce ustawień itp.

Mając aplikację na Androida zawsze jednak trzeba zwracać uwagę na tzw. target, czyli wersję API, na którym aplikacja jest oparta. Obecnie aby opublikować aplikację lub wydać aktualizację w Google Play wymagany jest target 30, czyli aplikacja musi być dostosowana do Androida 11. Nowa wersja Androida ma target 31, jednak nie zmienia wymagań targetu minimalnego – nadal jest to 30. Od przyszłego roku będzie to jednak target 31. Nie dostrzegliśmy pomiędzy targetami jakichkolwiek niekompatybilności, zatem jeśli wasza aplikacja jest targetowana numerem 30 to raczej nie musicie się niczym martwić, a jeśli macie aplikację targetowaną niższym API i tak musicie ją dostosować do targetu 31 jeśli chcecie opublikować aktualizację.

Android 11 beta - co nowego

Nowy rok, nowy Android – tym razem o numerze 11 i oznaczeniu kodowym R. Jak zawsze przyglądamy się wersji beta, aby sprawdzić na co należy być przygotowanym i czy w ogóle trzeba coś robić, jeśli ma się aplikacje na Androida opublikowane na platformie Google Play. Ostateczna publiczna wersja systemu będzie dostępna jesienią i wówczas ewentualne zmiany zostaną wprowadzone w konsoli Google Play. Posiadacze aplikacji opublikowanych w HUAWEI AppGallery nie muszą się specjalnie zastanawiać, gdyż ta platforma jest oparta o AOSP (Android Open Source Project) i jako taka nie podlega zmianom i wymaganiom wprowadzanym przez Google w usługach i serwisach tej firmy.

Największe zmiany w systemie w wersji 11 dotyczą opcji prywatności i uzyskiwania uprawnień od użytkownika. Lista tzw. uprawnień wrażliwych, na której dotychczas były telefon, SMS i czujniki związane z kondycją fizyczną i zdrowiem użytkownika, została rozszerzona o uprawnienia do lokalizacji w tle. To oznacza, że na lokalizację w tle trzeba uzyskać dodatkowe pozwolenie od użytkownika. Użytkownicy mogą teraz taże w dowolnej chwili przyznać lub cofnąć konkretne uprawnienie dla poszczególnych aplikacji. Jeśli zatem wasza aplikacja korzysta z lokalizacji w tle lub kilku odrębnych uprawnień, warto pamiętać aby przygotować ją na możliwość wycofania dowolnego uprawnienia w każdej chwili (dodać obsługę zmiany uprawnienia w każdym momencie, jeśli w kodzie aplikacji nie jest to obsługiwane – co wciąż się zdarza zwłaszcza w kodzie, który został przygotowany dla wcześniejszych wersji Androida i nie był od dłuższego czasu aktualizowany).
Pozostałe zmiany należą do kategorii kosmetycznych i optymalizacyjnych – drobne korekty w wyglądzie (niewielkie), uporządkowanie belki systemowej, porządki w szufladce ustawień, estetyczne poprawki w powiadomieniach itp.

Mając aplikację na Androida zawsze trzeba zwracać uwagę na tzw. target, czyli wersję API, na którym aplikacja jest oparta. Obecnie aby opublikować aplikację lub wydać aktualizację w Google Play wymagany jest target 29, czyli aplikacja musi być dostosowana do Androida 10. Nowa wersja Androida ma target 30, jednak nie zmienia wymagań targetu minimalnego – nadal jest to 29. Nie dostrzegliśmy także innych niekompatybilności, zatem jeśli wasza aplikacja jest targetowana numerem 29 to raczej nie musicie się niczym martwić, a jeśli macie aplikację targetowaną niższym API i tak musicie ją dostosować do targetu 29 jeśli chcecie opublikować aktualizację. Biorąc jednak pod uwagę kolejne zmiany wprowadzane w opcjach prywatności systemu w wersji 11 spodziewamy się, że z czasem pojawią się nowe wymagania. Trudno na etapie dość wczesnej jeszcze wersji beta systemu stwierdzić, czy będą wymagane zmiany w samych aplikacjach, tak jak miało to miejsce przed rokiem przy okazji przejścia na Androida 10, czy też może raczej zmiany będą dotyczyły tylko konsoli Google Play, niemniej jednak jeśli jesteście właścicielami konta w Google Play warto zachowywać czujność w tej kwestii i śledzić kolejne informacje publikowane przez Google.

 

Wsparcie z FOSA

„Wsparcie w Gdańsku!” to pierwsza tego typu aplikacja w Polsce – nie tylko z nazwy, ale i realnie funkcjonująca na rzecz wsparcia osób z zaburzeniami psychicznymi. Realnie, gdyż po drugiej stronie ekranu smartfonów z Androidem, na których działa ten program, stoją realni ludzie – specjaliści z fundacji FOSA, od wielu lat zajmujący się pracą z osobami doświadczającymi kryzysów i trudności natury psychicznej. Skrót FOSA rozwija się jako Fundacja Oparcia Społecznego Aleksandry, a możliwość uczestniczenia w projekcie finansowanym przez Miasto Gdańsk, mającym na celu zapewnić realną pomoc mieszkańcom miasta borykającym się z problemami natury psychicznej, była dla nas i prawdziwą radością i jednocześnie ciekawą przygodą.

Samo projektowanie aplikacji od strony czysto programistycznej niczym nie różniło się oczywiście od programowania innych aplikacji – lubimy swoją pracę więc zawsze wykonujemy ją z pełnym zaangażowaniem – jednak od strony merytorycznej to już zupełnie inna historia. Fascynujące było obserwowanie jak bardzo zwykły program na Androida, w rękach doświadczonych psychologów, z narzędzia po prostu pomocnego i praktycznego – realizującego swoje funkcje – potrafi zmienić się w narzędzie przyjazne – narzędzie komunikujące się z użytkownikiem językiem dostosowanym do potrzeb grupy użytkowników, do której jest kierowane. Dotychczas z profesjonalnej pomocy w układaniu komunikatów, czy projektowaniu komunikacji wizualnej korzystaliśmy głównie podczas projektowania aplikacji dla dzieci, co wydaje się oczywiste. Tym razem mieliśmy okazję przyjrzeć się podobnej pracy wykonywanej podczas projektowania aplikacji przeznaczonej głównie dla dorosłego odbiorcy. Zaskakujące jak bardzo standardowe alerty, czy komunikaty, do których wszyscy jesteśmy przyzwyczajeni w oprogramowaniu wszelkiego typu, mogą różnić się, gdy są ściśle kierowane do określonej grupy ludzi. Wychodzi na to, że słowa mają znaczenie.

 

 

Dziś mamy dla was zapowiedź naszej nowej gry na urządzenia mobilne. Ta platformowa przygodówka opowiadająca o perypetiach pewnego nastolatka to jedna z naszych większych produkcji. Szczegółów fabuły nie zdradzimy. Gra będzie dostępna bezpłatnie dla urządzeń z Androidem. Obecnie produkcja wchodzi w ostatnią fazę, zatem premiery spodziewajcie się w ciągu kilku tygodni – śledźcie Google Play. Na dobry początek mamy dla was trailer.

Android 8 został oficjalnie udostępniony.

Android 8 został oficjalnie udostępniony. Wszystkich wydawców aplikacji na system Android spieszymy uspokoić – jeśli wasza aplikacja uruchamia się i działa prawidłowo na Androidzie 5 Lollipop i 6 Marshmallow nie musicie nic robić. Nie odnotowaliśmy żadnych problemów z kompatybilnością na nowym wydaniu. Zapewne jest to spowodowane tym, że nowa wersja Androida nie wnosi bardziej istotnych zmian. Jest to raczej zestaw usprawnień i kilku nowych funkcji ułatwiających obsługę systemu. Co zatem nowego?

Picture in picture
Kolejna po podzielonym ekranie forma multitaskingu trafiająca na Androida. Wideo można zminimalizować do rozmiaru małego pływającego okienka i oglądać korzystając jednocześnie z innej aplikacji. Przydatna funkcja zwłaszcza na większych ekranach.

Szpilki powiadomień
Funkcja znana z iOS trafia na Androida. Jeśli wewnątrz aplikacji pojawia się jakieś powiadomienie, np. Przyjdzie nowy e-mail, przy ikonie tego programu pojawia się czerwona kropka. Jeśli teraz przytrzymamy dłużej ikonę palcem rozwinie się dymek z podglądem powiadomienia.

I to… właściwie wszystko z rzeczy zauważalnych łatwo dla użytkownika. Jest też sporo ulepszeń wewnątrz samego systemu, takich jak autouzupełnianie haseł i loginów w aplikacjach, poprawione zaznaczanie i kopiowanie tekstu, usprawnienia optymalizacji systemu, czy nowe zestawy emotikon. Nie są to jednak zmiany rewolucyjne. Android 8 to nadal ten sam Android, który niewiele się zmienił od czasu swojego 5 wydania.

Zagraj w mobilną reklamę na Androidzie

Konferencja Game Developers Conference w San Francisco przyniosła ciekawe nowości zaprezentowane przez Google. Nowe narzędzia dla Androida pozwalają m.in. na tworzenie reklam mobilnych w postaci… niewielkich gier. Nie jest to nowy pomysł. Z grywalnymi formami reklamy eksperymentowały już firmy streamingujące aplikacje, niemniej jednak pd egidą Google pomysł może wypłynąć na szersze wody, gdyż ta firma ma potężne zaplecze w postaci systemu Android i sieci reklamowych AdWords i AdMob.

Nowy format reklamowy pojawi się w ciągu najbliższych miesięcy. Rozszerzony zostanie także znany z gier system nagradzania użytkowników wirtualnymi trofeami – w tym wypadku trofeum przyznawane będzie de facto za oglądniecie reklamy. Z platformy AdWords system trafi następnie do AdMob i będzie dostępny przez kampanie uniwersalne.

Zapewne jednym z pierwszych odbiorców nowej formy reklamy będą firmy i instytucje promujące swoje produkty i usługi za pomocą gier. Problemem dzisiejszych gier mobilnych pozostaje bowiem mały współczynnik ich otwierania po pobraniu – użytkownicy ściągają grę do telefonu, a następnie w nią nie grają. Grywalne reklamy dają szansę na wciągnięcie odbiorcy w rozgrywkę już na etapie promocji, zachęcając do otwarcia aplikacji po jej zainstalowaniu.

Kolejną nowością jest narzędzie umożliwiające dostosowanie reklamy wideo do orientacji w jakiej trzymany jest telefon. Obecnie reklamy wideo w aplikacjach wyświetlane są w ustalonej pozycji. Gdy użytkownikowi grającemu w grę w orientacji pionowej owa gra wyświetla reklamę poziomą istnieje duże prawdopodobieństwo, że graczowi nie będzie się chciało obrócić telefonu, aby lepiej zobaczyć, co jest na ekranie i po prostu reklamę przeczeka. Google zamierza problem rozwiązać automatycznie tworząc różne wersje reklamy w różnych orientacjach, na podstawie najważniejszych zawartych w niej obiektów. W testach, współczynnik klikalności reklam dostosowanych do aktualnej orientacji ekranu okazał się 20% wyższy, niż w przypadku reklam niedostosowanych.

Ostatnią nowością z San Francisco są przebudowane narzędzia analityczne Firebase Analitycs (platforma analityki aplikacji mobilnych) umożliwiające śledzenie zaangażowania użytkowników. Pakiet będzie także dostępny w postaci SDK C++ oraz dla silnika gier Unity. Rozbudowane narzędzia pozwalają na śledzenie konkretnych zachowań użytkowników – czasu spędzonego w grze, ukończeń poziomów, ścieżek poruszania po menu etc.

Android Pay w Polsce

Polska to drugi kraj w Europie, w którym można oferować klientom płatności za pomocą Android Pay – usługi, która umożliwia użytkownikowi płacenie za zakupy smartfonem w sklepach i Internecie. Dotychczas Android Pay w Europie było oferowane jedynie w Wielkiej Brytanii. Informacja ta ma niebagatelne znaczenie podczas planowania aplikacji e-commerce dla systemu Android. Głównym warunkiem wykorzystania usługi jest bowiem posiadanie urządzenia mobilnego z systemem Android w wersji co najmniej 4.4 oraz obsługą NFC. Dzięki temu usługa współpracuje z każdym terminalem płatności zbliżeniowych. Obecnie Android Pay obsługiwane jest przez trzy polskie banki: Alior Bank, BZWBK oraz Usługi Bankowe T-Mobile.

Korzystanie z Android Pay przez użytkownika końcowego jest równie proste, co wyciągnięcie z portfela karty zbliżeniowej i dotknięcie nią terminalu. Po wymaganym wybudzeniu i odblokowaniu telefon rejestruje dokonywaną płatność. Wpisywanie kodu PIN przy transakcjach powyżej 50 złotych odbywa się na ekranie urządzenia. Robienie zakupów w aplikacjach e-commerce współpracujących z Android Pay jest jeszcze prostsze – wystarczy kliknąć przycisk pozwalający dokonać zakupu i… to wszystko. Jeśli użytkownik ma skonfigurowany Android Pay w telefonie, nie jest wymagana od niego żadna dodatkowa akcja.