How to patch a framework?

Paul Kocialkowski paulk at
Thu Jul 25 16:59:56 UTC 2013

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.

> 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.

> 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)?

> 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.

More information about the Replicant mailing list