android - registro - no puedo contestar llamadas en mi huawei

¿Cómo se pueden responder las llamadas entrantes mediante programación en Android 5.0(Lollipop)?

Question

Como estoy tratando de crear una pantalla personalizada para las llamadas entrantes, estoy tratando de responder programáticamente una llamada entrante. Estoy usando el siguiente código pero no funciona en Android 5.0.

// Simulate a press of the headset button to pick up the call
Intent buttonDown = new Intent(Intent.ACTION_MEDIA_BUTTON);
buttonDown.putExtra(Intent.EXTRA_KEY_EVENT, new KeyEvent(KeyEvent.ACTION_DOWN, KeyEvent.KEYCODE_HEADSETHOOK));
context.sendOrderedBroadcast(buttonDown, "android.permission.CALL_PRIVILEGED");
// froyo and beyond trigger on buttonUp instead of buttonDown
Intent buttonUp = new Intent(Intent.ACTION_MEDIA_BUTTON);
buttonUp.putExtra(Intent.EXTRA_KEY_EVENT, new KeyEvent(KeyEvent.ACTION_UP, KeyEvent.KEYCODE_HEADSETHOOK));
context.sendOrderedBroadcast(buttonUp, "android.permission.CALL_PRIVILEGED");

Answer 1

Actualización con Android 8.0 Oreo

A pesar de que la pregunta se hizo originalmente para el soporte de Android L, las personas todavía parecen estar respondiendo a esta pregunta y respuesta, por lo que vale la pena describir las mejoras introducidas en Android 8.0 Oreo. Los métodos compatibles con versiones anteriores todavía se describen a continuación.

¿Qué cambió?

A partir de Android 8.0 Oreo , el grupo de permisos PHONE también contiene el permiso ANSWER_PHONE_CALLS . Como sugiere el nombre del permiso, retenerlo permite que su aplicación acepte mediante programación llamadas entrantes a través de una llamada API adecuada sin ningún tipo de pirateo en el sistema utilizando la reflexión o la simulación del usuario.

¿Cómo utilizamos este cambio?

Debe verificar la versión del sistema en tiempo de ejecución si admite versiones anteriores de Android para poder encapsular esta nueva llamada API mientras mantiene el soporte para esas versiones anteriores de Android. Debe seguir solicitando permisos en tiempo de ejecución para obtener ese nuevo permiso durante el tiempo de ejecución, como es estándar en las versiones más recientes de Android.

Después de obtener el permiso, su aplicación simplemente tiene que llamar al método acceptRingingCall de TelecomManager . Una invocación básica tiene el siguiente aspecto:

TelecomManager tm = (TelecomManager) mContext
.getSystemService(Context.TELECOM_SERVICE);
if (tm == null) {
// whether you want to handle this is up to you really
throw new NullPointerException("tm == null");
}
tm.acceptRingingCall();

Método 1: TelephonyManager.answerRingingCall ()

Para cuando tienes control ilimitado sobre el dispositivo.

¿Que es esto?

Hay TelephonyManager.answerRingingCall (), que es un método interno oculto. Funciona como un puente para ITelephony.answerRingingCall () que se ha discutido en las interwebs y parece prometedor al principio. No está disponible en 4.4.2_r1 ya que se introdujo solo en commit 83da75d para Android 4.4 KitKat ( línea 1537 en 4.4.3_r1 ) y luego "reintroducido" en commit f1e1e77 para Lollipop ( línea 3138 en 5.0.0_r1 ) debido a cómo El árbol de Git fue estructurado. Esto significa que, a menos que solo admita dispositivos con Lollipop, lo que probablemente sea una mala decisión en función de la pequeña participación de mercado que tiene en este momento, aún debe proporcionar métodos alternativos si sigue esta ruta.

¿Cómo usaríamos esto?

Como el método en cuestión está oculto del uso de las aplicaciones SDK, debe usar la reflection para examinar dinámicamente y usar el método durante el tiempo de ejecución. Si no está familiarizado con la reflexión, puede leer rápidamente ¿Qué es la reflexión y por qué es útil? . También puede profundizar en los detalles en Trail: The Reflection API si está interesado en hacerlo.

¿Y cómo se ve eso en el código?

// set the logging tag constant; you probably want to change this
final String LOG_TAG = "TelephonyAnswer";
TelephonyManager tm = (TelephonyManager) mContext
.getSystemService(Context.TELEPHONY_SERVICE);
try {
if (tm == null) {
// this will be easier for debugging later on
throw new NullPointerException("tm == null");
}
// do reflection magic
tm.getClass().getMethod("answerRingingCall").invoke(tm);
} catch (Exception e) {
// we catch it all as the following things could happen:
// NoSuchMethodException, if the answerRingingCall() is missing
// SecurityException, if the security manager is not happy
// IllegalAccessException, if the method is not accessible
// IllegalArgumentException, if the method expected other arguments
// InvocationTargetException, if the method threw itself
// NullPointerException, if something was a null value along the way
// ExceptionInInitializerError, if initialization failed
// something more crazy, if anything else breaks
// TODO decide how to handle this state
// you probably want to set some failure state/go to fallback
Log.e(LOG_TAG, "Unable to use the Telephony Manager directly.", e);
}

¡Esto es demasiado bueno para ser verdad!

En realidad, hay un pequeño problema. Este método debería ser completamente funcional, pero el administrador de seguridad quiere que las personas que llaman tengan android.permission.MODIFY_PHONE_STATE . Este permiso está en el ámbito de las características del sistema solo parcialmente documentadas, ya que no se espera que terceros lo toquen (como puede ver en la documentación). Puede intentar agregar un <uses-permission> pero no servirá de nada porque el nivel de protección para este permiso es el sistema de firma ( consulte la línea 1201 de core / AndroidManifest en 5.0.0_r1 ).

Puede leer el problema 34785: Actualice la documentación de android: protectionLevel que se creó en 2012 para ver que nos faltan detalles sobre la "sintaxis de tubería" específica, pero al experimentar, parece que debe funcionar como un "Y", lo que significa todo los indicadores especificados deben cumplirse para que se otorgue el permiso. Trabajando bajo esa suposición, significaría que debe tener su aplicación:

1. Instalado como una aplicación del sistema.

   Esto debería estar bien y podría lograrse pidiéndoles a los usuarios que instalen usando un ZIP en la recuperación, como al rootear o instalar aplicaciones de Google en ROM personalizadas que aún no las tienen empaquetadas.

2. Firmado con la misma firma que frameworks / base, también conocido como sistema, también conocido como ROM.

   Aquí es donde surgen los problemas. Para hacer esto, debe tener las manos en las teclas utilizadas para firmar frameworks / base. No solo tendría que obtener acceso a las claves de Google para las imágenes de fábrica de Nexus, sino que también tendría que tener acceso a todas las demás claves de OEM y desarrolladores de ROM. Esto no parece plausible, por lo que puede hacer que su aplicación se firme con las claves del sistema, ya sea haciendo una ROM personalizada y pidiéndoles a sus usuarios que cambien a ella (lo que podría ser difícil) o encontrando un exploit con el cual se pueda omitir el nivel de protección de permisos (que también puede ser difícil).

Además, este comportamiento parece estar relacionado con el problema 34792: Android Jelly Bean / 4.1: android.permission.READ_LOGS ya no funciona, ya que utiliza el mismo nivel de protección junto con un indicador de desarrollo no documentado.

Trabajar con el TelephonyManager suena bien, pero no funcionará a menos que obtenga el permiso apropiado que no es tan fácil de hacer en la práctica.

¿Qué pasa con el uso de TelephonyManager de otras maneras?

Lamentablemente, parece requerir que mantengas android.permission.MODIFY_PHONE_STATE para usar las herramientas geniales, lo que a su vez significa que tendrás dificultades para acceder a esos métodos.

Método 2: llamada de servicio CÓDIGO DE SERVICIO

Para cuándo puede probar que la compilación que se ejecuta en el dispositivo funcionará con el código especificado.

Sin poder interactuar con el Administrador de telefonía, también existe la posibilidad de interactuar con el servicio a través del ejecutable del service .

¿Como funciona esto?

Es bastante simple, pero hay menos documentación sobre esta ruta que otras. Sabemos con certeza que el ejecutable toma dos argumentos: el nombre del servicio y el código.

• El nombre del servicio que queremos usar es teléfono .

  Esto se puede ver ejecutando la service list .

• El código que queremos usar parece haber sido 6 pero ahora parece ser 5 .

  Parece que se ha basado en IBinder.FIRST_CALL_TRANSACTION + 5 para muchas versiones ahora (de 1.5_r4 a 4.4.4_r1 ) pero durante las pruebas locales el código 5 funcionó para responder una llamada entrante. Como Lollipo es una actualización masiva en todos lados, es comprensible que las partes internas también se cambien aquí.

Esto resulta con un comando de service call phone 5 .

¿Cómo utilizamos esto programáticamente?

Java

El siguiente código es una implementación aproximada hecha para funcionar como una prueba de concepto. Si realmente desea seguir adelante y usar este método, probablemente desee consultar las pautas para el uso de su sin problemas y posiblemente cambiar al libsuperuser más desarrollado por Chainfire .

try {
Process proc = Runtime.getRuntime().exec("su");
DataOutputStream os = new DataOutputStream(proc.getOutputStream());
os.writeBytes("service call phone 5/n");
os.flush();
os.writeBytes("exit/n");
os.flush();
if (proc.waitFor() == 255) {
// TODO handle being declined root access
// 255 is the standard code for being declined root for SU
}
} catch (IOException e) {
// TODO handle I/O going wrong
// this probably means that the device isn''t rooted
} catch (InterruptedException e) {
// don''t swallow interruptions
Thread.currentThread().interrupt();
}

Manifiesto

<!-- Inform the user we want them root accesses. -->
<uses-permission android:name="android.permission.ACCESS_SUPERUSER"/>

¿Esto realmente requiere acceso de root?

Lamentablemente, eso parece. Puede intentar usar Runtime.exec en él, pero no tuve suerte con esa ruta.

¿Qué tan estable es esto?

Me alegra que lo hayas preguntado. Debido a que no está documentado, esto puede romperse en varias versiones, como lo ilustra la aparente diferencia de código anterior. El nombre del servicio probablemente debería permanecer en el teléfono en varias compilaciones, pero por lo que sabemos, el valor del código puede cambiar en varias compilaciones de la misma versión (modificaciones internas por, digamos, la máscara del OEM) rompiendo a su vez el método utilizado. Por lo tanto, vale la pena mencionar que la prueba se realizó en un Nexus 4 (mako / occam). Yo personalmente le aconsejaría que no use este método, pero como no puedo encontrar un método más estable, creo que esta es la mejor opción.

Método original: intenciones del código clave del auricular

Para los momentos en que tienes que conformarte.

La siguiente sección fue fuertemente influenciada por esta respuesta de Riley C.

El método de intención simulada del auricular publicado en la pregunta original parece transmitirse tal como cabría esperar, pero no parece cumplir el objetivo de responder la llamada. Si bien parece haber un código en el lugar que debería manejar esas intenciones, simplemente no se les importa, lo que tiene que significar que debe haber algún tipo de nuevas contramedidas contra este método. El registro tampoco muestra nada de interés y personalmente no creo que valga la pena buscar en la fuente de Android para esto solo debido a la posibilidad de que Google introduzca un ligero cambio que rompa fácilmente el método utilizado de todos modos.

¿Hay algo que podamos hacer ahora?

El comportamiento se puede reproducir de manera consistente utilizando el ejecutable de entrada. Toma un argumento de código KeyEvent.KEYCODE_HEADSETHOOK , para el cual simplemente pasamos KeyEvent.KEYCODE_HEADSETHOOK . El método ni siquiera requiere acceso a la raíz, por lo que es adecuado para casos de uso común en el público en general, pero hay un pequeño inconveniente en el método: el evento de presión del botón del auricular no se puede especificar para requerir un permiso, lo que significa que funciona como un verdadero al presionar un botón y burbujear a través de toda la cadena, lo que a su vez significa que debe tener cuidado con la hora de simular la presión del botón como podría, por ejemplo, activar el reproductor de música para iniciar la reproducción si nadie más de mayor prioridad está listo para manejar el evento.

¿Código?

new Thread(new Runnable() {
@Override
public void run() {
try {
Runtime.getRuntime().exec("input keyevent " +
Integer.toString(KeyEvent.KEYCODE_HEADSETHOOK));
} catch (IOException e) {
// Runtime.exec(String) had an I/O problem, try to fall back
String enforcedPerm = "android.permission.CALL_PRIVILEGED";
Intent btnDown = new Intent(Intent.ACTION_MEDIA_BUTTON).putExtra(
Intent.EXTRA_KEY_EVENT, new KeyEvent(KeyEvent.ACTION_DOWN,
KeyEvent.KEYCODE_HEADSETHOOK));
Intent btnUp = new Intent(Intent.ACTION_MEDIA_BUTTON).putExtra(
Intent.EXTRA_KEY_EVENT, new KeyEvent(KeyEvent.ACTION_UP,
KeyEvent.KEYCODE_HEADSETHOOK));
mContext.sendOrderedBroadcast(btnDown, enforcedPerm);
mContext.sendOrderedBroadcast(btnUp, enforcedPerm);
}
}
}).start();

tl; dr

Hay una buena API pública para Android 8.0 Oreo y versiones posteriores.

No hay una API pública anterior a Android 8.0 Oreo. Las API internas están fuera de los límites o simplemente sin documentación. Debe proceder con precaución.

Answer 2

La solución totalmente funcional se basa en el código @Valter Strods.

Para que funcione, debe mostrar una actividad (invisible) en la pantalla de bloqueo donde se ejecuta el código.

AndroidManifest.xml

<uses-permission android:name="android.permission.WAKE_LOCK" />
<uses-permission android:name="android.permission.DISABLE_KEYGUARD" />
<activity android:name="com.mysms.android.lib.activity.AcceptCallActivity"
android:launchMode="singleTop"
android:excludeFromRecents="true"
android:taskAffinity=""
android:configChanges="orientation|keyboardHidden|screenSize"
android:theme="@style/Mysms.Invisible">
</activity>

Actividad de aceptar llamada

package com.mysms.android.lib.activity;
import android.app.Activity;
import android.app.KeyguardManager;
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
import android.content.IntentFilter;
import android.media.AudioManager;
import android.os.Build;
import android.os.Bundle;
import android.telephony.TelephonyManager;
import android.view.KeyEvent;
import android.view.WindowManager;
import org.apache.log4j.Logger;
import java.io.IOException;
public class AcceptCallActivity extends Activity {
private static Logger logger = Logger.getLogger(AcceptCallActivity.class);
private static final String MANUFACTURER_HTC = "HTC";
private KeyguardManager keyguardManager;
private AudioManager audioManager;
private CallStateReceiver callStateReceiver;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
keyguardManager = (KeyguardManager) getSystemService(Context.KEYGUARD_SERVICE);
audioManager = (AudioManager) getSystemService(Context.AUDIO_SERVICE);
}
@Override
protected void onResume() {
super.onResume();
registerCallStateReceiver();
updateWindowFlags();
acceptCall();
}
@Override
protected void onPause() {
super.onPause();
if (callStateReceiver != null) {
unregisterReceiver(callStateReceiver);
callStateReceiver = null;
}
}
private void registerCallStateReceiver() {
callStateReceiver = new CallStateReceiver();
IntentFilter intentFilter = new IntentFilter();
intentFilter.addAction(TelephonyManager.ACTION_PHONE_STATE_CHANGED);
registerReceiver(callStateReceiver, intentFilter);
}
private void updateWindowFlags() {
if (keyguardManager.inKeyguardRestrictedInputMode()) {
getWindow().addFlags(
WindowManager.LayoutParams.FLAG_DISMISS_KEYGUARD |
WindowManager.LayoutParams.FLAG_TURN_SCREEN_ON |
WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED);
} else {
getWindow().clearFlags(
WindowManager.LayoutParams.FLAG_DISMISS_KEYGUARD |
WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON |
WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED);
}
}
private void acceptCall() {
// for HTC devices we need to broadcast a connected headset
boolean broadcastConnected = MANUFACTURER_HTC.equalsIgnoreCase(Build.MANUFACTURER)
&& !audioManager.isWiredHeadsetOn();
if (broadcastConnected) {
broadcastHeadsetConnected(false);
}
try {
try {
logger.debug("execute input keycode headset hook");
Runtime.getRuntime().exec("input keyevent " +
Integer.toString(KeyEvent.KEYCODE_HEADSETHOOK));
} catch (IOException e) {
// Runtime.exec(String) had an I/O problem, try to fall back
logger.debug("send keycode headset hook intents");
String enforcedPerm = "android.permission.CALL_PRIVILEGED";
Intent btnDown = new Intent(Intent.ACTION_MEDIA_BUTTON).putExtra(
Intent.EXTRA_KEY_EVENT, new KeyEvent(KeyEvent.ACTION_DOWN,
KeyEvent.KEYCODE_HEADSETHOOK));
Intent btnUp = new Intent(Intent.ACTION_MEDIA_BUTTON).putExtra(
Intent.EXTRA_KEY_EVENT, new KeyEvent(KeyEvent.ACTION_UP,
KeyEvent.KEYCODE_HEADSETHOOK));
sendOrderedBroadcast(btnDown, enforcedPerm);
sendOrderedBroadcast(btnUp, enforcedPerm);
}
} finally {
if (broadcastConnected) {
broadcastHeadsetConnected(false);
}
}
}
private void broadcastHeadsetConnected(boolean connected) {
Intent i = new Intent(Intent.ACTION_HEADSET_PLUG);
i.addFlags(Intent.FLAG_RECEIVER_REGISTERED_ONLY);
i.putExtra("state", connected ? 1 : 0);
i.putExtra("name", "mysms");
try {
sendOrderedBroadcast(i, null);
} catch (Exception e) {
}
}
private class CallStateReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
finish();
}
}
}

Estilo

<style name="Mysms.Invisible">
<item name="android:windowFrame">@null</item>
<item name="android:windowBackground">@android:color/transparent</item>
<item name="android:windowContentOverlay">@null</item>
<item name="android:windowNoTitle">true</item>
<item name="android:windowIsTranslucent">true</item>
<item name="android:windowAnimationStyle">@null</item>
</style>

¡Por fin llama a la magia!

Intent intent = new Intent(context, AcceptCallActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_ACTIVITY_CLEAR_TASK
| Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS);
context.startActivity(intent);

Answer 3

Para su información, si está interesado en cómo FINALIZAR una llamada en curso en Android O, Valter''s Method 1: TelephonyManager.answerRingingCall() funciona si cambia el método para invocar endCall .

Solo requiere el android.permission.CALL_PHONE permiso.

Aquí está el código:

// set the logging tag constant; you probably want to change this
final String LOG_TAG = "TelephonyAnswer";
public void endCall() {
TelephonyManager tm = (TelephonyManager) mContext
.getSystemService(Context.TELEPHONY_SERVICE);
try {
if (tm == null) {
// this will be easier for debugging later on
throw new NullPointerException("tm == null");
}
// do reflection magic
tm.getClass().getMethod("endCall").invoke(tm);
} catch (Exception e) {
// we catch it all as the following things could happen:
// NoSuchMethodException, if the answerRingingCall() is missing
// SecurityException, if the security manager is not happy
// IllegalAccessException, if the method is not accessible
// IllegalArgumentException, if the method expected other arguments
// InvocationTargetException, if the method threw itself
// NullPointerException, if something was a null value along the way
// ExceptionInInitializerError, if initialization failed
// something more crazy, if anything else breaks
// TODO decide how to handle this state
// you probably want to set some failure state/go to fallback
Log.e(LOG_TAG, "Unable to use the Telephony Manager directly.", e);
}
}

Answer 4

Ejecute el siguiente comando como root:

input keyevent 5

Más detalles sobre la simulación de eventos clave here .

Puede usar esta clase base que creé para ejecutar comandos como root desde su aplicación.

Answer 5

El siguiente es un enfoque alternativo que funcionó para mí. Envía el evento clave al servidor de telecomunicaciones directamente utilizando la API MediaController. Esto requiere que la aplicación tenga el permiso BIND_NOTIFICATION_LISTENER_SERVICE y se le BIND_NOTIFICATION_LISTENER_SERVICE permiso de notificación explícito del usuario:

@TargetApi(Build.VERSION_CODES.LOLLIPOP)
void sendHeadsetHookLollipop() {
MediaSessionManager mediaSessionManager = (MediaSessionManager) getApplicationContext().getSystemService(Context.MEDIA_SESSION_SERVICE);
try {
List<MediaController> mediaControllerList = mediaSessionManager.getActiveSessions
(new ComponentName(getApplicationContext(), NotificationReceiverService.class));
for (MediaController m : mediaControllerList) {
if ("com.android.server.telecom".equals(m.getPackageName())) {
m.dispatchMediaButtonEvent(new KeyEvent(KeyEvent.ACTION_UP, KeyEvent.KEYCODE_HEADSETHOOK));
log.info("HEADSETHOOK sent to telecom server");
break;
}
}
} catch (SecurityException e) {
log.error("Permission error. Access to notification not granted to the app.");
}
}

NotificationReceiverService.class en el código anterior podría ser solo una clase vacía.

import android.service.notification.NotificationListenerService;
public class NotificationReceiverService extends NotificationListenerService{
public NotificationReceiverService() {
}
}

Con la sección correspondiente en el manifiesto:

 <service android:name=".NotificationReceiverService" android:permission="android.permission.BIND_NOTIFICATION_LISTENER_SERVICE"
android:enabled="true" android:exported="true">
<intent-filter>
<action android:name="android.service.notification.NotificationListenerService" />
</intent-filter>

Dado que el objetivo del evento es explícito, esto probablemente debería evitar cualquier efecto secundario de activar el reproductor multimedia.

Nota: el servidor de telecomunicaciones puede no estar inmediatamente activo después del evento de llamada. Para que esto funcione de manera confiable, puede ser útil que la aplicación implemente MediaSessionManager.OnActiveSessionsChangedListener para monitorear cuándo el servidor de telecomunicaciones se activa, antes de enviar el evento.

Actualizar:

En Android O , uno necesita simular ACTION_DOWN antes de ACTION_UP , de lo contrario, lo anterior no tiene ningún efecto. es decir, se necesita lo siguiente:

m.dispatchMediaButtonEvent(new KeyEvent(KeyEvent.ACTION_DOWN, KeyEvent.KEYCODE_HEADSETHOOK));
m.dispatchMediaButtonEvent(new KeyEvent(KeyEvent.ACTION_UP, KeyEvent.KEYCODE_HEADSETHOOK));

Pero dado que una llamada oficial para contestar llamadas está disponible desde Android O (ver respuesta superior), puede que ya no sea necesario este truco, a menos que uno esté atascado con un nivel de compilación API anterior a Android O.

Answer 6

Gracias @notz la respuesta de está trabajando para mí en el Lolillop. Para mantener este código funcionando con el viejo SDK de Android, puede hacer este código:

if (Build.VERSION.SDK_INT >= 21) {
Intent answerCalintent = new Intent(context, AcceptCallActivity.class);
answerCalintent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK |
Intent.FLAG_ACTIVITY_CLEAR_TASK |
Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS);
context.startActivity(answerCalintent);
}
else {
if (telephonyService != null) {
try {
telephonyService.answerRingingCall();
}
catch (Exception e) {
answerPhoneHeadsethook();
}
}
} 

Answer 7

Para elaborar un poco sobre la respuesta de @Muzikant, y modificarlo un poco para que funcione un poco más limpio en mi dispositivo, intente input keyevent 79 , la constante para KeyEvent.KEYCODE_HEADSETHOOK . Muy a grandes rasgos:

 new Thread(new Runnable() {
@Override
public void run() {
try {
Runtime.getRuntime().exec( "input keyevent " + KeyEvent.KEYCODE_HEADSETHOOK );
}
catch (Throwable t) {
// do something proper here.
}
}
}).start();

Perdone las convenciones de codificación bastante malas, no estoy muy versado en llamadas Runtime.exec (). Tenga en cuenta que mi dispositivo no está rooteado, ni solicito privilegios de root.

El problema con este enfoque es que solo funciona bajo ciertas condiciones (para mí). Es decir, si ejecuto el hilo anterior desde una opción de menú que el usuario selecciona mientras suena una llamada, la llamada responde bien. Si lo ejecuto desde un receptor que monitorea el estado de las llamadas entrantes, se ignora por completo.

Por lo tanto, en mi Nexus 5 funciona bien para las respuestas dirigidas por el usuario y debería adaptarse al propósito de una pantalla de llamada personalizada. Simplemente no funcionará para ningún tipo de aplicaciones automatizadas de tipo control de llamadas.

También hay que tener en cuenta todas las advertencias posibles, incluido que esto también probablemente dejará de funcionar en una actualización o dos.

Answer 8

a través de los comandos de adb Cómo responder una llamada de adb

Tenga en cuenta que Android es Linux con una JVM masiva en el front-end. Puede descargar una aplicación de línea de comando y rootear el teléfono y ahora tiene una computadora y línea de comando Linux que hace todas las cosas normales. Ejecute scripts, incluso puede hacer ssh (truco de OpenVPN)

Answer 9

pruebe esto: primero agregue los permisos y luego use killCall () para colgar use answerCall () para responder la llamada

<uses-permission android:name="android.permission.READ_PHONE_STATE"></uses-permission>
<uses-permission android:name="android.permission.PROCESS_OUTGOING_CALLS"></uses-permission>
public void killCall() {
try {
TelephonyManager telephonyManager =
(TelephonyManager) getContext().getSystemService(Context.TELEPHONY_SERVICE);
Class classTelephony = Class.forName(telephonyManager.getClass().getName());
Method methodGetITelephony = classTelephony.getDeclaredMethod("getITelephony");
methodGetITelephony.setAccessible(true);
Object telephonyInterface = methodGetITelephony.invoke(telephonyManager);
Class telephonyInterfaceClass =
Class.forName(telephonyInterface.getClass().getName());
Method methodEndCall = telephonyInterfaceClass.getDeclaredMethod("endCall");
methodEndCall.invoke(telephonyInterface);
} catch (Exception ex) {
Log.d(TAG, "PhoneStateReceiver **" + ex.toString());
}
}
public void answerCall() {
try {
Runtime.getRuntime().exec("input keyevent " +
Integer.toString(KeyEvent.KEYCODE_HEADSETHOOK));
} catch (IOException e) {
answerRingingCallWithIntent();
}
}
public void answerRingingCallWithIntent() {
try {
Intent localIntent1 = new Intent(Intent.ACTION_HEADSET_PLUG);
localIntent1.addFlags(Intent.FLAG_ACTIVITY_NO_HISTORY);
localIntent1.putExtra("state", 1);
localIntent1.putExtra("microphone", 1);
localIntent1.putExtra("name", "Headset");
getContext().sendOrderedBroadcast(localIntent1, "android.permission.CALL_PRIVILEGED");
Intent localIntent2 = new Intent(Intent.ACTION_MEDIA_BUTTON);
KeyEvent localKeyEvent1 = new KeyEvent(KeyEvent.ACTION_DOWN, KeyEvent.KEYCODE_HEADSETHOOK);
localIntent2.putExtra(Intent.EXTRA_KEY_EVENT, localKeyEvent1);
getContext().sendOrderedBroadcast(localIntent2, "android.permission.CALL_PRIVILEGED");
Intent localIntent3 = new Intent(Intent.ACTION_MEDIA_BUTTON);
KeyEvent localKeyEvent2 = new KeyEvent(KeyEvent.ACTION_UP, KeyEvent.KEYCODE_HEADSETHOOK);
localIntent3.putExtra(Intent.EXTRA_KEY_EVENT, localKeyEvent2);
getContext().sendOrderedBroadcast(localIntent3, "android.permission.CALL_PRIVILEGED");
Intent localIntent4 = new Intent(Intent.ACTION_HEADSET_PLUG);
localIntent4.addFlags(Intent.FLAG_ACTIVITY_NO_HISTORY);
localIntent4.putExtra("state", 0);
localIntent4.putExtra("microphone", 1);
localIntent4.putExtra("name", "Headset");
getContext().sendOrderedBroadcast(localIntent4, "android.permission.CALL_PRIVILEGED");
} catch (Exception e2) {
e2.printStackTrace();
}
}

Answer 10

Cómo encender el altavoz después de contestar llamadas automáticamente.

Resolví mi problema anterior con setSpeakerphoneOn. Creo que vale la pena publicarlo aquí, ya que el caso de uso para contestar automáticamente una llamada telefónica a menudo también requeriría que el altavoz sea útil. Gracias de nuevo a todos en este hilo, qué trabajo tan increíble.

Esto funciona para mí en Android 5.1.1 en mi Nexus 4 sin ROOT. ;)

Permiso requerido:

<uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS"/>

Código Java:

// this means the phone has answered
if(state==TelephonyManager.CALL_STATE_OFFHOOK)
{
// try and turn on speaker phone
final Handler mHandler = new Handler();
mHandler.postDelayed(new Runnable() {
@Override
public void run() {
AudioManager audioManager = (AudioManager) localContext.getSystemService(Context.AUDIO_SERVICE);
// this doesnt work without android.permission.MODIFY_PHONE_STATE
// audioManager.setMode(AudioManager.MODE_IN_CALL);
// weirdly this works
audioManager.setMode(AudioManager.MODE_NORMAL); // this is important
audioManager.setSpeakerphoneOn(true);
// note the phone interface won''t show speaker phone is enabled
// but the phone speaker will be on
// remember to turn it back off when your done ;)
}
}, 500); // half a second delay is important or it might fail
}