Workarounds/known issues 7/22: Updated for FRX07

[jinro]

Thank you manekineko and arrrghhh. It seemed to be related to my account not syncing properly on the phone (would not sync email nor calendar either). Deleting the data.img file and rebooting and resetting up the account brought back the sync.

[F22]

Originally Posted by F22

Yup, it's been in all of my more recent rootfs images, and I entirely agree. The funny thing is that I forgot to mention that it was present in my announcement until I read your post earlier today. Your post reminded me that I really should mention that it's in there. It really is a nice little feature. I have no idea why the button was originally mapped to REAR_MUTE instead of MUTE to begin with in the layout file, there is no REAR_MUTE keycode in android, so the framework didn't have a clue about what to do with it.

Manekineko, I just remembered that you had brought this subject up with me in mid-January. DOH. I'm getting forgetful in my old age. :P I didn't get around to it for another 2 days after our conversation, but once I did look at it I pretty much came to the same eminently sensible conclusion you did on your own. So I owe you credit for putting the idea of reassigning the rear mute key in my head.

[[sammich]]

Stickied

[gtmethod3]

Originally Posted by [sammich]

Stickied

Great news!



I'm not sure if this has been mentioned or not, I did not see it on the list. I have noticed that my battery drops 20%-30% whenever I make a call and shortly after I hang up (2-4 mins) the battery level slowly creeps back up. My guess is that when the communications chip becomes active, the current it uses causes the battery to think it is lower than it should be.

This makes sense since phones have rated talk time and standby time. No idea how to fix it, just figured I would make note.

[arrrghhh]

Originally Posted by gtmethod3

I'm not sure if this has been mentioned or not, I did not see it on the list. I have noticed that my battery drops 20%-30% whenever I make a call and shortly after I hang up (2-4 mins) the battery level slowly creeps back up. My guess is that when the communications chip becomes active, the current it uses causes the battery to think it is lower than it should be.

This makes sense since phones have rated talk time and standby time. No idea how to fix it, just figured I would make note.

You noticed that too eh? viruscrazy explained that camro's battery code doesn't take into account peripherals whatsoever - so basically any radio, modem, etc that draws from the battery is not taken into account.

I've been chatting with WisTilt2 about this frequently as well, and there's a lot of agreement that the battery code is going to need to be either completely rewritten or severely overhauled. Not to discount camro and his work, but he never really finished his work as his phone blew up basically and never returned to the scene. We were going to get him a phone, but he didn't seem interested. So it's not an easy fix, but we do know what needs to be done at least - and sometimes that's half the battle .

WisTilt2 has a lot of things on his plate with this project at this point, but he did say he wanted to talk to jonpry soon about rewriting this code. I look forward to seeing what he can do to improve this - there's a lot of bugs with the battery code, they're just not easily seen as batteries are mysterious beasts.

[manekineko]

Originally Posted by gtmethod3

Great news!



I'm not sure if this has been mentioned or not, I did not see it on the list. I have noticed that my battery drops 20%-30% whenever I make a call and shortly after I hang up (2-4 mins) the battery level slowly creeps back up. My guess is that when the communications chip becomes active, the current it uses causes the battery to think it is lower than it should be.

This makes sense since phones have rated talk time and standby time. No idea how to fix it, just figured I would make note.

Thanks! Added it to the list.

[gtmethod3]

Originally Posted by arrrghhh

You noticed that too eh? viruscrazy explained that camro's battery code doesn't take into account peripherals whatsoever - so basically any radio, modem, etc that draws from the battery is not taken into account.

I've been chatting with WisTilt2 about this frequently as well, and there's a lot of agreement that the battery code is going to need to be either completely rewritten or severely overhauled. Not to discount camro and his work, but he never really finished his work as his phone blew up basically and never returned to the scene. We were going to get him a phone, but he didn't seem interested. So it's not an easy fix, but we do know what needs to be done at least - and sometimes that's half the battle .

WisTilt2 has a lot of things on his plate with this project at this point, but he did say he wanted to talk to jonpry soon about rewriting this code. I look forward to seeing what he can do to improve this - there's a lot of bugs with the battery code, they're just not easily seen as batteries are mysterious beasts.

Ahh, that makes a lot of sense. It's interesting to think how much coding is involved for a simple battery reading. I can't imagine what coding the rest of the device could be like!

Thanks for the reply, not a huge issue by any means, but a minor annoyance. I have noticed that different battery meters from the market give me back different readings sometimes but usually return to a roughly similar value. Perhaps they use different algorithms.

Wouldn't a relatively simple thing be to apply some sort of moving average in the reading? it wouldn't fix it in the long run but get rid of the small fluctuations. Though its such a minor issue that it may not even be worth it. I wish I knew how to code in Linux!

[arrrghhh]

Originally Posted by gtmethod3

Wouldn't a relatively simple thing be to apply some sort of moving average in the reading? it wouldn't fix it in the long run but get rid of the small fluctuations. Though its such a minor issue that it may not even be worth it. I wish I knew how to code in Linux!

Ironically camro did basically just that. Meter used to be WAY jumpier. I'm guessing you weren't around pre-Oct 2010 .

[manekineko]

System server bug removed from list thanks to the new rootfs.img.

Always satisfying to remove something from the list!

[arrrghhh]

Originally Posted by manekineko

System server bug removed from list thanks to the new rootfs.img.

Always satisfying to remove something from the list!

Heck yes. Awesome work by stine, considering his device didn't even exhibit the behavior .