1. Are you ready for the Galaxy S20? Here is everything we know so far!

Using Logcat to Debug Screen

Discussion in 'Android Devices' started by AndyDroidBot, Apr 12, 2012.

  1. AndyDroidBot

    AndyDroidBot Member
    Thread Starter

    bads3ctor is the only user to have successfully gathered a Logcat dump to give definitive information regarding the "long-press and drag and drop" bug in this phone. Looking further into the issue and doing a little more reading, I don't think we've utilized Logcat to it's full potential and I also don't think the issue has anything to do with a broken digitizer or bad drivers (I suspect it's the way some firmware is compiled with the rom or kernel, ie: inputdispatcher.cpp)

    Using the "Log" class in ADB can be scary to new users, but is a life line for devs to debug and fix errors, it essentially is Android's built-in bug-finder.
    To learn a little more about what some of the Logcat "flags/switches" do you can read here:
    Running Logcat (Advanced way)
    and here
    Flags

    A developer at XDA, named Michael Perez, made an app to easily gather Logcat information (with many flags, and also supports kernel logging) specifically tailored to those of us who are not devs or power users.

    This application is called "LogThis" and can be found at the Play Store here:
    LogThis

    In the attatched youtube video, it gives a description of how to run and how to create an output, according to Michael Perez, once the app is running it collects data for around ~10 minutes, just long enough to minimize the app, go to the homescreen and try to drag an icon around until the error manifests itself again, and then go back to the app to collect the log.
     


    smith058 and ChoznJuan like this.

    1. Download the Forums for Android™ app!


      Download

       
  2. BLuFeNiX

    BLuFeNiX Well-Known Member

    What application tag should I enter?
    Do you need All logs, Debug, Information, Warnings, or Errors only?
    What about Android runtime errors?

    I know I'd probably be safe if I just enabled everything, but that can make finding the problem harder. If we want users to post logs, we need simple step-by-step instructions of what to do.
     
    smith058 likes this.
  3. AndyDroidBot

    AndyDroidBot Member
    Thread Starter

    As per request here is a simple-to-follow written guide.
    This will function as a "How-to" for generating logs for easy viewing.
    This application does not require the phone to have root privileges. Logs can be generated without making any modifications to your phone (or tablet).

    Please note: The youtube video made by the developer who wrote the app I attatched in the first post has this same information in somewhat greater detail and visuals, if you are having a hard time generating logs after reading these instructions then please watch the video (it is around 8 minutes long).

    Step 1)
    Download "Log This" by Mgamerz Productions, from Google Play (Android Market).
    Here is a link to make sure you have the correct application.
    Google Play Store Link: Log This

    Step 2)
    The First screen you see will ask you how you want share the finished log, in the interest of time select "Post Logs to Pastebin." If you were to select "Send Logs via Email" you don't get to choose how long the phone collects data before it generates a log.


    Step 3)
    The next thing you must do is enter a "log tag" which is essentially a feature of Logcat to help create a more well defined log by filtering out information that will not be useful to your bug search[/I][/B]

    This is a short excerpt from Google's Developer website explaining how they do it:
    Every Android log message has a tag and a priority associated with it.

    The tag of a log message is a short string indicating the system component from which the message originates (for example, "View" for the view system).
    The priority is one of the following character values, ordered from lowest to highest priority:
    V
     
    ChoznJuan and smith058 like this.
  4. smith058

    smith058 Android Expert

    Wow what details.... you're now disignated detail wrighter for our forum... lol gj
     
  5. bads3ctor

    bads3ctor Well-Known Member

    I have a theory as to what is causing the touchscreen fault but I have yet to find a way to verify it. It could be i/o latency causing the touchscreen driver to drop input data. If anyone knows a way to test i/o latency in Android...I'm all ears.

    Edit: I have requested some changes to Bob's OC kernel to test my theory:
    http://androidforums.com/transform-...locking-kernel-sph-m930bst-2.html#post4224180

    I'd hate to do all this work just to find out I am wrong about this. :rolleyes:
     
    smith058 likes this.
  6. AndyDroidBot

    AndyDroidBot Member
    Thread Starter

    I didn't even think of this so I did a quick google search, only to find that an app had been written for Audio latency (unrelated)...


    After I read the top comment I got to thinking.
    If you believe the processor may be getting choked up, it may be the scheduler!

    XDA has the GREATEST written post ever on how to modify a kernel.
    [REF][TWEAKS] Kernel Governors, Modules, I/O Schedulers, CPU Tweaks, AIO App Configs - xda-developers

    Post #4 deals with IO schedulers
     
    smith058 and bads3ctor like this.
  7. Loota

    Loota Android Enthusiast

    no-frills cpu control allows you to change I/O scheduler between noop and cfq... I have been using cfq and still have issues with it. I will try noop and report back.

    EDIT: just tested with noop enabled and there is no change but I am questioning if the app can change the scheduler without an option being enabled in kernel?

    As for the original post in this thread I have it installed and have tried to get a logcat using this method but have not been able to populate it, I will try after watching the video now and see what I can do... worst comes to worst and I will just run an actual logcat with ddms and see if I can't contribute.
     
  8. Loota

    Loota Android Enthusiast

    As near as I can tell we want InputReader and InputDispatcher. Can someone confirm this? I found this by viewing my log in alogcat and as near as I can tell this is what handles the touchscreen.

    here is my pastebin of those two tags. Transform Ultra InputReader/InputDispatcher - Pastebin.com

    Note** the v, d, i, w, e, f and s tags do not work and as near as I can tell that describes the a different type of tags found in a logcat and not what this app specifically looks for (which I think is a filter to only show you logs of whatever app or process you specify)

    Edit: I definitely think InputReader and InputDispatch are what is needed but I wonder if we need more then just those two? If someone confirms this or can post what we actually need I will use screencast to make a video and take screenshots to make this process even easier to do for endusers for this purpose...
     
  9. Loota

    Loota Android Enthusiast

    ChoznJuan likes this.
  10. AndyDroidBot

    AndyDroidBot Member
    Thread Starter

    Loota is correct, the tags in my original post are filters for doing it the manual way. Sorry for any confusion.. but now that also means I am unsure of what this app uses to filter results.

    I have located a website that hosts the repo for the original Android 2.3.4 R1 source (all in Java I believe)
    http://grepcode.com/snapshot/repository.grepcode.com/java/ext/com.google.android/android/2.3.4_r1/

    It makes it easier to download this way so you don't have to sync with google and wait a bunch to do the download. Once you have the source I have a question for anyone who can analyze it better.

    I've downloaded it and opened the java containers with 7Zip on my windows PC, I do not yet have a linux dual boot environment set up, but I really don't know what files I am looking for as it is not very self-explanatory. There is an entire file dedicated to sensors, drivers, and touch utilities, and I'm thinking they can be copied over and recompiled to the source from samsung's open source website.

    back to the original point of this thread, which is logcat, it's very interesting that you also returned the same name of a problem area as Bad's original logcat post.
    check this out

    one thing I read about Logcat is it's output is Java errors (makes sense seeing as how the Dalvik player is a java compatibility layer)
    I searched and searched but couldn't find any information regarding "error 167" which is in parenthesis here. but what IS interesting about some of the online logcats I've found is that they all have different error codes for the given problem areas. The ones based on "InputReader"

    XDA Thread

    these folks at XDA with another samsung phone (galaxy ace) have a log posted about half way down the page and it's error code 173, but still has to do with InputReader

    here is the C++ file that goes in the kernel in full, is it possible to compare this to the one are already have to see if some punctuation or something simple is missing?
    libs/ui/InputDispatcher.cpp - frameworks-base in rowboat - Gitorious
     
  11. AndyDroidBot

    AndyDroidBot Member
    Thread Starter

    EDIT: Here's something else I found on that website,
    These are all the .cpp files for handling inputs and touch events

    Library files for kernel

    Input.cpp
    InputDispatcher.cpp
    InputManager.cpp
    InputReader.cpp
    InputTransport.cpp
     
  12. Loota

    Loota Android Enthusiast

    While it's good to know the other files that may be involved rowboat seems to be an ics android port to ti calculators :( not sure if that applies.. I'm trying to find a version of InputReader version specifically for our phone... Looking in source but I'm not seeing anything...

    https://github.com/android/platform_frameworks_base/blob/master/services/input/InputReader.cpp

    What do you think of this? Look at lines 163 and 159 which are the two numbers being thrown up by bads and my logs respectively...
     
  13. bads3ctor

    bads3ctor Well-Known Member

    I have been trying to get cm7 or cm9 booted on the TU to verify if the problem is actually with frameworks inputreader or with the kernel. If I get cm7 booted and we still have the TS bug then the problem would most likely be with the kernel driver or with some other app or driver intermittently taking the I/O bandwidth from the TS driver.
     
  14. ChoznJuan

    ChoznJuan Well-Known Member

Samsung Transform Ultra Forum

The Samsung Transform Ultra release date was October 2011. Features and Specs include a 3.5" inch screen, 3MP camera, 128GB RAM, Snapdragon S2 processor, and 1500mAh battery.

October 2011
Release Date
0
Reviews
Loading...

Share This Page

Loading...