Platforma Android Telecom (inaczej „Telecom”) zarządza rozmowami audio i wideo na urządzeniach z Androidem. Obejmuje to połączenia przez kartę SIM, np. wykorzystujące platformę telefonii, oraz połączenia VoIP z wdrożonym interfejsem API ConnectionService.
Główne komponenty, którymi zarządza firma Telecom, to ConnectionService i InCallService.
Implementacja ConnectionService wykorzystuje technologie takie jak VoIP do nawiązywania połączeń z innymi osobami. Najpopularniejsza implementacja ConnectionService na telefonie to ConnectionService. Łączy połączenia przez operatora.
Implementacja InCallService udostępnia interfejs do połączeń zarządzanych przez telekomunikację oraz pozwala użytkownikowi sterować tymi połączeniami i wchodzić z nimi w interakcje. Najczęściej implementacją InCallService jest aplikacja telefonu dołączona do urządzenia.
Telekomunikacja pełni rolę centrali. Kieruje ona wywołania, które implementacje ConnectionService przekazują do wywołujących interfejsów użytkownika, które są dostępne w implementacjach InCallService.
Wdrożenie interfejsów Telecom API może być przydatne, jeśli:
- Aby utworzyć zamiennik systemowej aplikacji Telefon.
- Aby zintegrować rozwiązanie do połączeń z interfejsem rozmów na Androida.
Tworzenie zastępczej aplikacji telefonicznej
Aby utworzyć zamiennik domyślnej aplikacji telefonicznej na urządzeniu z Androidem, zaimplementuj interfejs API InCallService. Twoja implementacja musi spełniać te wymagania:
- Nie może on mieć żadnej funkcji nawiązywania połączeń i musi składać się wyłącznie z interfejsu użytkownika.
- Musi obsługiwać wszystkie połączenia, o których wieża platforma telekomunikacyjna, i nie może wyciągać wniosków co do ich charakteru. Na przykład nie może zakładać, że połączenia są wykonywane przez kartę SIM, ani stosować ograniczeń połączeń opartych na dowolnym
ConnectionService, takich jak egzekwowanie ograniczeń telefonicznych w przypadku rozmów wideo.
Więcej informacji: InCallService.
Zintegruj rozwiązanie do rozmów
Aby zintegrować rozwiązanie do połączeń z Androidem, masz do wyboru te opcje:
Zaimplementuj samodzielnie zarządzanym interfejs ConnectionService API: ta opcja jest idealna dla programistów samodzielnych aplikacji wywołujących, którzy nie chcą pokazywać swoich wywołań w domyślnej aplikacji do obsługi telefonu ani mieć innych wywołań w interfejsie.
Gdy używasz samodzielnie zarządzanego interfejsu
ConnectionService, Twoja aplikacja może współpracować nie tylko z natywnymi połączeniami telefonicznymi na urządzeniu, ale także z innymi samodzielnymi aplikacjami wywołującymi ten interfejs API, które go używają. Zarządzany przez siebie samodzielnie interfejs APIConnectionServicezarządza też routingiem i fokusem dźwięku. Więcej informacji znajdziesz w artykule Tworzenie aplikacji do rozmów.Zaimplementuj interfejs zarządzanego interfejsu ConnectionService API: ta opcja ułatwia opracowanie rozwiązania wywołującego, które korzysta z istniejącej aplikacji telefonu na urządzeniu do udostępniania interfejsu użytkownika. Przykładem może być implementacja przez inną firmę usług połączeń SIP i VoIP. Więcej informacji:
getDefaultDialerPackage().Już samo urządzenie
ConnectionServiceumożliwia nawiązywanie połączeń. Nie ma ona powiązanego interfejsu.Zaimplementuj zarówno interfejs InCallService, jak i ConnectionService API: ta opcja jest idealna, jeśli chcesz utworzyć własne rozwiązanie do wywoływania oparte na
ConnectionService, z własnym interfejsem użytkownika, a także wyświetlać wszystkie inne wywołania Androida w tym samym interfejsie. Jeśli używasz tej metody, implementacjaInCallServicenie może zakładać żadnych założeń dotyczących źródeł wyświetlanych wywołań. Dodatkowo implementacjaConnectionServicemusi nadal działać bez ustawienia domyślnej aplikacji telefonu jako niestandardowej aplikacjiInCallService.
Filtrowanie połączeń
Urządzenia z Androidem 10 (poziom interfejsu API 29) lub nowszym umożliwiają aplikacji identyfikowanie połączeń z numerów, których nie ma w książce adresowej użytkownika, jako potencjalnych połączeń spamowych. Użytkownicy mogą włączyć dyskretne odrzucanie połączeń spamowych. Aby zapewnić użytkownikom większą przejrzystość informacji o nieodebranych połączeniach, informacje o tych zablokowanych połączeniach są rejestrowane w rejestrze połączeń. Korzystanie z interfejsu Android 10 API eliminuje konieczność uzyskiwania od użytkownika uprawnień do READ_CALL_LOG, aby zapewnić filtrowanie połączeń i funkcje identyfikatora rozmówcy.
Do filtrowania połączeń używasz implementacji CallScreeningService. Wywołaj funkcję onScreenCall() w przypadku każdego nowego połączenia przychodzącego lub wychodzącego, gdy numeru nie ma na liście kontaktów użytkownika. Informacje o wywołaniu znajdziesz w obiekcie Call.Details. W szczególności funkcja getCallerNumberVerificationStatus() zawiera informacje o drugim numerze od dostawcy sieci.
Jeśli weryfikacja się nie powiodła, oznacza to, że połączenie jest z nieprawidłowego numeru lub może być 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 respondToCall(), aby poinformować system, jak ma odpowiedzieć na nowe wywołanie. Ta funkcja przyjmuje parametr CallResponse, który pozwala systemowi blokować wywołanie, odrzucać je tak, jak gdyby to robił użytkownik, lub je wyciszać. Możesz też sprawić, że system całkowicie pominie
dodawanie tego wywołania do rejestru połączeń urządzenia.
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ł ją prawidłowo aktywować, musisz zarejestrować w pliku manifestu implementację CallScreeningService, używając 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 transmisja ACTION_NEW_OUTGOING_CALL została wycofana i zastąpiona interfejsem API CallRedirectionService. CallRedirectionService udostępnia interfejsy, które służą do modyfikowania połączeń wychodzących wykonywanych przez platformę Androida. Aplikacje innych firm mogą na przykład 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ą poprawnie 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 przekierowania, aplikacja musi poprosić o rolę przekierowania połączeń z poziomu RoleManager. Spowoduje to pytanie użytkownika, czy chce zezwolić aplikacji na obsługę przekierowań połączeń. Jeśli nie otrzymasz tej roli, usługa przekierowania nie będzie używana.
Sprawdź, czy aplikacja ma tę rolę, gdy użytkownik ją uruchamia, aby w razie potrzeby poprosić o nią. Uruchamiasz intencję utworzoną przez intencję RoleManager, dlatego pamiętaj, aby zastąpić funkcję onActivityResult() w celu obsługi wyboru 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);
}
}
}
}