Posts Tagged ‘logcat’

CatLog jives with Jelly Bean, goes open-source


CatLog is an app I’ve always been immensely proud of. I wrote the initial version in the span of a weekend, and yet it grew to be my second-biggest Android app, after the now-defunct Pokédroid. Even though it’s a pretty esoteric app, and nobody except developers will find it very useful, I’m glad I could contribute something valuable to the Android community and help make Android development a bit less of a pain. It’s cool to see fan-made instructional videos on YouTube and all the forum posts where people say, “Just download CatLog and send me a log report.”

But lo, all is not well in CatLog Land. As of the newest version of Android (4.1 Jelly Bean), Android apps can no longer read each other’s logs using the READ_LOGS permission. You’re limited to your own logs, unless you’re a system app or you gain root privileges. Uh oh.

Now, this is a defensible position on Google’s part. After all, there was a pretty high-profile security hole found in the Facebook Android SDK due to developers carelessly writing sensitive information to the system log. And in general, most apps don’t need to read each other’s logs, so the change is understandable. Stay in your own sandbox and all that.

This change is going to have a big impact on certain varieties of apps, though. Not only will it affect log-reading apps (like CatLog and aLogcat), but also apps that rely on log-reading in some way. For instance, you can say goodbye to the various “app lock”-type programs that rely on reading the system log to determine when other apps are being launched. If you don’t believe me, check out the permissions page for those apps. See where it says “read sensitive log data”? That’s the death knell for these types of apps, unless somebody figures out a smarter way to detect when another app is launched. (My own AppTracker works in the same way. So it’s toast as well.)

So what does this mean for CatLog? Well, in the future, it means it will only work on rooted phones, which basically limits its appeal to developers and root-happy techies. Until now, it had also come in handy for end users, since it gave them a way to easily submit bug reports (in cases where, for whatever reason, the default reporting mechanism wasn’t available). But starting with Jelly Bean, CatLog will require root access, which means it’s basically worthless for Joe Android User now.

So given that this is more or less CatLog’s swan song, I’m taking a pretty radical step with it. I’m open-sourcing it. Yep, CatLog is now free to remix and re-use, released under the ultra-permissive WTFPL license, just like my other apps.

Why such a permissive license? Well, because I honestly don’t care. CatLog was always a free app, and although I’m grateful for the nice pocket change I make from the donate version (about $20 per month), I doubt open-sourcing it will affect the donations much, and anyway the app was never about making money for me. So there’s really no reason to lock down the source code. I mean, yeah, there are already some copycat apps out there that stand to benefit, but they’re not really doing anyone any harm hanging out in sixth or seventh place in the search results. CatLog’s main advantage is its reputation on the Google Play Store.

On the other hand, if you do want to re-use CatLog’s code, the only thing I ask for is attribution. Sure, the WTFPL doesn’t require it, but this is just one of those “don’t-be-a-jerk” requests.

I have another strong reason for wanting to open-source CatLog: I’m bored of it. Frankly, I haven’t been able to give it much attention lately, because I think 99% of its useful features are finished, and everything that’s left is just flourishes and fine-tuning. It needs a facelift and probably some tweaks to the filter syntax, but with the enthusiasm I’ve shown for the app lately, I’m obviously just not the one to do it.

Also, I find myself turning away from Android development in general. I started writing Android apps when the system was still in its infancy, with only two phones available – the HTC Dream and the Magic. I found it a lot more fun when Android was still simple and untamed, when the market wasn’t flooded with glitzy, polished apps all competing for users’ mind-share. Back in those days, you could even write a simple Pokémon app with an ugly UI and people would love you for it. Development was easy, and the exposure was fun.

Nowadays the Play Store is much more crowded, and Android development is more difficult in general, what with supporting hundreds of devices with multiple form factors (including tablets), and multiple Android versions stretching from 1.5 Cupcake to 4.1 Jelly Bean. The APIs have grown incredibly complicated, and I can’t count the number of times I’ve discovered bugs that only appeared on a certain Android version or on a certain phone. It’s a huge headache trying to maintain all this compatibility, which is why I still haven’t updated any of my apps to the new “Holo” theme from ICS.

However, my lack of enthusiasm shouldn’t limit CatLog’s potential. When you’ve lost interest in a software project, I think it’s your duty to make it open-source, so that somebody else has a chance to grab the baton and run with it. And that’s exactly what I’m doing with CatLog. So if you have any features or bugfixes you’d like to write, fork me on GitHub and go nuts!

CatLog now supports external Intents

As of version 1.3.2, you can now start up the main CatLog activity using an external Intent, with parameters for filter text and log level.

For Android developers, the idea is that you can just put a switch in your app where, if some debug variable is enabled, you can press a button or access a menu item to start up CatLog and search for text related to your app. This should make it less painful to do debugging, in situations where you don’t have access to adb logcat.

I’ve written a simple demo app on GitHub to show how to use the new Intent.  But the basic gist is that you want to paste something like this into your code:

Intent intent = new Intent("com.nolanlawson.logcat.intents.LAUNCH");

intent.putExtra("filter", myFilterText);
intent.putExtra("level", myLevelText);


That’s it! Full documentation is below.





Text to filter by.  Case doesn’t matter, and you can search for either process ids, tags, or log text.


Log level to set CatLog to, case insensitive.  One of:

  • E (error)
  • W (warn)
  • I (info)
  • D (debug)
  • V (verbose)
  • F (what a terrible failure)

CatLog is #1!

My goal with CatLog was to write the best darned Logcat app for Android, and in that regard I think I succeeded. But as long as the adequate but inferior aLogcat was ahead in the search results for “logcat,” I felt like my work was incomplete. After all, most people will just download the first app in the list without trying any others. How can I really say that I’ve written the “best Logcat app for Android,” when it’s not most people’s first choice?

Starting sometime this month, though, it finally happened – CatLog now shows up first in a search for “logcat” on the Android Market:

I’m ecstatic that my app is finally getting the recognition I think it deserves, but, to be honest, I’m also kind of puzzled as to why it suddenly managed to nudge ahead of aLogcat. Comparing the Market statistics of the two apps side-by-side, it’s not clear what makes CatLog stand out:

CatLog aLogcat
Released: Aug. 2010 Nov. 2009 (?)
Downloads: 10,000-50,000 100,000-500,000
Reviews: 587 1,683
Rating: 4.7 4.6
Updated: August 14, 2011 March 6, 2011
Android Version: 1.5 and up 1.5 and up
Category: Tools Tools
Size: 323k 39k
Price: Free Free
Content Rating: Everyone Everyone

There doesn’t seem to be a big difference in the ratings (4.7 vs. 4.6), and aLogcat has a considerably higher number of downloads and reviews. So what changed? I think this blog post might provide a clue. It seems that, besides downloads and ratings, Google’s ranking algorithm also takes into consideration the retention rate of an app – i.e. how many users actually keep the app installed, as opposed to those who just download it.

It’s impossible for me to know what aLogcat’s retention rate is, because Google doesn’t make that information public. But I do know that CatLog has 40,834 downloads and 15,487 active users, which gives it a retention rate of 38%. This is the highest retention rate out of my most popular apps (30% for Chord Reader, 18% for Japanese Name Converter, and 20% for Pokédroid), so I’m guessing it’s also higher than whatever aLogcat has. Considering that aLogcat was released almost a year before CatLog, maybe it initially attracted a large user base that later started flocking to my app? Who knows.

Alternatively, it could be the fact that I’ve recently updated CatLog, whereas aLogcat hasn’t been updated since March of 2011. If that’s the case, then aLogcat could quickly regain the lead by just releasing an update. This seems unlikely, though, given that such a system would be easily gameable by just releasing a new update every day. As I noted in a previous post, those kinds of shenanigans made the “Just In” section of the Android Market practically useless, so Google eventually nipped that practice in the bud.

Whatever the reason, it’s nice to see that quality apps do eventually drift to the top. Similarly, I’ve watched one of my other apps, KeepScore, jump from 11th to 3rd in a search for “score keeper.” I’m hoping that, by just being the quiet valedictorian in the back of the class, it can eventually make it to the top. CatLog proves that that’s possible.

If imitation is flattery, then CatLog has a secret admirer

When I first released CatLog last summer, my goal was to create a replacement for the dominant Logcat app, aLogcat. (“Logcat,” if you don’t know, is the somewhat cryptic name for Android’s system log, which is invoked by typing adb logcat in a shell. In a delicious pun, the Android team also lets you invoke it with adb lolcat.)

Around that time, I was on vacation in France, and I didn’t have access to a computer with an Android development environment. So when a problem came up in one of my apps, I tried using aLogcat instead. But aLogcat just wasn’t cutting it for me. It was clunky, difficult to read, and lacking in decent search/filter functionality. Just scrolling through the logs to try to pick out my own app from the others was a classic victory of the haystack over the needle.

When I got back to Seattle I was still unemployed, which meant I had a lot of time to burn. So I sat down at my laptop, and less than 24 hours of frenzied coding later, I had busted out my first version of CatLog. It didn’t have a lot of the cool features I ended up adding in future updates, but it would still beat aLogcat in a beauty contest:



CatLog’s look and feel is inspired by Jeff Sharkey’s Colored Logcat script, which is a great way to view logs because the tags are color-coded, and because everything is organized into neat columns. CatLog is also easier to search than aLogcat, because the search bar is right on top of the screen, and it filters automatically as you type.

As far as additional features go, CatLog also records logs in the background, sends logs as text or attachments, and auto-scrolls when you’re at the bottom of the screen. aLogcat, by contrast, only lets you search through a cumbersome dialog box, it can only send logs as text, and it forces you to pause and unpause if you want to control the scrolling. It does the job, but in terms of usability, it leaves a lot to be desired. (Edit: aLogcat now supports auto-scrolling.)

Despite these shortcomings, aLogcat is still more popular than CatLog, and it comes up first in a search for “logcat”. That doesn’t bother me much, though, because I know I’ve written the best Logcat app for Android. You only have to play with each app for a few seconds to see the huge difference in presentation, features, and usability. aLogcat was first on the Android Market, and that’s probably what it owes much of its success to. But given enough time, I’m sure CatLog will pull ahead.

I got a little surprise a few weeks ago, though, when I noticed a new Logcat app on the market: LogViewer. I wondered if someone had finally improved upon CatLog – I love a good challenge! But as I played around with the app, I became more and more puzzled. LogViewer has far fewer features than CatLog, but the presentation is a dead-on imitation. Like CatLog, it has a cat in the icon. Like CatLog, it arranges everything in columns. And like CatLog, the search bar is on top of the screen, with “expand” and “clear” buttons to the side.



I’m not angry at the developer for taking design cues from CatLog. After all, I modeled CatLog after Jeff Sharkey’s script, and the two look very similar (although his is a Python script and mine is an app). Also, I don’t really believe there’s anything wrong with borrowing someone else’s ideas to improve on them – human civilization is built off of this practice.

But what confuses me about LogViewer is that it doesn’t even improve upon CatLog in any way. It has far fewer features – no process id, no color-coded tags, no widget, no ability to delete saved logs, no ability to send logs as attachments, etc. And the only thing it adds is a big ad banner at the bottom, along with some text saying “Copyright 2011 ukzzang. All Rights Reserved.” (Nice use of the screen real estate, by the way. Heaven forbid someone should try to copy his app!)

I guess I just don’t see the point. Why would you go to the trouble of writing a Logcat app if it doesn’t improve on the competition? I suppose you can slap an ad banner on it and make a couple of cents that way, but having written an ad-supported app myself (Chord Reader), I can attest that ad revenue tends to be chump change unless your app is on par with Angry Birds in terms of popularity. (Chord Reader has over 11,000 active users, but it’s only earned about $60 since I released it 9 months ago. I’m thinking of just taking the ads out, since it’s not really worth it to ugly up the app.)

CatLog with menus

LogViewer with menus

My only hunch is that, since the author of LogViewer has written an “App Lock”-style app, he’s already had to deal with reading Logcat output (which is the way these sorts of apps work), so he figured he might as well write a Logcat app as well. And if that’s his reasoning, then fine. CatLog is still the best Logcat app on the Market, but if any of my users think to themselves, “Gee, I like CatLog, but I wish it had more ads,” well, they now have another option. I can’t argue against consumer choice, even though this particular choice seems a little silly to me.

There is one area, though, where I have to give LogViewer credit: its performance is pretty damn good. When I first tested it out, I noticed that its scrolling was much faster and smoother than CatLog’s. This made me realize that CatLog had some room for improvement in the speed department. So, spurred by this upstart new rival, I went back to the CatLog codebase and made some long-overdue optimizations that brought it up to roughly the same speed as its competitor. These changes are available starting in version 1.1.6.

So in this small way, at least, I tip my hat to CatLog’s secret admirer.