Easy (and fair) question, difficult answer
I will try to keep it grounded and simple, and here are the main reasons why monthly updates come sometimes “late” compared to other manufacturers:
- Non-security changes: there are often changes and fixes released together with security updates that make the whole release process slower, as those changes need to be thoroughly verified and they sometimes disrupt the acceptance process with our partners.
As you noticed, sometimes we consciously only deliver security updates to make sure the delivery is not at risk, but we often also need to prioritize fixes for issues that are impactful to you and, obviously, you expect a fix for. - Last-minute patch changes: although the security bulletins are available in advance, the related patches are not always available when the bulletin is released and it sometimes changes multiple times (or is even postponed) before the end of the month.
The reason behind this is easy to catch: Android must work on dozens of different chipsets, with different hardware configurations and sometimes even different ARM architectures. Thus, the patch is sometimes stable for some, but very unstable for others. - 1st of the month vs 5th of the month: as you might have noticed, there are 2 different security patch levels - 1st of the month and 5th of the month.
In very short, the 1st of the month patches only include framework changes (Android system layer) while the 5th of the month patches also include OEM-specific patches, chipset manufacturer patches, some kernel modules patches, etc.
Although the difference sounds small, it is, in practice, very big: the Android framework layer is normally standard and kind of similar across different devices, thus is also more stable.
Applying a patch to the framework is less risky (in terms of stability) than applying a patch to the kernel or the firmware(s).
We decided, at some point, to aim for the 5th of the month to deliver you the best security possible in advance, but this decision comes with a little time price in terms of implementation and testing.
Is this decision set in stone? Absolutely not, at some point we might change it, but for the time being this is the standard we follow.
There are of course also a bunch of other factors that can slow down the process, but the above points are the more constant ones.
I can tell you that the topic (make the security patches delivery more time-efficient) is definitely on our agenda for next year