Quoting "Robin Humble" <[email protected]> > so maybe we should back up here and ask what is it that you actually > want to do with this phone?
Well, let me start with David Bowie who has the best catch phrases for everything: "I demand a better future": http://www.youtube.com/watch?v=eoWJm5pzcMQ Well, it's for playing. For "normal use" it is already useless out of the box: It even completely logs out from the phone network after a while so I am not reachable (to be honest I did not expect it to be _that_ useless) I don't like the idea of having a device which I don't control and it is closed source (even if it is Android, an "open source operating system"). Well, that's as it is now but to be able to understand how it works, and then think about ways to tweak it for me. Thanks for your mail, it helps me a lot. > Note that the vast majority of the android blobs are userland binary > blobs - not kernel - the device specific kernel is released as (usually > shitty) source because of GPL compliance. vendors typically modify a > standard android kernel enough to support the hardware, and then put all > the real smarts in userspace with the kernel layer being minimal. Okay, the kernel only sends "0x03 875" to the radio receiver and only closed source libradio.so knows what it means (having a function "switchStation(frequency)" in it)? > nothing is impossible, and with enough glue code and compat layers and > forward and backward porting those blobs could continue to be ok for a > long time, but it might easily be 1000's of lines of (usually android > framework) code, and a lot of understanding of what is changing and why. > > indeed, the above blobs are (I think) from Gingerbread (Android 2.3) > which was the last drop that the vendor did for the phone, and yet the > roms I currently build are JB (4.3) because many people have written > enough compat code to workaround all the API/ABI changes in android > over time and keep the blobs happy. > >> Does it mean there is a stable ABIs to hook the drivers into a >> Android kernel? >> How stable is this? E.g. all from Android 4.0 to 4.1 to .. 4.4? Linux >> 3.8 to 3.10 to..? > > rom variants generally coalesce around specific blob drops from the > vendor that often match android drops. > > as long as userland sees exactly the same data from the kernel and the > binary kernel modules still (ie. same kernel version) load then you can > backport as many features to a kernel as you want. if you are lucky > enough to have no binary kernel modules then you can probably use a > much newer android kernel as long as it has android specific features > that match the blobs. ie. there might not be much of a win. In a newer FreeBSD version you can include a COMPAT_x option, e.g: options COMPAT_FREEBSD4 options COMPAT_FREEBSD5 options COMPAT_FREEBSD6 options COMPAT_FREEBSD7 so I can build a FreeBSD 9 kernel which is compatible with binaries written for FreeBSD 4 (which had EoL 2007) The ABI is usually stable over a major release so it does not matter which FreeBSD 9.x it is. I frequently have "minor mismatch" because I run newer jails on a kernel I did not update for a while. You have written something similar as I understand, so you have ZTE BLOBs from Android 2.3 still working. But is a bit more about the spots _you_ need so it may not work for all Android 2.3 BLOBs? I wonder sometimes how much of "smarts" are in the BLOBs which are worth to be hidden or could be easily open sourced without any commercial damage for the manufacturer, e.g. ZTE. Thanks for ideas Peter _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
