Qualcomm‘s latest high-end system-on-chip, the Qualcomm Snapdragon 845, was announced at the Snapdragon Tech Summit back in December. The chipset offers 4 Kryo 385 (A75 “performance”) and 4 Kryo 385 (A55 “efficiency”) CPU cores, the latest Adreno 630 GPU, the Spectra 280 ISP, the Hexagon 685 DSP, and the Snapdragon X20 LTE modem. There’s also a new Secure Processing Unit (SPU) and a dedicated Hi-Fi DAC that supports 32-bit audio called the AQT1000. The Snapdragon 845 SoC is a powerhouse in benchmarks and it is already available in devices like the Samsung Galaxy S9/S9+, Xiaomi Mi Mix 2S, and the OnePlus 6. Developers on our forums have been itching to get their hands on a device with Qualcomm’s latest and greatest, but there’s just one thing that has made some developers worry about the future of development on the platform: The lack of publicly available source code for the kernel, HALs, framework branches, and more on the CodeAurora Forums.
Qualcomm and the CodeAurora Forums
If you’ve ever wondered why developers on our forums favor working on devices with Qualcomm chipsets over devices with chipsets from HiSilicon, Samsung, MediaTek, and others, the reason is that of Qualcomm’s friendliness with the custom development community. The Android that custom ROM developers build from is based on the Android Open Source Project (AOSP). Google releases a public part of AOSP but they also develop parts of Android in private (which is why if you build a ROM from AOSP today, you won’t get any of the fancy new features in Android P.) For custom ROM developers, the only choice they have to merge Android’s latest platform features is to wait for Google to release the source code with the final release. Chipset vendors, however, have an agreement with Google to get early access to the next version of Android—they fork from the private AOSP repositories, modify their chipset code to be compatible, and then distribute this code to OEMs to build and distribute ROMs for their devices.
General update process for each release of Android. Source: Google.
To abide by the GNU General Public License (GPL) under which the Linux kernel is licensed, the chipset vendors and OEMs are required to release the kernel source code, but that’s all they’re required to release. The kernel source code for the Qualcomm Snapdragon 845 Samsung Galaxy S9/S9+, Xiaomi Mi Mix 2S, and the OnePlus 6 are already available, for instance. That’s enough for developers to get started on porting AOSP-based custom ROMs on these devices, but just having access to the kernel source code doesn’t mean it’ll be easy to port LineageOS 15.1 to these devices (though that’s changing thanks to Project Treble). All of the chipset specific code for new chipset features is usually unavailable in these kernel source code releases, which is expected since the code would reveal how proprietary chipset features work. Developers have access to this code in the form of precompiled binaries (called a Binary Large Object or BLOB), but it’s nearly impossible to combine these BLOBs with their work on an AOSP ROM since there’s no documentation on how that would work.
Fortunately for developers, that’s where Qualcomm’s CodeAurora Forums (CAF) comes in handy. On CAF, Qualcomm releases the public parts of their chipset specific code in a way that makes it really easy for ROM developers to build for the platform without having to know how the new chipset features work. Developers just need to fork the public parts of the new platform repositories (such as hardware/qcom/display and vendor/qcom-opensource/bluetooth) and combine it with the precompiled binaries and it’ll basically just work for the most part. Qualcomm has released their chipset specific code on CAF for previous SoCs such as the Qualcomm Snapdragon 820/821 and Snapdragon 835, and usually within days of the chipset being announced! However, it has been 5 months since the Snapdragon 845 was announced, and we have yet to see the company’s usual source code drops under the sdm845 branch.
Searching CAF for source code relating to the Qualcomm Snapdragon 835 SoC
The delayed release of sdm845 sources in CAF has led some developers to worry that Qualcomm would be abandoning the forum, in effect becoming like MediaTek by only sharing sources with their partners and not the community. The developers we spoke to are concerned that this would be detrimental to custom ROM development on devices from companies like Xiaomi, as CAF sources are often necessary to build stable ROMs for Xiaomi’s Snapdragon devices. We reached out to Qualcomm to find out what’s going on, and we finally have some good news to share: CAF isn’t being abandoned, it’s just that the Qualcomm Snapdragon 845 code drop won’t happen until Qualcomm announces their new mobile platforms. The reason? Because of leaks.
CodeAurora Forum and Qualcomm Chip Leaks
When Qualcomm engineers are working on new platform features for their chipsets, it’s rare for them to only develop these features with one chipset in mind. It’s possible for unreleased chipsets to use the same software found in already announced chipsets like the Snapdragon 845. While companies often use code names to prevent leaks, even that doesn’t totally prevent leaks from happening. For example, details of the unreleased Qualcomm Snapdragon 670 were found in CAF by Roland Quandt from WinFuture. We later found out from CAF that the Qualcomm Snapdragon 670 was being re-branded to the Qualcomm Snapdragon 710. Qualcomm hasn’t confirmed the existence of the Snapdragon 670/Snapdragon 710, but thanks to references in CAF we already know a lot about the upcoming chipset.
Thus, to prevent leaks like this from occurring, Qualcomm chose to delay the release of source code for the Snapdragon 845. We’re told that the company won’t be releasing the source code for the chipset until after the new mobile platforms are announced. After about 6 weeks from now, the company will be able to release the sdm845 sources on CAF. A Qualcomm representative apologized for the delay in source code release, stating that the company is reviewing their chipset naming conventions in code so they can release code for already announced chipsets while still avoiding leaks.