Hi Dave > I re-read the old thread and bugs and had a few questions/thoughts. > > Has anybody reached out to our partners and taken a survey of the ways > they modify our code for their devices? If there are patterns (e.g. > they all disable feature X) then maybe we should consider abstracting > away that part and make it super easy for them to provide their own > implementations. An abstraction opens the possibility of swapping > their implementation with another implementation at a later date--like > after the vendor has dropped support.
We sort of have this abstraction, but Gecko moves fast and the vendor implementations usually don't keep up. At some point it's not compatible any more. Unfortunately, vendor binaries are required for central phone functionality (e.g., phone calls). This means that we are currently unable to provide updates by ourselves; except minor bug fixes for specific versions. To solve this problem, we need to move all drivers out of Gecko and provide (semi-)stable interfaces that we can support over a longer period of time. The two critical areas I know of are in Geolocation and RIL. For Geolocation I opened bug 1107539, [1] but didn't have time to work on it. As far as I understand, the vendor modifications to Geolocation are minor and maybe we can completely move them into an external program. For RIL, there are ideas to keep some of Gecko's internal interfaces stable, so that vendor binaries continue to work with newer versions of Gecko. I don't know what the status here is. Another idea is to write a RIL daemon that encapsulates older vendor RIL binaries. The daemon would contain an instance of Gecko that is compatible with the vendor binary. Our updated Gecko implementation could use its RIL code to talk to this RIL daemon, which translates it into calls to the vendor RIL. And there are differences between the two interfaces (RIL protocol and RIL API) that the RIL daemon somehow had to handle. Best regards Thomas [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1107539 > > What I'm getting at, is maybe there is a third option with vendors > where we negotiate a "sunset clause" situation. The partners provide > us with a signed app that "unlocks" their phones before they ship. > They lock their phone down and ship. Then when the partner officially > drops support (or otherwise authorizes us), we'll release the unlock > app via FOTA update or through the marketplace. It would replace the > swappable piece with the stock one and allow the user to change their > update channel to whatever they want. This attempts to balance the > partner's financial interests with the long-term interests of users. > Plus it makes FxOS easier to customize by the vendors. > > --dave > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
