Occasionally software companies that Hatch makes custom Android tablets or custom Android smartphones for request access to the source code running on their device. They feel that they understand Android well enough to work on the source code and want to get more connected to their product. These requests are fair and honorable. Their idea is that they can quickly resolve software bugs or experiment changes in code on their own, but unfortunately the source code isn’t what they expect.
While the neutral AOSP (Android Open Source Project) source code is available for anyone to download that alone can’t run on actual hardware without modifications tailored around the specific hardware used in the device. Android CPU (Central Processing Unit), the main IC chip in an Android product, manufacturers like Rockchips, Qualcomm, Mediatek, and others that make chips which run Android spend a lot of money on engineers’ salaries to modify the Android source code to run smoothly on their reference designs. IC companies provide reference designs to the engineers who design final products so they know exactly which components to choose in the product. Sometimes the Android IC manufacturers also purchase code from third party software companies or use proprietary code from third party component companies to integrate into the Android BSP (Board Support Package) that runs on their devices. After making their own modifications or integrating those of other companies, these Android IC companies don’t release the device-specific full source code to anyone outside of their company (with very rare exceptions based on economic interests). Usually engineers at the CPU companies themselves only get access to the parts they actually work on. The BSP is Android firmware that has been custom tailored to a specific CPU and reference design.
Once the Android IC manufacturer has a nearly stable build of the BSP completed they’ll work with their licensed engineering partners, called design houses, to fix the final bugs.
Design Houses (‘DH’) are the engineering companies that build finished products using the CPU, reference design, and BSP developed by a CPU manufacturer. Usually DHs are loyal to one CPU manufacturer’s product line. In some cases one DH will work with more than one CPU if there are differences in their product lines for example one manufacturer makes CPUs for Wi-Fi only devices while another one makes CPUs that support mobile data.
Here’s a simple example to understand the relationship between Android CPU manufacturers and DHs. The CPU manufacturer makes the engine of an airplane and the DH designs the rest of the plane around that engine, taking into consideration things like power, fuel consumption, and other criteria. The engine manufacturer can spend years designing and building an engine, but until that engine is actually tested in a real plane no one knows what problems will appear. The DHs feedback those problems to the CPU company and the CPU company works with the DHs to fix the problems. Over time the issues are resolved. Quite often, with new chip releases, not all the problems are discovered before buyers get access to the newest technology and as a result it’s really important for Android tablet or smartphone brands to start with small orders of a new chipset to minimize risk of an unforeseen failure.
Back to the firmware.
In this article the term ‘firmware’ is used to refer to the software running the Android OS. When the DHs get the firmware from the Android CPU companies a lot of the time consuming modifications that concern integrating components of the reference design have been done and are stored in closed off .bin files. The reference design usually includes Wi-Fi, Bluetooth, and power management. That means that the DH doesn’t have access to this closed software. In a situation where an end customer (meaning the tablet or smartphone buyer) requires changes to the firmware that involve a closed piece of code only the CPU manufacturer can implement those changes. Since the DH and the CPU manufacturer are dedicated partners it’s understood that the CPU manufacturer will help the DH to make the modifications they require. On top of that the DH closes off their own source code for drivers that relate to components outside of the reference design such as cameras, screens, touch panels, etc. Those drivers are provided and optimized by the component vendors and the DH is more open to releasing that to a customer, on an as-needed basis.
When customers ask Hatch for the source code, depending on the CPU being used, we’re generally able to work out an agreement where the customer can get the same source code that the DH gets from the CPU company at the beginning of a project.
They are less likely to release the source code that contains custom modifications made specifically for the end customer product because they already invested in making those changes and don’t want to risk losing that investment. This still doesn’t mean that the customer, even one with a good engineering team, can do everything they want with it due to all the closed parts of the source code. Oftentimes when customers really want to control their own source code they’ll need to send an engineer to China to work out of the DH offices, alongside a DH engineer, for real time troubleshooting with the DH engineers and through the DH engineers to the CPU manufacturer directly.
The reason for this is that the reference design level source code modifications made or purchased by the CPU manufacturer are kept secret by the CPU manufacturer. Secondly the optimized drivers made by the DH or component suppliers are either closed or require a bit of know-how in order to effectively manipulate. For people new to these terms, a ‘driver’ is the software that ties key components such as Wi-Fi, a touch screen, cameras, etc. to the CPU. So in order to get access to all this custom Android code both the CPU manufacturer and DH must agree to open the additional work they do on top of the AOSP.
Source code itself is generally specific to a certain IC or set of ICs. The manufacturers of those ICs (like the CPU manufacturer) shouldn’t have a problem giving more people access to their source code since it means those people will likely buy their IC’s, but the algorithm logic used in the code can be applied to the chips of competitors. These proprietary and reusable algorithms are what they want to protect.
To summarize there are different levels of Android source code modification that have different levels of confidentiality and value (in the order below):
- Changes made by the CPU manufacturer to integrate key components in a reference design (usually Wi-Fi, Bluetooth, and power management).
- Third party code that the manufacturer doesn’t have the right or interest to release.
- Driver code from component manufacturers created for the DH for components that aren’t part of the reference design (like screens, cameras, memory, and touch panel).
- Custom Android code created by the DH per the specific customer requests for the final product.
While it is possible to get work done on all levels of the source code, it’s usually not possible to get access to all levels of the code. The amount of custom work that a client can expect directly correlates with the potential volume of the client or size of the order since the DHs and CPU manufacturers make money by selling components. In any event the client should make clear at the very beginning of a project exactly what their source code requirements are because once custom work gets started it becomes less and less likely or more and more expensive to get access to that.
