The Saga of a CyanogenMod Exynos4 device maintainer - Samsung, the Hope-Killer

Disclaimer:  This series of posts contains the personal opinion/perspective of just one member of the team.  It is not, in any way, an official statement from the project.

This is a continuation of the saga, with the last installment being

So, on Monday after the BABBQ, I flew home (FAIL on my part - 9 AM flight on a Monday.  I am NOT doing THAT again.  I had to go to bed early Sunday evening because of that failure to properly choose flights.)

As documented in the previous post, I flew back hopeful that things would finally improve with Samsung.

Only a few days after, +Daniel Hillenbrand emailed our Samsung contact with some questions related to Galaxy Tab 2 call audio.  Specifically, Bluetooth calls on these devices become silent after a few seconds in AOSP, with the RIL popping out an unknown unsol response and also an "am" intent:

E/RILJ    (  533): Exception processing unsol response: 11022Exception:java.lang.RuntimeException: Unrecognized unsol response: 11022
D/RILJ    (  533): [UNSL]< RIL_UNSOL_AM broadcast -a android.intent.action.pcmclkctrl --ez status true
D/RILJ    (  533): Executing AM: broadcast -a android.intent.action.pcmclkctrl --ez status true

(Remember my "spoiler alert" at - here's where it's important)

Within four hours, he received a response of "we can't/won't help you.  contact Wolfson".  Huh?  Wolfson?  For a RIL issue, and an issue not seen on any other Wolfson-audio-enabled device?

So, just after promising to be more open and helpful to developers, Samsung was being faster than ever with the "no, no help for you" responses.  Daniel lost hope at this point, and I lost most of the hope I had gained at BABBQ after hearing about this too.

A few days later, we saw the Insignal code repositories at open up.  On Thursday, someone sent me a message on gtalk indicating that code had just been pushed to

YES!!!  New code!  Well...  not really.  While it had a few new things (LPA audio, some additional HDMI bits), it still exhibited ALL of the problems that the old Insignal reference source and the Hardkernel reference source did.  In short, it was completely useless on 99% of the Exynos4 devices in the world for reasons none of us had been able to figure out for the past six months.

A waiting game started, where we hoped we would see an update to this code.  We saw code pushed to the other platform repos, but it was nothing we didn't already have/weren't already using.

Eventually, the "about" page was updated - - It was very explicit that only Exynos 4412 devices were receiving ICS reference source...  Dafuq?  While working 4412 sources should easily have been backportable to 4210, the fact was, other manufacturers weren't EOLing their SoCs so rapidly.  In addition, at this point, Jellybean was pushed for Exynos5 devices.  Conspiciously missing from these Jellybean repositories was ANY signs of Exynos4 support, in addition to the fact that Exynos4 was explicitly called out as only being supported by ICS in the sources.

Similarly, was published with no discussion whatsoever of Jellybean on Exynos4 - despite the fact that at that point, Jellybean had been available on Exynos4 handsets for over a month and a half.  So "the code doesn't exist" isn't an excuse here - it clearly exists on the I9300 and N7100!

In addition, the schedule is interesting in that they could code everything "green" and not deliver the items (such as working functional HWC and not the compiles-but-does-nothing placebo they've published so far) that got them into this mess in the first place.  As far as graphics subsystem support goes, their definition of success is "boots to lock screen" - SERIOUSLY?  Almost anyone, even winzip kangbangers, can get a device to boot to the lock screen.  That doesn't mean the device's graphics subsystem will be remotely functional/usable.  HWC could be completely missing and they could still claim "green/done" on that schedule.

In addition, SamsungExynos on Twitter is now linking to Insignal saying "the sources are here" - indicating they consider that the useless cruft they've pushed out fulfills their promises to the community.

Last but not least, Jellybean on Exynos4 is "out of plan" for Samsung, despite the fact that I9300 has had Jellybean for over a month and a half - - "I'm sorry to say JB version for Exynos4 is out of plan until now, as I know."

So, at this point, I've basically lost all hope.  While I have a few things I was going to ask the people I met at BABBQ, after seeing how quickly they responded with "no we won't help you" to Daniel just after BABBQ, it's not worth my time even writing the email...

All of this has just been yet another case of Samsung talking and making promises and failing to deliver, just like they've been talking and making promises for over a year.  Development boards are supposed to be AHEAD of handsets - they don't need to deal with carrier testing, wireless certifications, or any of the things that are usually notorious for holding back handset updates.  Plus their intended target is DEVELOPERS, so they should be the "bleeding edge".  This is what Qualcomm and TI reference source is - It's the absolute latest, ahead of anything seen on handsets.  What we're getting from Samsung is more than 6 months out of date - ICS for an SoC that was in a handset which launched with ICS in Spring 2012, and which received an official Jellybean update (carrier approvals/wireless certs and all) in early October 2012...  But they're still working on ICS for their reference source???

The next post in the saga will be the conclusion, summarizing where I stand/how I feel after all this crap I've dealt with, and what I know of where some of the other Exynos4 maintainers stand.

The conclusion is posted at
Shared publiclyView activity