protego-safe / android

Aplikacja Android

STOP COVID - ProteGO Safe Android app

Project overview

This is an Android application for STOP COVID - ProteGO Safe project and it implements two main features:

• User daily triage - //TODO description to be provided or linked to main documentation//
• Contact tracing - module that is fully based on Exposure Notification API provided by Google and Apple and it's goal is to inform people of potential exposure to COVID-19

Application is structured based on Clean Architecture pattern and Presentation (UI) layer is almost fully realized with a single Fragment (HomeFragment) with a WebView control that loads a website application called 'PWA'. PWA is responsible for GUI, user interaction and 'User daily triage' feature. A website app interacts with a native code through the JavaScript bridge and is described widely here. Native application business logic is implemented in a HomeViewModel and it decides what kind of UseCase should be executed based on application state. UseCases are defined in a Domain layer and they call methods from proper repository. Repositories implementations are either in a Data module (responsible for everything that is data related - storing, fetching or manipulation) or Device module (device specific APIs not directly related to data).

App implements contact tracing module that is based on ExposureNotification API (EN) and we can extract couple of features related to this:

• Controlling EN: start, stop, check if device supports it, check what is its state
• Uploading Temporary Exposure Keys (TEKs) of positively diagnosed user verified by the application: authorize user for TEKs upload, get TEKs from EN, add proper verification data (using SafetyNet API), upload data to the Cloud Server.
• Downloading periodically files with batch of TEKs of positively diagnosed users (that recently uploaded their TEKs): execute periodic task responsible for downloading recently created .zip files (it fetches list of available files from CDN, selects only not yet analyzed files and downloads only these ones)
• Providing files to EN API for detecting exposures: get proper configuration for risk calculation (Exposure Configuration), fire EN API with list of downloaded files and configuration, delete analyzed files
• Receiving information about detected exposures: register broadcast receiver about exposures, get information about exposures, store part of information (day of exposure, risk score and duration that is in 5 minutes intervals but max 30 minutes)
• Reporting risk level to the PWA: extract risk scores of saved exposures and calculate risk level, pass risk level to PWA
• Removing historical data: remove information about exposures older than 14 days

Project structure

This is multi-module Android Studio Project. It can be compiled with gradle commands, or from Android Studio user interface.

Project modules

• app - all the classes related to the Android UI such as view models, adapters, views, dependency injection
• domain - in this module we place all objects that will interact with other layers
• data - contains everything related to data persistence and manipulation
• device - has everything related to Android that’s not data persistence and UI

Build Variants

Application has 3 flavours matching environments: Prod, Stage, and Dev.

Flavours have different:

• Firebase configurations
• URL for PWA

There are two build types: release, and debug.

Setup of the app

To get started on the app, setup and configure the following:

1. ./gradle.properties

2. Firebase - google-services.json

Config parameters in gradle.properties

Name	Description
STAGING_GET_ACCESS_TOKEN_ENDPOINT	Endpoint for HTTPS call to validate PIN and get proper access token for TEKs upload (development type of application)
STAGING_UPLOAD_BUCKET_ENDPOINT	Endpoint for HTTPS call to upload TEKs (development type of application)
STAGING_STORAGE_BUCKET_ENDPOINT	Endpoint for CDN with Diagnosis Keys (development type of application)
STAGING_SAFETYNET_API_KEY	SafetyNet device attestation API Key (development type of application)
PRODUCTION_GET_ACCESS_TOKEN_ENDPOINT	Endpoint for HTTPS call to validate PIN and get proper access token for TEKs upload (production type of application)
PRODUCTION_UPLOAD_BUCKET_ENDPOINT	Endpoint for HTTPS call to upload TEKs (production type of application)
PRODUCTION_STORAGE_BUCKET_ENDPOINT	Endpoint for CDN with Diagnosis Keys (production type of application)
PRODUCTION_SAFETYNET_API_KEY	SafetyNet device attestation API Key (production type of application)
SHARED_PREFERENCES_FILE_NAME	File name for Shared Preferences storage

Firebase and google-services.json

Setup Firebase for the different environment. Download the google-services.json for each of environment and put into proper directory:

Prod: ./app/src/prod/google-services.json

Stage: ./app/src/stage/google-services.json

Dev: ./app/src/dev/google-services.json

---

ChangeLog

4.13.0

• Added handling deep links
• Added handling redirect to sms application
• Updated UI

4.12.0

• Disabled SafetyNet token check for lab test
• Updated UI

4.11.0

• Updated UI

4.10.1

• Fix missing districts

4.10.0

• Added new file storage method
• Split current JSON data to multiple smaller data files to prevent over downloading unwanted data
• Enhanced view of the app home screen, which now includes more detailed statistics on vaccination and infections
• New screen with detailed statistics and graphs on vaccination (number of people vaccinated, doses, adverse reactions) and infections (number of people infected, recovered, deaths, causes of death and tests)
• Added information on vaccination and registration rules with redirection to registration, vaccination request and helpline
• Fixed bug that occurred on Xiaomi phones with dark mode enabled
• Bump EN version to 1.8.3

4.9.1

• Added information on vaccination statistics in Poland
• Updated UI

4.9.0

• Added information on COVID-19 statistics in Poland
• Added information about the checks carried out by the application on meetings with people who reported to have got sick with COVID-19
• Added history of application activity (information about performed checks, indicated threats, system notifications)
• Added possibility of redirecting to a specific application screen by system notification
• Added possibility to evaluate applications in the Google Play / Apple App Store
• Added translations of the application into Russian, German and Turkish.
• Updated UI

4.8.0

• Possibility to share Temporary Exposure Keys with other countries
• Updated UI

4.7.1

• Fixed back button handling
• Updated translations
• Possibility to cancel exposure risk on UI request
• Updated UI

4.7.0

• Possibility to generate Covid Test Subscription when Exposure Notification returns HIGH RISK
• Added cache for UI requests when error should be handled by native
• Updated UI

4.6.0

• Added list of current color zones for poviats.
• Possibility of monitoring selected poviats - notification in case of a change in the color of the zone.
• Updated screen that informs about the possibility to add a translation into a new language.
• Updated UI

4.5.0

• Added closing app on UI request
• Upgraded gradle and gradle dependencies
• Added response "ACCESS_DENIED" code(5) when user denied sharing TEKs
• Updated UI

4.4.0

• Added translations for English and Ukrainian languages
• Updated UI

4.3.1

• Updated UI

4.3.0

• Updated app name
• Updated UI
• Added validation of Temporary Exposure Keys before upload
• Getting and setting application language/locale (not supported by UI yet)

4.2.4

• Updated GIS recommendations

4.2.3

• Updated PWA
• Passed app version to PWA
• Updated certification pinning

4.2.2

• Updated PWA

4.2.1

• Increased connection timeouts
• Handled upload errors
• Updated PWA

4.2.0

• PWA GUI migrated to offline version (local assets)
• Migration of PWA data from previous versions added
• Improved device verification check (missing Google Play services handled properly)
• Risk level thresholds added as configuration
• VPN connection problem fixed (still valid for keys upload)
• Improved download files process (omitting not existing files)

4.1.1

• Security fixes added:
  • Migration of Firebase Cloud Functions to HTTP calls
  • Certificate pinning for HTTP calls and PWA application
  • Preventing app screen recording/taking screenshots
  • Warning about rooted devices displayed on first app launch
  • In-app updates added
• Config changes

4.1.0

• Exposure Notification API added
• OpenTrace module fully removed together with all collected data
• New types of communication with PWA via JS Bridge

3.0.3

• Fixed wrong condition for battery optimization check for Android 5
• SafetyNet check disabled

3.0.2

• Improved Bluetooth module operation
• Added support for deleting all data collected by Bluetooth module

3.0.1

• Added OpenTrace module for collecting BLE contacts

2.0.1

• Basic version with PWA, and notifications

android's Issues

Na oknie startowym (splash) pokazujemy logo Ministerstwa Cyfryzacji

Brak scrollowania na ekranie dashboard'u - ucięta treść

Opis błędu

Nie ma możliwości przescrollowania treści okna głównego (.ui.main.DashboardActivity) co powoduje ucinanie jego treści.

Kroki

1. Otwórz aplikację
2. Zaloguj się, potwierdzając numer telefonu, jeśli tego nie zrobiłeś wcześniej
3. Przejdź na ekran statusu (dashboard) aplikacji

Oczekiwany zachowanie aplikacji

Aplikacja w oknie .ui.main.DashboardActivity powinna umożliwiać na telefonach z mniejszym wyświetlaczem scrollowanie do treści wychodzących poza okno, aby móc odczytać wszystkie informacje na nim prezentowane.

Zrzut ekranu

Urządzenie (proszę wypełnij poniższe informacje dotyczące urządzenia):

• Nazwa: telefon Sony Xperia XZ1 Compact (G8441)
• System operacyjny: Android
• Wersja systemu operacyjnego: Android 9
• Wersja aplikacji 0.0.1-stg (obecny master)

Środowisko

• Wersja środowiska: stg

Brak walidacji poprawności kodu SMS

Opis błędu

Przycisk potwierdzenia kodu SMS jest niezablokowany jeżeli nie wpisze się 6 cyfr. Można potwierdzić niepoprawny kod SMS (kod SMS o niepoprawnym formacie).

Kroki

1. Wpisz nr telefonu
2. Przejdź do ekranu z kodem SMS
3. Wpisz niepoprawny format kodu SMS (mniej lub więcej niż 6 cyfr)
4. Potwierdź kod SMS

Oczekiwany zachowanie aplikacji

1. Walidacja poprawności kodu SMS powinna działać
2. Przycisk potwierdzenia kodu SMS powinien być zablokowany przy wpisanym niepoprawnym kodzie SMS (niepoprawny format)

Urządzenie (proszę wypełnij poniższe informacje dotyczące urządzenia):

• Nazwa: Samsung Galaxy S6
• System operacyjny: Android
• Wersja systemu operacyjnego: 7.0
• Wersja aplikacji ProteGO Stg 1.0.10-stg

Środowisko

• Wersja środowiska: stag

Aplikacja działa w tle

Aplikacja działa w tle i na bieżąco zapisuje informacje o wykrytych urządzeniach. Zapisy starsze niż 2 tygodnie są na bieżąco kasowane. W przypadku jeśli aplikacja zostanie wyłączona podejmuje próbę włączenia się ponownie.

Aplikacja jest dostępna dla osób z niepełnosprawnościami

TBD

Automatyczne wpisywanie kodu z SMS

Opis prozypozycji rozwiązania

Kiedy pojawia się pole wpisywania kodu do rejestracji, aplikacja powinna nasłuchiwać przychodzących wiadomości SMS. Po otrzymaniu kodu aplikacja powinna automatycznie rejestrować użytkownika.

Opis alternatywnych rozwiązań

Użytkownik powinien mieć zawsze możliwość wpisania kodu ręcznie.

Link w README nie działa

W readme jest niedziałający link: https://github.com/orgs/ProteGO-app/projects/1

Brak walidacji długości kodu SMS

Opis błędu

Użytkownik może potwierdzić kod o niepoprawnej długości (6 znaków).

Oczekiwany zachowanie aplikacji

Przycisk potwierdzenia wysłania kodu “PRZEŚLIJ DO” powinien być wyłączony do momentu wpisania poprawnej długości kodu.

Urządzenie (proszę wypełnij poniższe informacje dotyczące urządzenia):

• Nazwa: Samsung Galaxy S8
• System operacyjny: Android
• Wersja aplikacji: 0.0.3-stg

Środowisko

• Wersja środowiska: stg

Aplikacja sprawdza wersję i ew. prosi o aktualizację

Po uruchomieniu, aplikacja sprawdza czy zainstalowana wersja jest najnowsza i w przeciwnym wypadku Użytkownik proszony jest o zainstalowanie nowszej wersji i przekierowany jest do odpowiedniego sklepu z aplikacjami.

Android Contact Tracing API - zmiana zakresu projektu

Apple i Google pracują nad systemem, który na pierwszy rzut oka w pełni pokrywa zakres projektu ProteGO. Rozważcie proszę, czy nie warto na ten moment wstrzymać się z budowaniem warstwy komunikacji i poczekać do maja, kiedy pierwsza wersja Android Contact Tracing API zostanie udostępniona.

Aplikacje tego typu mają sens wyłącznie wtedy, gdy są wykorzystywane na masową skalę. Wspomniane API zapewni Wam znacznie lepszą ekspozycję już teraz, a w przyszłości najprawdopodobniej będzie stałym elementem obu systemów operacyjnych.

Poza tym zwyczajnie dostarczy gotową abstrakcję i zdejmie z Was trochę roboty 🙂

Więcej informacji:

• https://blog.google/inside-google/company-announcements/apple-and-google-partner-covid-19-contact-tracing-technology

• https://blog.google/documents/55/Android_Contact_Tracing_API.pdf

• https://blog.google/documents/58/Contact_Tracing_-_Bluetooth_Specification_v1.1_RYGZbKW.pdf

• https://blog.google/documents/56/Contact_Tracing_-_Cryptography_Specification.pdf

• https://www.theverge.com/2020/4/10/21216715/apple-google-coronavirus-covid-19-contact-tracing-app-details-use

Statyczna weryfikacja zależności

Opis prozypozycji rozwiązania

Obecnie projekt korzysta z zależności pobieranych ad-hoc z zewnętrzych repozytoriów maven, bez sprawdzania sum kontrolnych co w skrajnych przypadkach może być luką bezpieczeństwa (patrz https://github.com/signalapp/gradle-witness#dependency-problems)
rozwiązaniem będzie użycie https://github.com/signalapp/gradle-witness w celu statycznej weryfikacji zależności

Użytkownik może otworzyć okno "O Aplikacji"

wg. projektu ProteGO-Safe/specs#10

Stworzenie gittera na potrzeby rozmowy o aplikacji.

Stworznie gittera jako najbardziej zintegrowanego z github'em, w celu rozmowy na temat aplikacji.
Plusem gittera jest to że nie trzeba go instalować, oraz można zalogować się loginem githuba.

Alternatywą mógłby byc slack albo inny komunikator.

Aplikacja przechowuje dane tylko przez 2 tygodnie

Na bieżąco kasujemy informacje o napotkanych urządzeniach starsze niż 2 tyg

Zmień ProteGo na ProteGO (wielkie "O") wszędzie

Aplikacja wyświetla powitanie

Pierwsze uruchomienie
W przypadku kiedy aplikacja uruchamiana jest po raz pierwszy (nie mamy user_id), następuje rejestracja aplikacji. Użytkownikowi pokazywane są ekrany startowe:

Powitanie w aplikacji
Akceptacja regulaminu. Regulamin jako link otwierany w przeglądarce.
Wyjaśnienie jak działa aplikacja (może być kilka ekranów)
Prośba o włączenie Bluetooth. Aplikacja nie przechodzi dalej bez włączenia Bluetooth (chyba że nie da się skutecznie sprawdzić stanu Bluetooth, wtedy przechodzi).

Aplikacja wykrywa brak internetu i nie włącza się

W przypadku braku dostępu do Internetu, aplikacja informuje o tym i nie pozwala przejść dalej.

Aplikacja powinna weryfikować certyfikat SSL serwera do którego się podłącza

"Kod weryfikujący: null" pojawia się w wersji prod 1.0.7

W wersji 1.0.7 prod podczas rejestracji na ekranie pojawia się notyfikacja "Kod weryfikujący: null".

W wersji prod nie powinno być żadnych tego typu notyfikacji.

Zmiana strategii powiadomień

Częste powiadomienie, które już sygnalizują użytkownicy w komentarzach (Google Play). Obecnie wszystkie powiadomienie, w tym te najważniejsze zawarte są w jednym kanale (dodatkowo opisanym po angielsku; w ogóle nie było polskiej nazwy dla polskiej aplikacji - pytanie retoryczne). Można utworzyć oddzielne kanały (kategorie dostępne w systemowych ustawieniach aplikacji) powiadomień skojarzone z "dzióbkami" w ustawieniach aplikacji. Te mniej ważne domyślnie o niskim priorytecie tak, aby nie wyłączać wszystkich celem świętego spokoju, włącznie z powiadomieniem o kontakcie z zarażonym!

Aplikacja powinna działać na możliwie niskiej wersji androida

Aplikacja powinna być powszechnie dostępna, także na stare urządzenia.
Udało mi się skompilować na minSdkVersion 21 a chciałbym od 17 bo takie mam urządzenie HTC ONE X+
Niżej w tej chwili się nie da - ograniczeniem jest com.polidea.cockpit:cockpit:3.1.2

Adres do API powinien być w postaci CNAME z domeny gov.pl wskazujący na GCP endpoint

Obrazki na onboardingu są rozciągnięte

Na pierwszym ekranie jaki widzi użytkownik obrazki są rozciągnięte, widać to zwłaszcza w landscape.
Rozwiązaniem problemu mogłoby być przygotowanie osobno zielonego tła oraz obrazka z osobą. Tło chyba jest już gotowe, nawet w formie wektorowej (użyte na splash screenie), wiec pozostaje sylwetka osoby.

"Nie korzystamy w żaden sposób z GPS i aplikacja nie wie gdzie jesteś lub byłeś."

Aplikacja głosi co w tytule, a posiada uprawnienia do dokładnej lokalizacji. Do BLE wystarczy "ACCESS_COARSE_LOCATION". Bodajże jest też to niezgodne z regulaminem Google Play - aplikacja nie może posiadać uprawnień do funkcji, z których nie korzysta.

Aplikacja pokazuje aktualny status Użytkownika

Aplikacja odpytuje serwer i pokazuje Użytkownikowi jeden z trzech statusów:

• czerwony
• pomarańczowy
• zielony

Przycisk "prześlij kod" jest cały czas nie aktywny

Opis błędu

Kiedy włączam aplikacje po raz pierwszy, to na ekranie wpisania numeru telefonu przycisk jest nie aktywny.
Nie aktywuje się nawet po wpisaniu prawidłowego numeru

Kroki

1. Odpalamy poraz pierwszy aplikacje
2. Przechodzimy przez 4 ekrany powiatalne
3. Jesteśmy na 5 ekranie gdzie wpisujemy swój numer telefonu
4. Przycisk prześlij kod jest nie aktywny.

Oczekiwany zachowanie aplikacji

Przycisk "prześlij kod powinen być aktywny", żeby przejść do następnego etapu rejestracji.

Zrzut ekranu

Urządzenie (proszę wypełnij poniższe informacje dotyczące urządzenia):

• Nazwa: LG G7
• System operacyjny: Android
• Wersja systemu operacyjnego: Android 9, lineage os 16
• Wersja aplikacji: 0.0.1-dev
  commit 5c66af8 (HEAD -> master, origin/master, origin/HEAD)
  Author: mzgreen [email protected]
  Date: Sun Apr 5 15:32:58 2020 +0200

Środowisko

• Wersja środowiska: dev

Dodatkowe informacje

Wygląda na to że w pliku registration_view.xml w lini 93 jest na sztywno ustawione:
android:enabled="false" dla elementu o id register_button.

Spodziewałem się że ten status powinen się zmienić po poprawnej walidacji, ale nie znalazłem kodu który miałby za to odpowiadać.

Przeniesienie logiki sprawdzania dostępności internetu do BaseViewModel

Zadanie wyniesione z tego komentarza: #55 (comment)
do tego PR: #55

Użytkownik rejestruje się w aplikacji (happy path)

Prośba o podanie numeru telefonu. Na stałe umieszczony jest przedrostek +48.
Po potwierdzeniu, użytkownik otrzymuje wiadomość SMS na podany numer i wpisuje 6-cyfrowy kod z wiadomości.

Aplikacja pokazuje pomarańczowy status Użytkownika

Aplikacja odpytuje serwer i pokazuje Użytkownikowi pomarańczowy status

Brak mozliwosci dodania zagranicznego numeru telefonu

Na ekranie powitalnym istnieje tylko mozliwosc dodania polskiego numeru z prefiksem +48. Czy na razie zagraniczne numery nie sa mozliwe ?

Użytkownik wpisuje kod który dostał od GIS podczas wysyłki historii spotkań

Ze względu na to, że numer telefonu nie będzie obowiązkowy (ProteGO-Safe/specs#34 (comment)) użytkownicy będą proszeni o podanie jakiegoś tekstowego identyfikatora (TBD) przed wysłaniem historii spotkań (encounters). Identyfikator będzie wysyłany na serwer, wraz z historią i tam weryfikowany.

Stare wersje zależności

Projekt używa np. Gradle 5.4.1 sprzed prawie roku, po którym wyszło kilkanaście stabilnych wersji.
Android Gradle plugin jest sprzed paru miesięcy.

Jest jakaś polityka, wymaganie biznesowe albo jakaś inna zależność która wymusza określone wersje bibliotek? Czy można śmiało zakładać PR z podbiciem wersji do nowszych stabilnych? Wolę się spytać najpierw niż ew. tracić czas na zmiany, które będą odrzucone.

Użytkownik może nie podać nr telefonu podczas rejestracji

Ze względu na to, że numer telefonu nie będzie obowiązkowy (ProteGO-Safe/specs#34 (comment)) użytkownicy mogą zarejestrować się bez podania nr telefonu. API zostanie ustalone tutaj: ProteGO-Safe/backend#67

Aplikacja wykrywa brak internetu i nie włącza się

W przypadku braku dostępu do Internetu, aplikacja informuje o tym i nie pozwala przejść dalej.

Aplikacja nie działa na Pixel 4

Po uaktualnieniu aplikacji pojawia sie komunikat:
Twoje urządzenie nie mogło zostać pozytywnie zweryfikowane

Aplikacja rozgłasza się, łączy z urządzeniami w pobliżu przez Bluetooth i pobiera ich identyfikatory

Wymagania:
Działa na iOS i Android. Obie platformy widzą się nawzajem.
Maksymalnie oszczędza baterię.
Zapisujemy siłę sygnału
Działa w tle. Po zamknięciu aplikacja wybudza się automatycznie.
Co godzinę rozgłaszamy inny identyfikator.
Wykryte urządzenia możemy śledzić np. w BugFender

Możliwość powrotu do poprzednich ekranów z ekranu statusu użytkownika

Opis błędu

Użytkownik ma możliwość powrotu za pomocą przycisku BACK z ekranu głównego aplikacji (ekran ze statusem użytkownika) do poprzednich ekranów (onboarding). Błąd występuje przy pierwszym uruchomieniu aplikacji.

Kroki

1. Otwórz aplikację
2. Przejdź onboarding
3. Przejdź do ekranu głównego
4. Użyj przycisku BACK

Oczekiwany zachowanie aplikacji

Użytkownik nie powinien mieć możliwości powrotu do ekranu onboardingu z ekranu głównego

Urządzenie (proszę wypełnij poniższe informacje dotyczące urządzenia):

• Nazwa: Samsung Galaxy S6
• System operacyjny: Android
• Wersja systemu operacyjnego: 7.0
• Wersja aplikacji: ProteGO Stg 1.0.10-stg

Środowisko

• Wersja środowiska: stag

Komunikat w SMS. Brak polskiej litery "ó" w słowie "Twój"

Opis błędu

Brak polskiej litery "ó" w komunikacie SMS.

Kroki

1. Odbierz kod SMS

Środowisko

• Wersja środowiska: stg

Usprawnienia modułu Bluetooth

Tematy usprawnień modułu Bluetooth

1. Przeniesienie użycia wszystkich obiektów związanych z działaniem Bluetootha do serwisu pracującego w oddzielnym procesie

Aktualnie na wciągnięcie do głównej gałęzi programu czeka #66
Po dodaniu będzie można przenieść użycie BluetoothBeaconIdExchangeManager z ProtegoApp do tego serwisu.

Motywacja: Foregroundowy serwis działający w oddzielnym procesie powinien być mniej narażony na zabicie przez system, gdy jednocześnie proces odpowiadający za interfejs użytkownika może zostać wymieciony w celu zwolnienia pamięci.

2. Automatyczne zarządzanie rozgłaszaniem i skanowaniem

Aktualna implementacja jest pierwszą działającą. Nie posiada funkcjonalności samoczynnego wznowienia działania przy sprzyjających warunkach.

Prawdopodobne miejsce wprowadzenia zmian: BluetoothBeaconIdExchangeManager

2a. Obserwacja stanu adaptera Bluetooth oraz ustawienia Location Services

W zależności od ustawienia adaptera należy włączyć lub wyłączyć ProteGoAdvertiser i ProteGoScanner. Odpowiednio, gdy Bluetooth jest włączony na telefonie, to oba obiekty też mogą zostać włączone. Gdy Bluetooth zostanie wyłączony, oba obiekty najpewniej zwrócą błędy w poprzez interfejs słuchacza.

Sprawa z Location Services jest o tyle bardziej skomplikowana, że najprawdopodobniej ProteGoAdvertiser będzie działał niezależnie od ich stanu, z poszanowaniem jednak stanu adaptera Bluetooth. ProteGoScanner natomiast w przypadku wyłączenia Location Services przestanie działać, gdyż takie są ograniczenia na większości urządzeń z systemem Android >=6.0.
Do rozważenia – w takim przypadku można ustawiać wersję w ProteGoAdvertiser (część Manufacturers Data), która by mówiła o tym, że dane urządzenie nie może skanować – wtedy wszystkie inne urządzenia Androida w pobliżu musiałyby się połączyć i zapisać swój BeaconId, gdyż wiadomo, że druga strona nie będzie mogła go zeskanować.

2b. Obsługa potencjalnych problemów raportowanych przez interfejsy słuchaczy ProteGoAdvertiser i ProteGoScanner

Obie klasy przy włączeniu przyjmują referencje do słuchaczy, którzy mogą zostać poinformowani w przypadku problemów, które mogą wystąpić już po włączeniu odpowiednich funkcjonalności.
W takim przypadku należy zidentyfikować problem i w miarę możliwości przełączyć w tryb pozwalający na utrzymanie możliwie dobrego działania.

Przykład myślenia (pseudokod):

var wynikInicjalizacjiAdvertisera = ProteGoAdvertiser.enable()
val wynikInicjalizacjiScanera = ProteGoScanner.enable()
if (wynikInicjalizacjiScanera == negatywny && wynikInicjalizacjiAdvertisera == pozytywny) {
  ProteGoAdvertiser.disable()
  wynikInicjalizacjiAdvertisera = ProteGoAdvertiser.enable(oznajmiajBrakMozliwosciSkanowania)
}
if (wynikInicjalizacjiAdvertisera == negatywny && wynikInicjalizacjiScanera == negatywny) {
  // aplikacja jest zupełnie nieużyteczna
  Notification.poinformujUżytkownikaONapotkanychProblemach
} else if (wynikInicjalizacjiScanera == negatywny) {
 // aplikacja może nie wymuszać połączeń od zewnętrznych urządzeń, jeśli przeszkody w inicjalizacji skanera zostaną usunięte
  Notification.poprosUżytkownikaOUsunięciePrzeszkód
} else if (wynikInicjalizacjiAdvertisera == negatywny) {
  ProteGoAdvertiser.disable() // pod spodem można wyłączyć serwer, który nie zostanie połączony jeśli się nie rozgłasza. Do rozważenia wydzielenie advertisera i serwera.
}

3. Dostrajanie działania funkcjonalności BLE

Ekosystem Androida jest bardzo rozbity. Mnogość urządzeń różnych producentów, często niestandardowych implementacji systemu, różnych wersji systemów, różnych czipów Bluetooth i różnych sterowników oraz firmware'ów na tych chipach nie pozwala na napisanie jednej implementacji, która będzie działała optymalnie w każdych warunkach.

3a. Stworzenie różnych implementacji logiki BluetoothBeaconIdExchangeManager

Przykładowe pomysły:

1. (Początkowa implementacja) Rozgłaszanie i skanowanie odbywa się ciągle. Próby połączeń nie powodują przerwania rozgłaszania i skanowania. Połączenia w trybie bezpośrednim (autoConnect == false.
   Alternatywą mogą być połączenia w trybie autoConnect == true
2. Rozgłaszanie odbywa się ciągle. Skanowanie trwa tak długo aż znajdzie się pierwsze urządzenie do połączenia, następnie przez 10 sekund inne zeskanowane urządzenia są łączone w trybie bezpośrednim (druga wersja w trybie autoConnect)
3. Rozgłaszanie i skanowanie jest przerywane na czas wykonywania połączeń

Dodatkowym parametrem który można wprowadzić jest zmiana trybu skanowania z niskomocowego na zbalansowany.

3b. A/B testy i zbieranie metryk

Ponieważ jest potencjalnie wiele taktyk i nie wiemy na jakim urządzeniu która będzie najlepsza, potrzebujemy robić testy i zbierać metryki z urządzeń.

Pomysły na metryki:

• marka / model / wersja system telefonu
• przyjęta taktyka połączeń (patrz punkt wyżej)
• ilość skanowanych urządzeń / 1h
• ilość prób połączeń do urządzeń / 1h
• ilość udanych połączeń do urządzeń / 1h
• czas trwania udanego połączenia
• czas trwania nieudanego połączenia

Celem zbierania metryk jest zrozumienie która taktyka na danym urządzeniu sprawuje się najlepiej, tak by następnie móc przełączyć wszystkie urządzenia właśnie na nią.

Oryginalna wiadomość

Wyniesione z #65

Do zrobienia:

1. Zarządzanie obiektami rozgłaszająco-skanującymi w kontekście zmian stanu adaptera Bluetooth, ustawień lokalizacji i zezwoleń
2. Implementacja docelowego zarządzania BeaconId
3. Przeniesienie obiektów związanych z Bluetooth do oddzielnego serwisu pracującego w oddzielnym procesie
4. Potencjalnie naprzemienne skanowanie (+ rozgłaszanie?) i próby połączeń
5. A/B testy skuteczności różnych rozwiązań połączeń dla danego modelu telefonu
   a. Czy naprzemienne skanowanie i łączenie poprawia skuteczność połączeń? (Najpewniej tak, patrz tutaj)
   b. Czy jednoczesne rozgłaszanie wpływa na skuteczność połączeń?
   c. Jak wzajemnie wpływają na siebie: rozgłaszanie, odbieranie połączeń, skanowanie i wykonywanie połączeń?
6. Fallback w przypadku gdy skanowanie nie jest możliwe z powodu braku dostępu do lokalizacji, tak by inne urządzenia mogły się połączyć i przekazać swój BeaconId?
7. Obsługa problemów związanych z asynchronicznym raportowaniem błędów przez advertiser i scanner

Zadanie jest do rozbicia na poszczególne punkty.

Przycisk back i cofanie do historycznych aktywności

Przycisk back naciskany w celu wyjścia z aplikacji, powoduje powrót do poprzednich historycznych aktywności które otwierałem. Lub np. jeśli kliknę 100 razy na "Porady" to żeby cofnąć się do poprzedniej aktywności z której przeszedłem muszę 100 razy kliknąć back.

Xiaomi Mi 9, Android 10.

Nadmiarowa walidacja poprawności nr telefonu podczas wpisywania numeru

Opis błędu

Podczas wpisywania nr telefonu pojawia się komunikat Niepoprawny numer telefonu do momentu wpisania całego poprawnego numeru (9 cyfr). Komunikat powinien pojawić się dopiero przy próbie potwierdzenia i wysłania nr telefonu.

Kroki

1. Wpisuj nr telefonu (do 9 cyfr)
2. Potwierdź nr telefonu

Oczekiwany zachowanie aplikacji

Komunikat walidacji poprawności nr telefonu powinien pojawić się dopiero przy próbie potwierdzenia niepoprawnego numeru
.
Urządzenie (proszę wypełnij poniższe informacje dotyczące urządzenia):

• Nazwa: Samsung Galaxy S8
• System operacyjny: Android
• Wersja aplikacji: 0.0.3-stg

Środowisko

• Wersja środowiska: stg

Publiczne pull'e

Witam,

Czy ten projekt będzie całkowicie otwarty i można tworzyć pulle które będą przeglądane i ewentualnie mergowane do głównej gałęzi?

Telefon rozgłasza inne uuid profilu Bluetooth na różnych wersjach aplikacji

Na jednym telefonie możemy mieć zainstalowane różne wersje aplikacji dev, stag, prod. Niech rozgłaszają się różnym uuid.

Historia spotkanych urządzeń jest szyfrowana na urządzeniu

Rozszerzenie mechanizmu sprawdzającego połączenie internetowe.

Sprawdzanie połączenie internetowego nie powinno się ograniczać jedynie do sprawdzenia statusu WIFI lub danych komórkowych ale powinno nastąpić sprawdzenie połączenia z jakims publicznym serwerem.

Aplikacja daje możliwość ponownego przesłania kodu weryfikującego numer telefonu

Opis prozypozycji rozwiązania

Obecnie po przesłaniu numeru telefonu użytkownik jest przenoszony do registration_confirmation_view z prośbą o wpisanie kodu potwierdzającego numer telefonu. W tym widoku użytkownik powinien mieć możliwość poproszenia o ponowne przesłanie kodu. Kod mógł nie zostać dostarczony z różnych przyczyn, użytkownik mógł omyłkowo usunąć SMS z kodem itp.

Opis alternatywnych rozwiązań

Alternatywnie można dać użytkownikowi możliwość powrotu do registration_view, tak żeby mógł jeszcze raz mógł użyć przycisku DOŁĄCZ DO, co prawda można to teraz zrobić przy pomocy sprzętowego przycisku powrotu, ale nie dla każdego może to być intuicyjne. Mógłby zatem istnieć drugi przycisk na registration_confirmation_view o tytule POWRÓT.

WAŻNE: ZMIANY W PROJEKCIE

Zapraszam do przeczytania ogłoszenia

Lokalny development aplikacji.

Jest jakiś opis w jaki sposób developować lokalnie aplikacje?

Próbowałem się zarejestrować po uruchomieniu aplikacji przez android studio w swoim telefonie, ale dostałem odpowiedz http 500 po wpisaniu kodu z SMS'a podczas rejestracji.

Możliwość dodania do sklepu F-Droid

Opis prozypozycji rozwiązania

Jeśli udałoby się uwzględnić możliwość użycia micro-G zamiast Google Play Services, oraz braku crashlytics w produkcyjnej kompilacji (lub jakaś jego wolna alternatywa), aplikacja może być dostępna w sklepie F-Droid (https://f-droid.org/).

Dodatkowe informacje

Zgłosiłem propozycję dodania aplikacji do tego sklepu tutaj:
https://gitlab.com/fdroid/fdroiddata/-/merge_requests/6593

Można sprawdzić lokalnie, czy aplikacja buduje się poprawnie: krok 1 i krok 2. Mnie wyskakuje tylko jeden błąd (logi).

F-Droid jest sklepem z aplikacjami skompilowanymi w pełni ze źródeł. Daje dużo ciekawych możliwości użytkownikom. No i można przypiąć apce ładną grafikę.

Użytkownik może wysłać dane na serwer

wg. designów