I've searched around for everything that seems to be capable of affecting logcat, but I just can't find an answer to this problem. I'm debugging a large application that dumps several hundred logcat messages to screen per second. In Eclipse, I'm using a regular expression to filter by log tag, but this is where things get weird. The "pause" button keeps on activating for no apparent reason, and given the massive volume of new messages, before I can get the logs for the specific sequence of events I'm investigating, they'll be overwritten, a little at a time. I've even set breakpoints and tried to capture the logs bit by bit with the "export" button, but the app is multithreaded and they still disappear too quickly because of messages from other threads. It would be nice to increase the buffer somehow, or make old messages stick around, though at this point I'm willing to dispense with it altogether and just output it to a file, but I'm not sure how to filter by log tag using my regular expression from the command line. What are my options?
P.S. I have been looking around and I hope this isn't redundant--I haven't found anything specifically addressing my problem, though I have of course run across abundant related threads that don't quite help. Thanks so much!
I had similar problem to this. I was working on application which communicate to web server and download a huge amount of data. I had logs almost for every variable and I had to test them to see if the result which I'm receiving from JSON is correct. So the thing that I did was to log all logs on a file on my sd card and I did something like this :
public void log2File(String filename, String log, int type){
switch(type){
case 1: // debug
case 2: //verbose
case 3: //warning
//..and etc
}
}
I didn't find anything better for my solution, so that's the way which I did it.And of course you have to add your logs on a file and save it.
Hope this solutions seems good for you.
I've found the eclipse logcat window to be fairly buggy with high logging volume - it won't even stay disabled if you try to turn it off.
To actually capture the desired data, I tend to use the adb logcat command from the commandline. On linux, or presumably cygwin or osx you should be able to do:
adb logcat | tee logfile
And both see the messages flying by and have them recorded to a file.
I know this question is old but I had the exact same problem as you. I looked everywhere for a good solution but did not find one that worked for me so I took to creating my own tool. If you are on a Mac you could use LogRabbit to do what you want to do. It could help solve your problem in two different ways.
You could use adb logcat -v threadtime on the command line and write the logs to disk and import that into LogRabbit.
The filtering mechanism should be plenty fast enough to handle the log volume you are talking about.
Have a look at http://lograbbit.com I hope this helps.
Related
I am unable to launch a flutter, both on mobile and on android emulator. I've checked all other questions similar to mine, but the answers provided could not help solve this issue. Who else has encountered something like this and what fix worked for you? The file is pretty large, over 5k lines of code, I could have just paste it here.
One of the possible cause of this occurrence is the presence of an infinite loop anywhere in your code. Once flutter encounters any infinite loop while preparing your app state, it gets stuck on executing this and the device/emulator connection timeout, hence connection lost. Place a print statement in all loops in code concerned with the homepage of your app, it's one of the stress free way to detect the culprit loop.
Currently involved in a University project and could use any help from members regarding rootkits designed for Android.
I have little knowledge of Android malware and the project so far has got us decompiling apks to view the java class files (if readable) and the AndroidManfiest.xml file. I have also managed to root a phone in the uni lab using various adb commands and pushing files over to it.
What I would like to know is if it's relatively easy to spot malicious rootkit code within a class file? Is there something I can look out for? Is it a case of getting su status or does it involve adding users? Assume to next stage would be to then contact a server so the developer has remote access..
Also, is there a system or service that can process an apk to spot if it contains a rootkit (not just malicious)?
reply:
hi sorry about late reply - tried responding immediately but wasn't allowed as I'm new, but then forgot!
Thanks for the info! I appreciate that I may sound naive, but I guess I have to be seeing as I don't know anything about rootkits or the way they work..
You're right, they are not asking about 3rd party scanners, that was just my interest. So on that topic, are you saying there are scanners out there that specifically look for rootkits in a sample? Or is this detection all part of the overall AV service they offer.. If specific to rootkits alone, then I would really like to know which ones, so i can research them..
Also, with regards to exploitation of a bug - I assume you mean a bug within the Android OS? Would this mean that when patch updates are pushed out from Google then the rootkit is unable to function?
Thanks
A mallicious rootkit tries its best to get certain access, secretly. So any generalisations you make about how it does its business will probably be already worked around by any good rootkit.
"setting su status" is hardly worthy of being called a 'rootkit', that's just 'using root permissions' that you seem to have given the app. A rootkit would look for a way to actually get this without permission, by exploiting some sort of bug.
Systems of services that spot those things are commonly called virus and/or mallware scanners. Yes they exist.
Not to be negative, but this seems like a naive post about the subject, and probably not a good start for a project: I'd say using a 3rd party malware scanner is probably not wat is asked?
You could, for instance, look for known exploit-methods. One that for some reason comes to mind is the overflow, but that's just a random thing. Read up on rootkits, their methods, heuristics to find them etc.
I have read quite a few questions regarding "Removing Logs" but none answered my question. So, I have to ask here again.
What is the impact of Log.d() or Log.v() or Syso() statements, on the application?
Let's say I have an application with 200 syso() statements, or Logs, that I used to debug while creating the app. I didn't bother to remove them, because, (I am a newbie in android) and I thought, there is no way those statements gets printed or displayed. So, why take the pain of removing all those lines.
So how far my idea of not removing the logs effect the application? Will it increase the size of the application (cached data or something)?
#All, I think you don't are misunderstanding what I am asking for. I know Google advises us to remove the logs, and I am not questioning that. I want to know, what's the impact of those logs on my application, if i don't remove the logs
You should remove all log messages. Else the user can see them via logcat. But nothing will happen with your app (no increase size etc.)
Read this if you want to know how to remove them on the fly while deploying:
Remove all debug logging calls before publishing: are there tools to do this?
Read the section - Preparing Your Application for Release
http://developer.android.com/tools/publishing/publishing_overview.html
I search for days now, and only specific answer i got in one thread is that its not possible (here).
But, I found some apps that can do it so i guess it is possible, probebly with some kind of a workaround.
The problem is that i'm in the dark, i dont have any idea where to start from. I'll be happy for any points, leads, anything to get me started...
Thanks,
Eitan.
Background:
* I am new to developing for Android but I am a programmer/front-end web developer so I'm not totally new to this sort of thing
* My personal phone is the Samsung Droid Charge, on Verizon - I am unsure if this will really matter or not.
Problem:
It seems like I have lost all of my photos and videos, so I'm reaching out to see if anyone knows whether or not for sure I am in trouble, or if there's still hope of recovering this data loss.
What I believe caused the problem:
I followed the tutorial on how to make a simple Hello World application, as a first step in learning how to develop using Eclipse. I was unfamiliar, at the time, with signing applications. So, I just used the apk which was in the bin folder of my project. I placed it onto my web server using FileZilla, and pointed my phone browser to the file. It downloaded it, but when I clicked on it, it said something along the lines of "File is too big." or "Application is too big." or "Not enough room to install." or something along those lines. The application was only 28k, but I'm sure that it had something to do with the fact that I did not sign it properly before attempting to use it on my phone.
So - my theory is that since it looked at it as "too big," that it removed other things on my phone which were too big, in order to make room for it. I noticed that my phone suddenly forgot all my ringtone and other sound settings - because it moved them all to my 32GB micro-SD card (which came with the phone). Previously, this data was stored on the internal memory along with my photos and videos. However - I am now not even able to view the files on my internal memory when I go to "My Files" from the apps. Why this would happen, I don't know - it doesn't seem like a very good feature to have. A fellow developer at my office mentioned that it may be something Verizon has set in place for some odd reason.
If the photos are still there, which is very possible, I'm not sure how to view them. The gallery app does not recognize any files, and I am otherwise completely unable to look at my internal memory - even using a program called AndExplorer.*
As a new developer for android, this is extremely frustrating. Sure, perhaps I should have backed up my data before testing my app on my own device, but there's absolutely no reason that this should have happened.
I'm sure I can't be the only one who has ever done this. I tried searching for the issue ALL OVER the web AND on stack overflow and was not able to find anything.
Any and all help is greatly appreciated. And I have certainly learned my lesson - I need to back up my stuff before testing anything.
*EDIT: It turns out I actually can view the internal memory using AndExplorer, but there doesn't seem to be anything on there, as far as my missing photos and videos.
I placed it onto my web server using FileZilla, and pointed my phone browser to the file.
Is your Web server configured with the proper MIME type for APK files?
but I'm sure that it had something to do with the fact that I did not sign it properly before attempting to use it on my phone.
I rather doubt that. You have to explicitly do things to avoid signing an APK.
So - my theory is that since it looked at it as "too big," that it removed other things on my phone which were too big, in order to make room for it.
That seems unlikely. Even if true, this is a question for Verizon/Motorola, not StackOverflow, as only they can help you with end user device issues such as lost data.
Sure, perhaps I should have backed up my data before testing my app on my own device, but there's absolutely no reason that this should have happened.
It doesn't, in the course of normal development.
I'm sure I can't be the only one who has ever done this.
You are probably the only person on the face of the planet whose photos, etc. were lost or misplaced as the result of trying to install a hello-world APK.
And I have certainly learned my lesson - I need to back up my stuff before testing anything.
Then you did not learn your lesson. You need to back up your "stuff", period, unless you are somehow personally invulnerable and believe that this protection will extend to your device. Otherwise, you are as likely as the rest of us to have your phone accidentally get dunked in a toilet, run over by a bakery truck, caught in a fireball triggered by a terrorist attack on a natural gas pipeline, etc. And, in those cases, you would lose your data as well.
In a nutshell, Android development does not typically adversely affect a device, certainly not the mere act of installing an app. Whatever problem you have experienced is due to some combination of events triggering some bug in the Charge (possibly just your individual device).
BTW, the preferred way to test an app on a device is to use the USB cable, then run it from Eclipse on the device itself. FileZilla and downloading from the Web can work with a properly-configured Web server, but that's usually reserved for later in the development process.
CommonsWare, some of what you've said is helpful, but some of it not-so-much. Who says I don't already backup my data? Perhaps I do, and I just hadn't done it in a day? You don't know that much detail about my situation. Maybe I am only missing photos from one day. You can't definitively say I have not learned my lesson. I'll decide if I've learned my lessons or not ;). That should not have been my main focus and for that I apologize.
I'm more interested in why this happened than I am interested in getting my data back. I certainly wouldn't want this happening again. If it has nothing to do with "size" or proper signing, what else could possibly ever make something like this happen? Like I said - I am new to developing apps for phones - I can only assume so much using the developer guide provided to me by Android. A lot of the steps assume that the user knows certain things. And perhaps that's my fault and I should start somewhere else for basics.
But I still attest that the issue must have been caused by the app. I did not change anything with mime types, but according to what you're saying, that shouldn't affect things. That should not have had any effect on data loss. Yet, it absolutely, without a doubt did.
I've used a program to scan the flash drive to see if it could find any deleted files. That didn't work. So I've pretty much given up on getting the data back. Like I said - my focus should just be to prevent it from happening again.