2013-06-20 10 views
29

Non riesco a eseguire run-as (o ndk-gdb) per il Galaxy S4 con Jellybean 4.2.2.run-as Il pacchetto 'a.b.c' è sconosciuto - Galaxy S4 Jellybean o Android 4.3

~ $ adb shell 
[email protected]:/ $ run-as a.b.c ls 
run-as: Package 'a.b.c' is unknown 

Non ci sono risposte multiple per questo problema per i dispositivi pre-ICS, ma quelli sembrano essere stati fissati in ICS.

Aggiornamento - Agosto 2013: Dopo essere apparso inizialmente sul Galaxy S4 con Jellybean 4.2.2, il problema di run-as sembra essere su tutti i dispositivi 4.3. Vedi questo Android bug.

Vedere il numero Android riconosciuto here.

Aggiornamento - Nov 2013: Google ha pubblicato il patches che corregge l'esecuzione come in Android 4.4.

+0

Solo per completezza ... il pacchetto è installato sul dispositivo? – CommonsWare

+0

Sì. Sono in grado di avviare l'applicazione con adb shell am start -n abc/{activity} –

+0

indizi su http://developer.samsung.com/forum/thread/ndk-debugging-with-gdb/77/178834, ma non è chiaro come cambiare ndk-gdb per i dispositivi non rooted. –

risposta

12

trovato il successo con l'aggiunta di questo per l'attività:

private void startGdbServer() { 
    try { 
     new ProcessBuilder() 
     .command(getFilesDir().getParent() + "/lib/gdbserver", "tcp:5039", "--attach" ,"" + android.os.Process.myPid()) 
     .redirectErrorStream(true) 
     .start(); 
    } catch (IOException e) { 
     Log.e(TAG, "IOException failed to start gdbserver"); 
    } 
} 

Poi ho avvolto startGdbServer in un servizio di Android e l'aggiornamento dello script NDK-gdb per avviare il server invece che il run-as comando.

Ecco l'aggiunta manifesta:

<service android:enabled="true" android:name="com.apportable.activity.GdbServerService" 
    android:label="@string/app_name" android:icon="@drawable/icon"> 
    <intent-filter > 
     <action android:name="apportable.FoundationTests.GdbServerService" /> 
    </intent-filter> 
</service> 

Ecco le relative variazioni NDK-gdb (in python):

remote_gdbserver = '/data/data/' + env['APPLICATION_IDENTIFIER'] + '/lib/gdbserver' 

    print "Attaching to pid " + pid 
    # Android 4.2 requires the --user 0 option. Earlier versions cannot have it 

    results = env.Execute([env['ADB'], 'shell', 'am']) 
    if "--user" in results: 
     user_option = "--user 0" 
    else: 
     user_option = "" 

    adb.AsyncShell(env, 'am startservice ' + user_option + ' -a ' + env['APPLICATION_IDENTIFIER'] + '.GdbServerService --es gdbserver_name ' + remote_gdbserver + ' --ei gdbserver_port ' + str(env['ANDROID_REMOTE_DEBUG_PORT'])) 

    # HACK: magic number. ensure the gdb server is actually up and running 
    time.sleep(2) # 1 is usually enough, but not always, like after reboot or with heavy system load 

    adb.Forward(env, env['ANDROID_LOCAL_DEBUG_PORT'], env['ANDROID_REMOTE_DEBUG_PORT']) 

    adb.Pull(env, process_path, '/system/bin/app_process') 

    setup_path = '"' + setup_path + '"' 

    if env['CGDB'] is not None: 
     cmd = [env['CGDB'], '-d', env['GDB'], '--', '-x', setup_path] 
    else: 
     cmd = [env['GDB'], '-x', setup_path] 

    env.RunCommand(cmd) 
+0

Avere l'app fuori da un server ssh in esecuzione come id utente potrebbe darti un discreto grado di flessibilità per avviare successivamente gdbserver indipendentemente dallo stato dell'app. –

+0

Grazie Chris. Ho finito con il wrapping di startGdbServer in un servizio Android e l'aggiornamento dello script ndk-gdb per avviare il server invece del comando run-as. Finora, questo sembra rendere i dispositivi Samsung buggy come debuggabili come altro –

+0

Quando dici "aggiungendo questo all'attività", intendi che l'hai aggiunto all'attività esistente nella tua app? O hai creato una nuova app solo per avviare il server GDB? Puoi chiarire come lo hai avvolto in un servizio Android e quali modifiche hai apportato allo script 'ndk-gdb'? –

0

Una cosa che ha finito per fissare il mio Nexus 7 dal fare questo, è installazione di diversi driver ADB. Ho anche re-flashato il dispositivo (anche se non sono sicuro che sia stato effettivamente risolto). Come accennato in un'altra risposta (la mia) era che sarebbe stato necessario fare il tifo - quando in realtà non è stato d'aiuto nemmeno nel mio caso.

-1

C'è un problema noto con l'ultima versione di Nexus 7. È sufficiente effettuare il downgrade a 4.2 (o ottenere 4.3 senza il mini-aggiornamento) e si dovrebbe andare bene. C'è una discussione qui a questo proposito:

http://code.google.com/p/android/issues/detail?id=58373

+0

Come già descritto nella domanda. –

0

Nel mio caso si trattava di un problema di nucleo app:

[email protected]:/ $ run-as com.android.phone transfer_bugreport ls 
run-as: Package 'com.android.phone' is unknown 

pacchetto che hanno in AndroidManifest.xml in <maninfest> tag coreApp="true" sono esclusi dalla /data/system/packages.list e quindi davvero sconosciuto per run-as.