34

I cannot run run-as (or ndk-gdb) for the Galaxy S4 running Jellybean 4.2.2. 

~  $ adb shell
shell@android:/ $ run-as a.b.c ls
run-as: Package 'a.b.c' is unknown

There are multiple answers for this issue for pre-ICS devices, but those seem to have been fixed in ICS.

Update - Aug 2013: After initially appearing on the Galaxy S4 with Jellybean 4.2.2, the run-as issue now seems to be on all 4.3 devices. See this Android bug.

See the acknowledged Android issue here.

Update - Nov 2013: Google posted the patches that fix run-as in Android 4.4.

Paul Beusterien
  • 21,795
  • 5
  • 61
  • 115

4 Answers4

13

Found success by adding this to the activity:

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");
    }
}

Then I wrapped startGdbServer in an Android service and updating the ndk-gdb script to start the server instead of the run-as command.

Here's the manifest addition:

<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>

Here are the relevant ndk-gdb changes (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)
Paul Beusterien
  • 21,795
  • 5
  • 61
  • 115
  • Having the app fork off an ssh server running as its user id might give you a fair degree of flexibility for subsequently starting gdbserver independent of the state of the app. – Chris Stratton Jun 21 '13 at 19:51
  • Thanks Chris. I ended up wrapping startGdbServer in an Android service and updating the ndk-gdb script to start the server instead of the run-as command. So far, this seems to make the buggy Samsung devices as debuggable as anything else – Paul Beusterien Jun 22 '13 at 00:24
  • When you say "by adding this to the activity", do you mean you added this to the existing activity in your app? Or did you create a new app just to start the GDB server? Can you clarify how you wrapped it in an Android service and which changes you made to the `ndk-gdb` script? – Adam Rosenfield Aug 13 '13 at 22:11
  • Wait I don't see any lines like that in ndk-gdb.py. That is the file we are supposed to modify correct? Or am I missing something? – Dmacpro Feb 07 '14 at 22:07
  • In the current SDK release (1.1.03), the code sequence starts at line 770 of .apportable/SDK/site_scons/android/sdk.py – Paul Beusterien Feb 08 '14 at 06:07
  • @PaulBeusterien Which file am I supposed to update? The ndk-gdb.py? – bbosak Mar 07 '14 at 13:46
  • @IDWMaster - if you're not using the Apportable SDK, you either need to make a similar change to the NDK's ndk-gdb script or completely replace it with your script. The code sample I provided will help, but you still need to do more adaptation. – Paul Beusterien Mar 07 '14 at 15:13
  • @PaulBeusterien Ended up just rooting the phone -- thanks though. – bbosak May 13 '14 at 04:18
  • Can't seem to find the `sdk.py` you mention on the Apportable site. Could you please give the full link to that file (or the archive/repo where it's located)? – Ruslan Sep 28 '17 at 16:57
  • @Ruslan - There is no longer a publicly available Apportable sdk. I'll remove the reference from the answer. – Paul Beusterien Sep 29 '17 at 16:38
0

One thing that ended up fixing my Nexus 7 from doing this, is installing different ADB drivers. I also re-flashed the device (though I am not sure if this was indeed what fixed it). As mentioned in another answer (mine) was that rooting would be required - when in fact, it did not help in my case either.

Mike Weir
  • 2,858
  • 1
  • 26
  • 44
0

In my case it was a problem of core app:

shell@android:/ $ run-as com.android.phone transfer_bugreport ls
run-as: Package 'com.android.phone' is unknown

Package which have in AndroidManifest.xml in <maninfest> tag coreApp="true" are excluded from /data/system/packages.list and thus really unknown for run-as.

pevik
  • 3,746
  • 3
  • 27
  • 37
-1

There is a known issue with the latest version of Nexus 7. Simply downgrade to 4.2 (or get 4.3 without the mini-update) and you should be fine. There's a discussion here about it:

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

Mike Weir
  • 2,858
  • 1
  • 26
  • 44