Skip to content

Customize ADB commands timeout #259

Open

Description

@gaetanlgce

Hi,

On old devices, ADB invocation can be quite long to be executed, more than 5 seconds.
It could be useful to allow overriding the value of 5 seconds. (cf issue #5).

Currently, I edit the dist version of the file (https://github.com/ionic-team/native-run/blob/develop/src/android/utils/adb.ts#L469) in my node_modules to force another value of timeout.

Is there a proper way to pass a param for that. I don't use native-run directly but I use the ionic/cordova stack that use native-run. Maybe an environment variable ?

Activity

  1. me-to-you93 commented on Oct 19, 2022

    @me-to-you93

    Same problem here, would be interested by this option !

  2. markemer commented on Mar 6, 2023

    @markemer
    Member

    I'll look into this - seems like we could do this in a non-breaking way.

    I'm not sure when I can get to it - but I'll put it on my radar.

    If you are interested in helping I'd be happy to review any PR you'd post.

  3. Dexus commented on Sep 27, 2024

    @Dexus

    To bad that this never found its way to the code...

  4. piotr-cz commented on Oct 24, 2024

    @piotr-cz

    The timeout argument would have to be read here:

    export async function run(args: readonly string[]): Promise<void> {

    and passed all the way to here:

    export async function execAdb(sdk: SDK, args: string[], options: ExecADBOptions = {}): Promise<string> {

  5. piotr-cz commented on Oct 25, 2024

    @piotr-cz

    For me, it looks like that:

    • the startActivity function executes ADB command which longer than 5s
    • the execAdb function times out
    • retrying fails, as the first ADB command is still executing
    • app is deployed and started on device
    • native-run exits with an error
    npx capacitor run --live-reload --port 8100
    ...
    √ Running Gradle build in 4.87s
    × Deploying app-debug.apk to Pixel_9_API_35 - failed!
    [error] Selected hardware device emulator-5554
            Installing xxx\android\app\build\outputs\apk\debug\app-debug.apk...
            Starting application activity xxx/xxx.MainActivity...
            ADBs is unresponsive after 5000ms, killing server and retrying...
            Error: Command failed: C:\Users\xxx\AppData\Local\Android\Sdk\platform-tools\adb -s emulator-5554 shell am
            start -W -n xxx/xxx.MainActivity
            adb.exe: device offline
    
            at ChildProcess.exithandler (node:child_process:422:12)
            at ChildProcess.emit (node:events:517:28)
            at maybeClose (node:internal/child_process:1098:16)
            at ChildProcess._handle.onexit (node:internal/child_process:303:5)
    
  6. piotr-cz commented on Oct 25, 2024

    @piotr-cz

    I prepared PR #393 that increases timeout to 15_000 ms, because it works for my case.

    @gaetanlgce @me-to-you93 @Dexus please let me know in above PR which timeout duration works for you

  7. Dexus commented on Oct 25, 2024

    @Dexus

    I have patched it my own thanks to patch-package so I was able to set it to 30_000 that was working for me

  8. thoro23 commented on Nov 12, 2024

    @thoro23

    We have the same problem, the starting of the activity takes longer than 5s when deploying to an emulator. When deploying to a device it takes less than 5s and works fine.

    For now we patch it with patch-package like @Dexus suggested but a proper fix would be preferable.

  9. xEverth commented on Dec 25, 2024

    @xEverth

    Device offline and device still authorizing errors from ADB should be caught and retried on by native-run - increasing the timeout via environment variable or patch to startActivity just moves the issue slightly further without addressing it.
    Also native-run seems a little too trigger-happy with adb kill-server currently

  10. jordus100 commented on Sep 18, 2026

    @jordus100

    @xEverth I don't think you understand the full problem here. Some ADB commands simply take too long (for example on remote devices) and this is a different issue from simply handling the slowly changing ADB device state. For example if an adb push operation takes too long because of low bandwidth, simply retrying the operation will cause it to get stuck in a loop because it will hit the timeout each time. I think for cases like this, controlling the timeout with an env variable is entirely reasonable. It would enable each user to fine-tune the tradeoff between time and error sensitivity to their use case.
    Honestly, hardcoding timeout values in production software interacting directly with a rich variety of differently set up hardware is an interesting choice, to put it mildly.

  11. jordus100 commented on Oct 13, 2026

    @jordus100

    @markemer Hi, could I get any feedback on my PR pertinent to this issue?
    #407

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions