Platforma Android Telecom (nazywana też po prostu „Telecom”) zarządza połączeniami audio i wideo na urządzeniu z Androidem. Obejmuje to połączenia z użyciem karty SIM, takie jak połączenia korzystające z ramy telefonicznej, oraz połączenia VoIP, które implementują bibliotekę Jetpack Core-Telecom
.
Główne komponenty zarządzane przez operatora telekomunikacyjnego to ConnectionService
i InCallService
.
Implementacja ConnectionService
opiera się na takich technologiach jak PSTN, aby nawiązywać połączenia z innymi stronami. Najczęstszym ConnectionService
w telefonie jest ConnectionService
. Łączy połączenia z operatorem.
Implementacja InCallService
zapewnia interfejs użytkownika do zarządzania połączeniami przez operatora telekomunikacyjnego oraz umożliwia użytkownikowi kontrolowanie tych połączeń i działanie na nich. Najczęstszym sposobem implementacji InCallService
jest aplikacja telefoniczna dołączona do urządzenia.
Telekomunikacja działa jak centrala telefoniczna. Przekierowuje połączenia obsługiwane przez implementacje ConnectionService
do interfejsów wywołania obsługiwanych przez implementacje InCallService
.
Interfejsy Telecom API możesz wdrażać z tych powodów:
- Aby utworzyć zamiennik aplikacji telefonicznej w systemie.
- Aby zintegrować rozwiązanie do połączeń z funkcją połączeń na Androidzie.
Tworzenie zastępczej aplikacji telefonicznej
Aby utworzyć zamiennik domyślnej aplikacji telefonicznej na urządzeniu z Androidem, zaimplementuj interfejs API InCallService
. Implementacja musi spełniać te wymagania:
- Aplikacja nie może mieć żadnych funkcji umożliwiających nawiązywanie połączeń i musi składać się wyłącznie z interfejsu do nawiązywania połączeń.
- Musi obsługiwać wszystkie wywołania, o których wie framework telekomunikacyjny, i nie może robić założeń dotyczących ich charakteru. Nie można na przykład założyć, że połączenia są połączeniami telefonicznymi z użyciem karty SIM, ani stosować ograniczeń połączeń opartych na jednym
ConnectionService
, takich jak egzekwowanie ograniczeń połączeń telefonicznych w przypadku połączeń wideo.
Więcej informacji znajdziesz w sekcji InCallService
.
Integracja rozwiązania do obsługi połączeń
Aby zintegrować rozwiązanie do wykonywania połączeń z Androidem, masz do wyboru te opcje:
Zaimplementuj samodzielnie zarządzaną bibliotekę Core-Telecom Jetpack: ta opcja jest idealna dla deweloperów samodzielnych aplikacji do wykonywania połączeń, którzy nie chcą wyświetlać swoich połączeń w domyślnej aplikacji Telefon ani nie chcą, aby inne połączenia były wyświetlane w interfejsie.
Integracja z biblioteką Jetpack
Core-Telecom
pozwala aplikacji na współpracę nie tylko z systemem telefonii na urządzeniu, ale też z innymi samodzielnymi aplikacjami do połączeń, które integrują się z Telecom. BibliotekaCore-Telecom
zarządza też kierowaniem dźwięku i punktowaniem. Więcej informacji znajdziesz w artykule Tworzenie aplikacji do połączeń.Wdrażanie zarządzanego interfejsu ConnectionService API: ta opcja ułatwia tworzenie rozwiązania do wykonywania połączeń, które korzysta z dotychczasowej aplikacji telefonicznej na urządzeniu, aby udostępnić interfejs użytkownika do obsługi połączeń. Przykładem może być implementacja przez firmę zewnętrzną usług połączeń SIP i VoIP. Więcej informacji znajdziesz w sekcji
getDefaultDialerPackage()
.Sam
ConnectionService
zapewnia tylko możliwość łączenia połączeń. Nie ma powiązanego z nim interfejsu.Zaimplementuj interfejsy InCallService i ConnectionService API: ta opcja jest idealna, jeśli chcesz utworzyć własne rozwiązanie do wykonywania połączeń na podstawie interfejsu
ConnectionService
, a także wyświetlać wszystkie inne połączenia na Androidzie w tym samym interfejsie. W takim przypadku implementacja funkcjiInCallService
nie może opierać się na żadnych założeniach dotyczących źródeł wywoływanych przez nią połączeń. Ponadto implementacjaConnectionService
musi działać bez domyślnej aplikacji telefonu ustawionej na niestandardową aplikacjęInCallService
.
Filtrowanie połączeń
Urządzenia z Androidem 10 (poziom interfejsu API 29) lub nowszym umożliwiają aplikacji identyfikowanie połączeń z numerów, które nie znajdują się w książce adresowej użytkownika, jako potencjalnych połączeń spamowych. Użytkownicy mogą zdecydować, że połączenia spamowe mają być automatycznie odrzucane. Aby zapewnić użytkownikom większą przejrzystość w przypadku nieodebranych połączeń, informacje o tych zablokowanych połączeniach są rejestrowane w historii połączeń. Korzystanie z interfejsu API Androida 10 eliminuje konieczność uzyskania od użytkownika uprawnień READ_CALL_LOG
, aby udostępnić funkcję sprawdzania połączeń i identyfikacji dzwoniącego.
Do filtrowania połączeń używasz implementacji CallScreeningService
. Użyj funkcji onScreenCall()
w przypadku nowych połączeń przychodzących i wychodzących, gdy numer nie znajduje się na liście kontaktów użytkownika. Aby uzyskać informacje o wywołaniu, możesz sprawdzić obiekt Call.Details
. W szczególności funkcja getCallerNumberVerificationStatus()
zawiera informacje od operatora sieci o drugim numerze.
Jeśli stan weryfikacji nie powiódł się, oznacza to, że połączenie pochodzi z nieprawidłowego numeru lub jest potencjalnym spamem.
Kotlin
class ScreeningService : CallScreeningService() { // This function is called when an ingoing or outgoing call // is from a number not in the user's contacts list override fun onScreenCall(callDetails: Call.Details) { // Can check the direction of the call val isIncoming = callDetails.callDirection == Call.Details.DIRECTION_INCOMING if (isIncoming) { // the handle (e.g. phone number) that the Call is currently connected to val handle: Uri = callDetails.handle // determine if you want to allow or reject the call when (callDetails.callerNumberVerificationStatus) { Connection.VERIFICATION_STATUS_FAILED -> { // Network verification failed, likely an invalid/spam call. } Connection.VERIFICATION_STATUS_PASSED -> { // Network verification passed, likely a valid call. } else -> { // Network could not perform verification. // This branch matches Connection.VERIFICATION_STATUS_NOT_VERIFIED. } } } } }
Java
class ScreeningService extends CallScreeningService { @Override public void onScreenCall(@NonNull Call.Details callDetails) { boolean isIncoming = callDetails.getCallDirection() == Call.Details.DIRECTION_INCOMING; if (isIncoming) { Uri handle = callDetails.getHandle(); switch (callDetails.getCallerNumberVerificationStatus()) { case Connection.VERIFICATION_STATUS_FAILED: // Network verification failed, likely an invalid/spam call. break; case Connection.VERIFICATION_STATUS_PASSED: // Network verification passed, likely a valid call. break; default: // Network could not perform verification. // This branch matches Connection.VERIFICATION_STATUS_NOT_VERIFIED } } } }
Ustaw funkcję onScreenCall()
tak, aby wywoływała funkcję respondToCall()
, aby poinformować system, jak ma odpowiedzieć na nowe połączenie. Ta funkcja przyjmuje parametr CallResponse
, który pozwala systemowi zablokować połączenie, odrzucić je tak, jakby zrobił to użytkownik, lub wyciszyć dźwięk. Możesz też zlecić systemowi, aby całkowicie pomijał dodawanie tego połączenia do dziennika połączeń na urządzeniu.
Kotlin
// Tell the system how to respond to the incoming call // and if it should notify the user of the call. val response = CallResponse.Builder() // Sets whether the incoming call should be blocked. .setDisallowCall(false) // Sets whether the incoming call should be rejected as if the user did so manually. .setRejectCall(false) // Sets whether ringing should be silenced for the incoming call. .setSilenceCall(false) // Sets whether the incoming call should not be displayed in the call log. .setSkipCallLog(false) // Sets whether a missed call notification should not be shown for the incoming call. .setSkipNotification(false) .build() // Call this function to provide your screening response. respondToCall(callDetails, response)
Java
// Tell the system how to respond to the incoming call // and if it should notify the user of the call. CallResponse.Builder response = new CallResponse.Builder(); // Sets whether the incoming call should be blocked. response.setDisallowCall(false); // Sets whether the incoming call should be rejected as if the user did so manually. response.setRejectCall(false); // Sets whether ringing should be silenced for the incoming call. response.setSilenceCall(false); // Sets whether the incoming call should not be displayed in the call log. response.setSkipCallLog(false); // Sets whether a missed call notification should not be shown for the incoming call. response.setSkipNotification(false); // Call this function to provide your screening response. respondToCall(callDetails, response.build());
Aby system mógł prawidłowo uruchamiać implementację CallScreeningService
, musisz ją zarejestrować w pliku manifestu za pomocą odpowiedniego filtra intencji i uprawnień.
<service
android:name=".ScreeningService"
android:permission="android.permission.BIND_SCREENING_SERVICE">
<intent-filter>
<action android:name="android.telecom.CallScreeningService" />
</intent-filter>
</service>
Przekierowywanie połączenia
Urządzenia z Androidem 10 lub nowszym zarządzają intencjami połączeń inaczej niż urządzenia z Androidem 9 lub starszym. W Androidzie 10 i nowszych wersjach transmisja ACTION_NEW_OUTGOING_CALL
została wycofana i zastąpiona interfejsem API CallRedirectionService
. CallRedirectionService
udostępnia interfejsy do modyfikowania wychodzących połączeń nawiązywanych przez platformę Android. Na przykład aplikacje innych firm mogą anulować połączenia i przekierować je przez VoIP.
Kotlin
class RedirectionService : CallRedirectionService() { override fun onPlaceCall( handle: Uri, initialPhoneAccount: PhoneAccountHandle, allowInteractiveResponse: Boolean ) { // Determine if the call should proceed, be redirected, or cancelled. val callShouldProceed = true val callShouldRedirect = false when { callShouldProceed -> { placeCallUnmodified() } callShouldRedirect -> { // Update the URI to point to a different phone number or modify the // PhoneAccountHandle and redirect. redirectCall(handle, initialPhoneAccount, true) } else -> { cancelCall() } } } }
Java
class RedirectionService extends CallRedirectionService { @Override public void onPlaceCall( @NonNull Uri handle, @NonNull PhoneAccountHandle initialPhoneAccount, boolean allowInteractiveResponse ) { // Determine if the call should proceed, be redirected, or cancelled. // Your app should implement this logic to determine the redirection. boolean callShouldProceed = true; boolean callShouldRedirect = false; if (callShouldProceed) { placeCallUnmodified(); } else if (callShouldRedirect) { // Update the URI to point to a different phone number or modify the // PhoneAccountHandle and redirect. redirectCall(handle, initialPhoneAccount, true); } else { cancelCall(); } } }
Musisz zarejestrować tę usługę w pliku manifestu, aby system mógł ją prawidłowo uruchomić.
<service
android:name=".RedirectionService"
android:permission="android.permission.BIND_CALL_REDIRECTION_SERVICE">
<intent-filter>
<action android:name="android.telecom.CallRedirectionService"/>
</intent-filter>
</service>
Aby korzystać z usługi przekierowywania, aplikacja musi poprosić o rolę przekierowywania połączeń od RoleManager
. Użytkownik zostanie poproszony o pozwolenie na przekierowanie połączeń przez Twoją aplikację. Jeśli aplikacji nie przyznano tej roli, usługa przekierowania nie jest używana.
Sprawdź, czy Twoja aplikacja ma tę rolę, gdy użytkownik ją uruchamia, aby móc ją w razie potrzeby poprosić. Użytkownik uruchamia zamiar utworzony przez RoleManager
,
dlatego musisz zastąpić funkcję
onActivityResult()
, aby obsłużyć wybór użytkownika.
Kotlin
class MainActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) // Tell the system that you want your app to handle call redirects. This // is done by using the RoleManager to register your app to handle redirects. if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.Q) { val roleManager = getSystemService(Context.ROLE_SERVICE) as RoleManager // Check if the app needs to register call redirection role. val shouldRequestRole = roleManager.isRoleAvailable(RoleManager.ROLE_CALL_REDIRECTION) && !roleManager.isRoleHeld(RoleManager.ROLE_CALL_REDIRECTION) if (shouldRequestRole) { val intent = roleManager.createRequestRoleIntent(RoleManager.ROLE_CALL_REDIRECTION) startActivityForResult(intent, REDIRECT_ROLE_REQUEST_CODE) } } } companion object { private const val REDIRECT_ROLE_REQUEST_CODE = 1 } }
Java
class MainActivity extends AppCompatActivity { private static final int REDIRECT_ROLE_REQUEST_CODE = 0; @Override protected void onCreate(@Nullable Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); // Tell the system that you want your app to handle call redirects. This // is done by using the RoleManager to register your app to handle redirects. if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.Q) { RoleManager roleManager = (RoleManager) getSystemService(Context.ROLE_SERVICE); // Check if the app needs to register call redirection role. boolean shouldRequestRole = roleManager.isRoleAvailable(RoleManager.ROLE_CALL_REDIRECTION) && !roleManager.isRoleHeld(RoleManager.ROLE_CALL_REDIRECTION); if (shouldRequestRole) { Intent intent = roleManager.createRequestRoleIntent(RoleManager.ROLE_CALL_REDIRECTION); startActivityForResult(intent, REDIRECT_ROLE_REQUEST_CODE); } } } }