You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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 ?
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.
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
@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.
Activity
me-to-you93 commentedon Oct 19, 2022
Same problem here, would be interested by this option !
markemer commentedon Mar 6, 2023
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.
Dexus commentedon Sep 27, 2024
To bad that this never found its way to the code...
piotr-cz commentedon Oct 24, 2024
The timeout argument would have to be read here:
native-run/src/android/run.ts
Line 35 in a6e5605
and passed all the way to here:
native-run/src/android/utils/adb.ts
Line 358 in a6e5605
piotr-cz commentedon Oct 25, 2024
For me, it looks like that:
startActivityfunction executes ADB command which longer than 5sexecAdbfunction times outpiotr-cz commentedon Oct 25, 2024
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
Dexus commentedon Oct 25, 2024
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
thoro23 commentedon Nov 12, 2024
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.
xEverth commentedon Dec 25, 2024
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
jordus100 commentedon Sep 18, 2026
@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 pushoperation 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.
jordus100 commentedon Oct 13, 2026
@markemer Hi, could I get any feedback on my PR pertinent to this issue?
#407