Urządzenia z Androidem, które nie mają salda danych, przepuszczają ruch sieciowy, co wymaga od operatorów i operatorów telekomunikacyjnych wdrożenia protokołów zapobiegania. Android wdraża ogólne rozwiązanie, które umożliwia operatorom i operatorom telekomunikacyjnym wskazanie, kiedy na urządzeniu kończy się saldo.
Platforma Androida udostępnia domyślną aplikację operatora z domyślnym zachowaniem w zakresie łagodzenia ruchu na podstawie sygnału wykrywania portalu przechwytującego. Umożliwia też operatorom i OEM-om dostosowywanie działania przy niskich kosztach i dużej elastyczności.
Przykłady i źródło
Domyślna aplikacja operatora znajduje się w miejscu platform/frameworks/base/packages/CarrierDefaultApp/.
Implementacja
Domyślna aplikacja operatora jest skonfigurowana tak, aby zapewniać większą wygodę nieskonfigurowanym operatorom. Operatorzy mogą korzystać z tego domyślnego działania. Mogą też zastąpić domyślne działanie, dodając do pliku XML konfiguracji operatora mapowania sygnału na działanie. Mogą zrezygnować z aplikacji domyślnej i zamiast tego korzystać z uprawnień UICC w ramach własnej samodzielnej aplikacji operatora.
Wprowadzenie do implementacji
Signals
Platforma Android umożliwia konfigurowanie działań na podstawie tych sygnałów z parametrami:
TelephonyIntents.ACTION_CARRIER_SIGNAL_REDIRECTEDTelephonyIntents.ACTION_CARRIER_SIGNAL_REQUEST_NETWORK_FAILED
Te sygnały znajdują się w sekcji frameworks/base/telephony/java/com/android/internal/telephony/TelephonyIntents.java.
Obsługiwane działania
Domyślna aplikacja operatora definiuje zestaw obsługiwanych działań, które można mapować na obsługiwane sygnały. Są one zdefiniowane w pliku CarrierActionUtils.java:
public static final int CARRIER_ACTION_ENABLE_METERED_APNS = 0;
public static final int CARRIER_ACTION_DISABLE_METERED_APNS = 1;
public static final int CARRIER_ACTION_DISABLE_RADIO = 2;
public static final int CARRIER_ACTION_ENABLE_RADIO = 3;
public static final int CARRIER_ACTION_SHOW_PORTAL_NOTIFICATION = 4;
public static final int CARRIER_ACTION_SHOW_NO_DATA_SERVICE_NOTIFICATION = 5;
public static final int CARRIER_ACTION_CANCEL_ALL_NOTIFICATIONS = 6;Uwaga: jeśli operator wdroży własną samodzielną aplikację, może wdrożyć obsługę sygnałów innych niż wymienione w tej sekcji. Mogą też definiować i konfigurować własne działania.
Domyślne mapowania sygnałów na działania
Aby skonfigurować działania domyślne:
- Określ klucz dla obsługiwanych sygnałów.
Domyślne mapowania sygnałów na działania są zdefiniowane w
CarrierConfigManager.java. Każdy z obsługiwanych sygnałów ma klucz:public static final String KEY_CARRIER_DEFAULT_ACTIONS_ON_REDIRECTION_STRING_ARRAY = "carrier_default_actions_on_redirection_string_array"; public static final String KEY_CARRIER_DEFAULT_ACTIONS_ON_DCFAILURE_STRING_ARRAY = "carrier_default_actions_on_dcfailure_string_array";
- Połącz domyślne działania z kluczami sygnału.
Domyślne identyfikatory działań są powiązane z kluczami sygnału:
sDefaults.putStringArray(KEY_CARRIER_DEFAULT_ACTIONS_ON_REDIRECTION_STRING_ARRAY, new String[]{ "1, 4" //1: CARRIER_ACTION_SHOW_PORTAL_NOTIFICATION // 4: CARRIER_ACTION_DISABLE_METERED_APNS });Platforma telefonii przypisuje te działania do odpowiednich sygnałów.
Zastępowanie działań domyślnych
W pliku konfiguracyjnym XML operatora możesz zdefiniować działania niestandardowe dla obsługiwanych sygnałów, powiązać identyfikatory działań z kluczami sygnału (zdefiniowane w pliku CarrierConfigManager.java). Na przykład poniższe mapowanie wyłącza płatne APN i wyświetli powiadomienie portalu po przekierowaniu:
<string-array name="carrier_default_actions_on_redirection_string_array" num="2">
<item value="1" />
<item value="4" />
</string-array>Framework telefonii ładuje te konfiguracje i zastępuje domyślne działania.
Weryfikacja
Ta funkcja nie jest objęta testami CTS, CTS Verifier ani GTS.
Aby zweryfikować funkcję, użyj tych testów ręcznej weryfikacji:
- Sprawdź powiadomienie o niedostatecznym sygnale urządzenia od operatora.
- Sprawdź ograniczanie przekierowywania ruchu w stanie nierównowagi i przy wyłączonym Wi-Fi.
- Sprawdź, czy ruch sieciowy jest ograniczony, a interfejs powiadomienia wyświetla się w stanie braku środków.
- Sprawdzanie funkcji połączeń głosowych/VoLTE w stanie braku równowagi.
- Sprawdź, czy rozmowy wideo są zablokowane w stanie nierównowagi.
- Gdy Wi-Fi jest włączone, sprawdź, czy użytkownik może kontynuować przeglądanie stron internetowych, a ruch przeglądania nie powoduje włączenia ruchu sieciowego w stanie nierównowagi.
- Sprawdzanie funkcji Wi-Fi, WFC i Bluetooth w stanie niesymetrycznym.
- Wyłącz Wi-Fi. Sprawdź interfejs powiadomienia o niedoładowaniu i upewnij się, że zwykły ruch przeglądania nie jest przekierowywany do witryny rejestracji operatora telefonii komórkowej. Sprawdź, czy po kliknięciu linku w interfejsie powiadomienia przeglądarka przekierowuje użytkownika do witryny rejestracji operatora.
- Sprawdź, czy przełączenie trybu samolotowego nie powoduje zresetowania stanu ograniczania przepustowości ruchu.
- Sprawdź, czy wymiana karty SIM w urządzeniu resetuje stan ruchu sieci.
- Sprawdź, czy ponowne włożenie karty SIM z niedopłatą powoduje ponowne przekierowanie ruchu i ponownie włącza ograniczanie ruchu sieciowego.
- Sprawdź, czy po ponownym uruchomieniu telefonu ponownie włącza się przekierowanie i pojawi się ograniczenie ruchu oraz interfejs powiadomień.
- Kliknij powiadomienie „captiveportal”. Sprawdź, czy połączenie z siecią z ograniczeniami zostało nawiązane, aby umożliwić użytkownikowi dodanie środków.
- Sprawdź, czy uzupełnienie salda na karcie SIM lub jej reaktywacja powoduje odzyskanie ruchu w sieci komórkowej oraz czy link do operatora i powiadomienie o brakującym saldzie znikają.
- Sprawdzanie poprawności po przywróceniu danych.
Domyślna aplikacja zawiera kilka przykładów testów jednostkowych oraz skrypt do ich uruchamiania (zob. tests/runtest.sh). Gdy wdrożesz dostosowaną wersję lub zachowanie, musisz odzwierciedlić te zmiany w dedykowanych testach jednostkowych.