Logcat on 2.1 MCR

[Guest Stevos]

Ooops, I've only just noticed this as I've just got back to doing some development after all the excitement of the 2.1 releases.

Using windows Vista x64 with the new adb drivers etc, adb connects fine to a 2.1 MCR Pulse, and commands can be passed, however logcat is resolutely blank whether using the command line or eclipse. This is going to make app development *very* hard.

I've done a search, but if there are answers they are buried inside 50 page threads...

Can anyone give me any pointers on how to get logcat working properly?

cheers medears,

[Guest jmmL]

Ooops, I've only just noticed this as I've just got back to doing some development after all the excitement of the 2.1 releases.

Using windows Vista x64 with the new adb drivers etc, adb connects fine to a 2.1 MCR Pulse, and commands can be passed, however logcat is resolutely blank whether using the command line or eclipse. This is going to make app development *very* hard.

I've done a search, but if there are answers they are buried inside 50 page threads...

Can anyone give me any pointers on how to get logcat working properly?

cheers medears,

Just checked and I can confirm no output from logcat. Which logs is logcat actually spitting out though?

I can get dmesg output no problem - but not sure if this contains all the information that logcat would.

[Guest jmmL]

Ooops, I've only just noticed this as I've just got back to doing some development after all the excitement of the 2.1 releases.

Using windows Vista x64 with the new adb drivers etc, adb connects fine to a 2.1 MCR Pulse, and commands can be passed, however logcat is resolutely blank whether using the command line or eclipse. This is going to make app development *very* hard.

I've done a search, but if there are answers they are buried inside 50 page threads...

Can anyone give me any pointers on how to get logcat working properly?

cheers medears,

Just checked and I can confirm no output from logcat. Which logs is logcat actually spitting out though?

I can get dmesg output no problem - but not sure if this contains all the information that logcat would.

[Guest Stevos]

logcat should contain VM and app level logging for event and error tracking. I think it's different information to the linux system logs.

With no logcat output it's very hard to track and debug application level code

[Guest Simon O]

Logcat is disabled in these roms. You need to enable logging as per instructions at http://android.modaco.com/index.php?s=&amp...t&p=1120481

[Guest Stevos]

Ah great find, thanks. I'll add that to the 2.1 tweaks thread.

I wonder why logging would be disabled...

[Guest Simon O]

Ah great find, thanks. I'll add that to the 2.1 tweaks thread.

I wonder why logging would be disabled...

I wonder that also. At the moment I'm not sure how to enable it within a custom rom, but I'll work it out.

[Guest jmmL]

Ah great find, thanks. I'll add that to the 2.1 tweaks thread.

I wonder why logging would be disabled...

Space constraints perhaps..?

[Guest Stevos]

I wonder that also. At the moment I'm not sure how to enable it within a custom rom, but I'll work it out.

My linux is very rusty, but I would guess a way to do it would be to simply add those echo statements into the startup scripts. There's probably a more graceful way though.

^ Yes it may be a size and space issue, but disabling logging on what looks to be a test / development ROM (shipped with test keys etc) seems like a *very* odd decision.

I almost wonder if something bad was showing up in the logs, so they turned it off to make it go away :(

[Guest Stevos]

Oh that's interesting (and unexpected - for me anyway)

The log enabled status seems to survive reboots, so it's evidently persisted to ROM.

It seems it doesn't have to be initialised at every boot, so perhaps it could go into an install script rather than run on each startup.

[Guest Stevos]

I almost wonder if something bad was showing up in the logs, so they turned it off to make it go away :(

And who hasn't felt like that sometimes...

Anyway it seems the log is frequently filled with low memory warnings when apps like maps are run, so perhaps they just decided "we know there's no memory, no need to tell us all the time" and switched it off.

ActivityManager: Low memory: No more background processes

That is presumably why the home app was getting shutdown and reloaded without the tweaks.

Obviously a certain amount of unloading and task killing is expected, but I'm pretty sure that just running maps on 1.5 didn't lead to killing all other processes.

[Guest Simon O]

And who hasn't felt like that sometimes...

Anyway it seems the log is frequently filled with low memory warnings when apps like maps are run, so perhaps they just decided "we know there's no memory, no need to tell us all the time" and switched it off.

ActivityManager: Low memory: No more background processes

That is presumably why the home app was getting shutdown and reloaded without the tweaks.

Obviously a certain amount of unloading and task killing is expected, but I'm pretty sure that just running maps on 1.5 didn't lead to killing all other processes.

My experienced of the 2.1 roms tells me that the stock T-Mobile rom is shockingly bloated. I'm using a rom with all the t-mobile crap removed and launcher replaced with ADW and it's extremely quick and responsive. I've never had any force closes since.

[Guest Stevos]

I'm on the standard 2.1 MCR at the moment with ADW.

free is reporting 7376Kb free until running maps (where the low memory warning shows up in the logs), and free then reports ~2Mb free or less.

hmm...

Edited June 3, 2010 by Stevos

[Guest Simon O]

I'm on the standard 2.1 MCR at the moment with ADW.

free is reporting 7376Kb free until running maps (where the low memory warning shows up in the logs), and free then reports ~2Mb free or less.

hmm...

That does happen with Google Maps as it's quite memory hungry. I suppose the only way this can be resolved is to have a custom kernel with swap support.

[Guest Stevos]

I'm not phased by the idea of having low memory and swapping / killing out apps per se, but it seems like if there's not really even enough to comfortably run one (fairly standard) app without panicking and shutting down background processes, it means the device may be in danger of shutting down essential services and other features if larger apps are run.

The VM heap size is 22Mb which is about 3 times the size of the initial free memory on boot. That does trouble me a bit.

[Guest Simon O]

I'm not phased by the idea of having low memory and swapping / killing out apps per se, but it seems like if there's not really even enough to comfortably run one (fairly standard) app without panicking and shutting down background processes, it means the device may be in danger of shutting down essential services and other features if larger apps are run.

The VM heap size is 22Mb which is about 3 times the size of the initial free memory on boot. That does trouble me a bit.

Hopefully Paul or BoBo could give us some information about that.

Edit: Weird. Just been checking out some 2.1 roms for the G1 and so far non of them have "dalvik.vm.heapsize" set. If it's removed from build.prop does it default to another setting or just doesn't allocate?

I did find this via Google also:

# This is a high density device with more memory, so larger vm heaps for it.

dalvik.vm.heapsize=24m[/code]


The Pulse doesn't have much memory so does having this set cause problems? I know it's set on the Pulse Mini which does have more RAM. Maybe Huawei just quickly ported the U8110 rom to the U8220 and left a lot of the original settings unchanged?

Edited June 4, 2010 by flibblesan

[Guest Stevos]

It may be a setting that's only needed on particularly limited memory devices - after all, with java garbage collection and well written software (along with android's multiitasking and memory management features for switching out background stuff), apps probably shouldn't particularly need hard limits unless they are trying to do somethout outside the reasonable scope for the device. I think it's mainly to stop runaway stuff pulling the system down.

Anyway, regardless of how big the heap size per VM is, having only 7Mb free on boot is going to cause a lot of app unloading when switching tasks. Are you getting similar figures on your ROM, or have I got something odd going on?

In a way it seems like a testament to how good the android memory /app switching system is that it can manage at all with such low resources.