Android has a log mechanism that is often referred to as logcat. Logcat is a command line tool to control and dump data sent to this log.
Note also that the Linux kernel has it’s own separate logging mechanism.
I haven’t fully inspected the logging architecture but here are some tips.
Java (Android) applications use the Log class to send data to the Android log.
Other systems software i.e. things like SurfaceFlinger and hardware adaptation code will use logging APIs contained in #include <cutils/log.h> for e.g.
LOGE("This is an error log message");
Kernel side code will use printk for it’s error messages. Note that such messages do not got to the same log as the logcat bound messages. It is typical on OMAP baseports that kernel messages are directed to the default serial console which also has a command line prompt.
Inspecting the logs
The logcat command can be used to see the contents of the log – but not the kernel log. From the serial console command line you typically put this logging in the background so you can run other commands for e.g.:
The dmesg command can be used to inspect the kernel – or you may capture messages on the serial console as mentioned before.
Clearing the log
You might sometimes not be interested in the current contents of the log before invoking logcat, so you can use:
logcat -c logcat &
to clear the log contents before keeping an eye on subsequent entries.
Logging to the console all the time
It can be a hassle to call logcat by hand, or a system crash may make it impossible to invoke logcat manually. You can add the following entry to the init.rc file in the root of the Android filesystem:
service logcat /system/bin/logcat -f /dev/kmsg oneshot
Other logging issues
One problem with logging from userspace code in general is that messages are not synchronous i.e. in the case of a kernel crash logging information maybe lost.
Also be aware that there is an overhead associated with logging. This is true if logging to a relatively slow serial port.
Colour me confused about what Nokia is up to.
What I hope is being learned is that in order to fight Android and the iPhone your don’t Ratner-ize one of your platforms. What is striking is that if you are going to ride two if not three horses you better present a good story.
Ironically, at the heart of things they do appear to have one – it’s Qt. Qt is technology which none of Nokia’s competitors have an effective equivalent. It has the high-level potential that you could write an application and have it work in any number of different OS environments. This story has been slow to evolve though. So perhaps the underlying technical barriers make this difficult to make true. Nonetheless, Nokia could do with a bit of Jobsian leadership right now.
So here we have it. According to some bloke called Doug Dawson at Nokia the Symbian OS will no longer be in Nokia’s flagship N series lineup.
This isn’t really news however what sense does it make for Nokia to make this statement? What message does it send to all the interested parties?:
Gadget geeks: Anything which is a Symbian device is behind the curve, you don’t want one of these.
Journalists: We are validating your prejudices, Symbian devices are out of date you need some else.
App developers: Don’t develop for Symbian OS (the current perception is that high-end phones is where the application money is).
Symbian platform developers: You ain’t got much of a future, but you might be able to earn money like the Cobol programmers do i.e. work with a technology with a limited or no bleeding edge development.
I don’t see any upside to Nokia to making this statement. When responding to the original C-NET Aus leak, how about saying “we don’t discuss our technology roadmap outside the company”? What’s wrong with a little secrecy? How about holding off on this news until you’ve released your latest and greatest devices?
Nokia will still shift many Symbian devices but from now you can’t help but feel that Nokia has cut the technology air supply to Symbian OS. Technologies, especially OS’s do not die quickly but nonetheless they are effectively dead.
Looking over the highlights for Android 2.2 (aka Froyo) my overall impression is the release is a little low key in terms of direct user features – for me the ‘oh that’s cool’ feature is probably the portable wifi hotspot. However, I suspect the performance improvements will have the biggest impact in the whole “User XP” (spit) as some call it…
Drilling in a bit further, obviously app installation onto external media is welcome, although that’s been available on Symbian devices for years. Allowing apps to participate in backup and restore is pretty cute also.
The addition of new graphics APIs is of interest to me:
- New OpenGL ES 2.0 APIs in android.opengl.GLES20.
- New ETC1, ETC1Util, and ETC1Util.ETC1Texture classes and utility methods for using ETC1 for texture compression.
- New ImageFormat class.
- New YUV image format API to enable compression from YUV to JPEG and manipulation of YUV data.
I think the SGX processor on the OMAP can handle ETC1 textures but not 100% sure. It also seems like it would be possible to optimise YUV to JPEG compression on the OMAP, I presume the default Froyo implementation is using ARM or potentially NEON instructions.
Of course the changes in the SDK don’t reflect what is changing under the hood… I’ll possibly be taking a look at that later.
1.43 Billion dollars divided among 164,000 actual paid apps gives the average app the revenue of $8,700. After Apple takes its 30% or $2,600 we are left with $6,100. That was over a two year period, so an average paid iPhone app earned six grand to its developers, ie in one year, they earned $3,050. This is the average, remember, it is not the median. The average skews too high because of the long tail. There are a few who make several millions, who distort the average number, so it is not true that half of iPhone App Developers earn more, and half less, than $3,050 per year. It is definitely true, that the median will be significantly less than this.