tns debug android --debug-brk broken

[NathanaelA]

Did you verify this is a real problem by searching

yes - #2550 seems to be related, but I don't understand why you would remove it from help...

Tell us about the problem

TNS on android doesn't seem to support the debug-brk command anymore. This used to work, and still works on iOS. It is still very needed functionality, for dealing with startup issues...

Which platform(s) does your issue occur on?

Broken on Android only, iOS works great.

Please provide the following version numbers that your issue occurs with:

2.5.4 and 3.0.0.rc.2

Please tell us how to recreate the issue in as much detail as possible.

tns debug android --debug-brk

Is there code involved? If so, please share the minimal amount of code needed to recreate the problem.

Nope.

[petekanev]

Hey @NathanaelA

The --debug-brk parameter is indeed not supported when debugging Android applications (2.5 and up). This is due to changes in the android runtime and the transition from node-inspector to the recommended v8-inspector, we can no longer force open an inspector tab and break at the earliest convenience (break at the first line of the first evaluated script), and instead need to ask developers to navigate to open the chrome devtools manually, at which point a handful of scripts would have executed already.

Ideally the V8 API will be used to break immediately when the first script has been parsed and wait for user action.

At the moment though a possible implementation is to pause the application on startup for several seconds as soon as the V8 VM has been initialized and listen for incoming Chrome DevTools connections.

[dtopuzov]

@Pip3r4o Can we remove --debug-brk from tns debug android --help?

[petekanev]

@dtopuzov Yes, certainly! It's misleading sitting there if we don't currently support the flag.

[hshristov]

I agree with @NathanaelA here. This was working (and it is still working on iOS) so better option is to fix it instead of removing the flag from --help.

[pkoleva]

Hey, @NathanaelA,

We have a fix in the latest @next of the android runtime. You could try it out and see if it covers your scenario :)