How to patch a framework?

[Dr. H. Nikolaus Schaller]

Hi Paul,

Am 25.07.2013 um 18:59 schrieb Paul Kocialkowski:

> Le lundi 22 juillet 2013 à 11:20 +0200, Dr. H. Nikolaus Schaller a
> écrit :
>> we have a minor issue with the GTA04 battery subsystem. The special situation is
>> that there may be two battery drivers in /sys/class/power_supply and if I understand
>> the code in frameworks/base/services/jni/com_android_server_BatteryService.cpp
>> correctly the batteries are picked up randomly and only one is processed.
> 
> I doubt there is an fact two batteries at any moment, so my answer is
> that we must handle that in the kernel, and probably unload one module
> or the other when it's not in use.

I have analysed the code in com_android_server_BatteryService.cpp and it
is only prepared to locate one battery at launch time. Or it will mix the values from
several batteries and take one more or less randomly (well, it will be the last
battery found in /sys/class/power_supply).

> 
>> Now the question is how we can patch replicant to provide our own 
>> com_android_server_BatteryService.cpp. I tried to add 
>> 
>> device/goldelico/gta04/overlay/frameworks/base/services/jni/com_android_server_BatteryService.cpp
>> 
>> but it appears that it is not compiled. Or do I have to run a make clean before?
> 
> I don't think the overlay works on code too (but I haven't really tried,
> it might). It is indeed a good idea to clean the build tree before
> trying that.

I have found some hints that they don't work for code. So I have to develop
a patch to be applied to the sources.

> 
>> The reason that we have two Battery drivers is that there are variants of the
>> GTA04 (e.g. Letux 3704) which don't have a HDQ battery while others have it.
>> And we want to have a single image for all these variants since maintaining
>> and developing such variants is a lot of work and preventing to simply swap
>> SD cards between them.
> 
> Is there no way to let the kernel detect which device is present and
> load the correct driver accordingly (for instance by registering the
> platform data for one driver or the other driver)?

That is very difficult and I have no idea how to do it. Interactions between
drivers as suggested are quite unusual...

Well, and we don't even have the HDQ driver anywhere in any gta04
specific code. It just appears if it runs on an OMAP3 and HDQ is configured.

We only can suppress registration of the new battery voltage driver.

> 
>> So the kernel/user-space code should be able to adapt to such small differences
>> like a HDQ driver (in kernel) reports 'no battery' and then switch to a backup
>> battery driver that simply estimates based on the battery voltage.
> 
> Anyway if the solution is about detecting a "No battery" state and
> switching to the next battery sysfs when that happens, we might as well
> modify the framework directly, provided that it's implemented cleanly
> and doesn't break other devices.

Yes, that is what I have planned how it should be done. It will still not be
perfect, but appears doable in a non-conflicting way.

It may also help for other devices with different battery options. It may eve
be a fallback for devices where there are some batteries in the wild that
have HDQ and others don't. Like we can use Nokia BL6 batteries as a
(non-HDQ) substitute.

So if it is ok for you, I will experiment to develop a patch for
com_android_server_BatteryService.cpp

BR,
Nikolaus