Can't get it to work on main application about stetho

[jasta]

We have a bug today where we don't refresh the available databases or SharedPreferences after you click Inspect. Instead, try going into settings, modifying a few things, and then clicking the APOD button on the main activity. After, click "Inspect" and you should see the resources appear.

This is something we'd like to address of course, but it will require jumping through a few hoops (namely FileObserver and a way to simulate page navigation to get new security origins). Pull requests welcome! :)

[jasta]

Prefer to re-open as a separate issue regarding dynamically refreshing databases and shared prefs.

[Tolriq]

Well the sample does work and I've seen the known issue :)

But the problem is that it does never work my application, no welcome message, error message in red and nothing available at all (databases and everything is up before inspect of course)

[jasta]

Oh I see. The method not implemented messages are harmless and can be ignored. Not seeing the usual Stetho banner is troubling. Can you confirm that the stetho-sample does indeed work? If yes, I can only imagine that something happened within your app that would have blocked the server worker threads from proceeding. Perhaps a debugger breakpoint?

[Tolriq]

Well my english is really bad :(

So yes the sample works perfectly (everything).

On my application it does not work when connecting I have an error message in Chrome :

Not implemented: Profiler.setSamplingInterval

Instead of the welcome banner.

But on the application logcat I have all correct messages with onConnect the messages about not implemented that does not matter (but I did know that) and I have the disconnect messages too when I close the chrome inspect window.

So no error message, from the logs server is started and talks but nothing in it.

[jasta]

Can you take a screenshot of exactly what the Console tab looks like? It is starting to sound like you're inspecting the inspector itself somehow (which is what we do often to troubleshoot issues with our implementation)

[Tolriq]

Clicking the inspect of sample open a new window that works.

Clicking the inspect of Yatse open this empty one.

[jasta]

Hmmmmm. You shouldn't even be seeing that "Not implemented" message in the console. I want to ask a bunch of questions about what version of Chrome and all that, but if stetho-sample works in the same session then I am really at a loss for what could possibly be going on. My normal procedure for debugging this stuff locally is fairly involved, requiring that you bring up wireshark, sniff the loopback device with the capture filter port 5037, then filter by websocket and scrutinize the traffic being sent by Stetho.

If I could repro somehow I'm pretty sure we could get to the bottom of it with the above workflow, but given that the sample works for you I'm at a loss. I'd be happy to help guide you through our debug process though if you're interested in helping us figure out what could be going on here.

[Tolriq]

Well I do have not thousand of times but I'll try to find time to help on that, as having direct access to preferences and databases quickly and without root will make me win lot's of time.

I'll try to gather the traces and upload the pcap file tomorrow, it's 11PM here :)

[Tolriq]

Here's the captures :

http://yatse.leetzone.org/Images/stetho-notworking.pcap
http://yatse.leetzone.org/Images/stetho-working.pcap

They are filtered on websocket and http.

For the record Windows wireshark does not support loopback needs RawCap as external tool.

[jasta]

The captures look fairly normal but do seem to indicate that something went wrong and caused the Stetho thread to hang. Does logcat have anything interesting to say by chance? Also, attaching a debugger and seeing what the Stetho worker threads are up to would be interesting. Or, perhaps more conveniently, run adb shell run-as mypackage kill -3 mypid then take a look at /data/anr/traces.txt. See here for more info on this trick: http://elliotth.blogspot.com/2012/08/how-to-read-dalvik-sigquit-output.html

[Tolriq]

Nothing in logcat at all :(

Here's the stack traces after clicking inspect on yatse that do not work: http://yatse.leetzone.org/Images/stetho-traces.txt

And here the same stack from sample that work :
http://yatse.leetzone.org/Images/stetho-traces-sample.txt

They look pretty same to me.

[jasta]

Hehe, I think I have a clue here. Are you by chance using proguard on your debug builds and/or using Stetho on a release build? I'm almost positive that proguard is obfuscating the class and/or method names of the ChromeDevtoolsDomain methods which will break the protocol implementation.

I recommend disabling proguard for debug builds if you can. Otherwise, try adding the following proguard rules:

-keepnames class com.facebook.stetho.**

You can verify this worked using:

dexdump MyApp.apk | grep 'Class desc' | grep stetho

And look for names like Network, Runtime, DOMStorage, etc.

[Tolriq]

Arf yes totally forget that :( I use proguard in debug due to dex limits.

There's no renaming or optimizations but I guess you use some reflection and proguard removes some needed things.

Fixed with : -keep class com.facebook.stetho.** {*;}

Maybe there's better way by just forcing keep only for what extends ChromeDevtoolsDomain but I'm not a proguard expert to go this deep and it does not really matter since it's only for debug anyway.

Thanks for the help and maybe worth adding a line somewhere about that.

[jasta]

If I may, there is now split dex support natively part of the build toolchain. You may want to check it out as a way of improving your build times. Also to confirm, yes we do use reflection to implement the devtools protocol. The performance hit is taken only after the first peer connects however.

[Tolriq]

Thanks but it does trigger more problems than solutions :) Only more or less solid with native one on android 5.X but my dev process includes work on older devices due to so many .... bugs.

[Tolriq]

Since not sure it does need a new issue, but is it normal that delete or update queries does not return anything like a confirmation message ?

[jasta]

@Tolriq actually the multi-dex solution has backwards compatibility to pre 5.0 devices: https://developer.android.com/tools/building/multidex.html#mdex-pre-l

As for update or delete queries in SQLite, AFAIK this is just how the UI was designed to work. There may be some opportunity for us to display status in some way, but I am not immediately aware of how. If you're curious, the way we usually explore what the UI is capable of first is to attach the debugger to a legitimate web app using Chrome on Android and play around with the feature set. Whatever is available there is available for us :)

[jasta]

@Tolriq please do file a new issue for that though, this one is getting hard to track :)

[Tolriq]

Ok I'll open a new one.

And for pre L yes it's supported but not really for production and real life that why I talked about more problems than solutions.

https://developer.android.com/tools/building/multidex.html#limitations

My app was touched by the last 3 ones, and now that I target 14 only the last 2 ones, but too much hassles currently.

I'll get there when I target API 16 and most animations and rendering problems are out of my way :)

[Wavesonics]

If you are using progaurd you may also need to force Support v4 to be kept:

-dontwarn android.support.v4.**
-keep class android.support.v4.** { ; }
-keep interface android.support.v4.* { *; }

[gbero]

Might be useful to add this info on the documentation page no ?

[jasta]

Yes, I'm going to look at this today. We have a need for a few small wiki sections to talk about this stuff, just haven't gotten around to it yet :)

[gbero]

👍

[thuytrinh]

👍