Aligning the Arvenna BSP Drop with the Android Platform Timeline

Good afternoon here in Seoul, and good morning to those of you in Europe and California. Thank you for making the time on a Sunday; I know this isn't ideal for anyone. Let's start with introductions, since a few of us are meeting for the first time. I'm Hyejin, the software program manager for Atlas on our side.

I'm Daniel, technical lead for Kernel and BSP. My team will be the main consumer of your BSP drops, so I'll probably be the one asking the annoying questions today.

Hi everyone, Marco Lindqvist, customer engineering manager at Arvenna, based in Stockholm. I own the relationship with your team for the new chipset, so anything that's late or broken on our side, I'm the one you should call.

And I'm Priya, the BSP release lead at Arvenna. I manage what goes into each drop and when it ships. I'm also in Stockholm, so it's still early for me, but the coffee is working.

Kevin Albright, partner engineering at Google, joining from Mountain View. My role is to help device makers stay aligned with the Android release schedule and the compatibility requirements, so I'm mostly here to listen and to flag anything that could cause trouble with certification later.

Thank you all. The purpose of today's call is simple: we need a BSP release plan that we can actually build a product schedule on. Concretely, I'd like to leave this call with three things nailed down: the first drop date and content, the cadence of drops after that, and how both line up with Google's platform milestones.

Let me start with where we are. The first drop, which we call BSP 0.5, is on track for August 14th. It will boot to a kernel console and an Android shell on our evaluation board. Display, storage, USB, and basic power management are in. Camera, modem, and audio are not included in 0.5; those come later.

Thanks, Priya. That matches what we expected for the content. My first question is about the kernel version. Our assumption was that 0.5 would be based on the 6.12 branch, since that's the kernel we're committing to for Atlas. Can you confirm that?

That's where I need to be transparent with you. The 0.5 drop will be on 6.6. Our 6.12 port is about three weeks behind, mainly because the new power management controller driver needed a significant rework for the newer kernel. We plan to move to 6.12 in the second drop.

I appreciate the honesty, but that's a significant change from what we were told in June. If we start bring-up on 6.6 and then switch to 6.12 a month later, we're effectively doing bring-up twice. Every patch we write on 6.6 has to be ported again. I'm not sure that's a good use of anyone's time.

I understand the frustration, Daniel, and I own that we didn't communicate this early enough. Let me offer some context. The alternative was to delay the entire first drop by three weeks. We assumed that having something on hardware early would be more valuable to you than waiting for the right kernel. If that assumption is wrong, we should talk about it now.

Let's look at it from both angles before we decide. Daniel, what would you actually do with a 6.6 drop on August 14th? Is any of that work throwaway, or does some of it carry over?

Fair question. Hardware validation carries over: checking that the board powers up, that the memory training passes, that our display panel lights up. That's maybe forty percent of early bring-up. Driver integration and our own kernel patches mostly don't carry over. So it's not all wasted, but it's not ideal either.

If I could jump in from the Google side, there's a compliance angle here that's worth keeping in mind. For devices launching on the next Android release, the kernel needs to be on a supported Generic Kernel Image branch, and 6.6 will not be accepted for a new launch on that release. So whatever you do in the short term, the launch build has to be on 6.12. There's no flexibility on that.

Yes, we're fully aligned on that, Kevin. 6.12 is our production target for this chipset. The question is only about the first drop.

Then let me suggest a middle ground. Ship 0.5 on 6.6 on August 14th as planned, and we'll use it strictly for hardware validation. No driver integration, no product patches. In parallel, can you give us early access to your 6.12 development branch, even if it's unstable? Our engineers can start porting against that, so when 1.0 lands, we're not starting from zero.

That's doable in principle. The development branch isn't something we normally share, because it changes daily and it breaks often. But we've done it for one other customer under a separate agreement. I'd need to check with our legal team about the terms, but I don't see a technical blocker.

I'll take that action and push it through on our side. Realistically, I think we can get the paperwork done within a week. Would access starting around August 10th work for you?

That would work well. It actually lines up with our development start on the 17th, so the team could hit the ground running.

One more thing from my side while we're on the kernel. Please make sure your vendor modules are built against the official GKI symbol list from the start. We've seen partners accumulate private symbol exports during bring-up, and then spend weeks cleaning them up before certification. It's much cheaper to keep it clean as you go.

Point taken. Our 6.12 modules are already built against the symbol list, and we have a check in our CI that fails the build if a module uses a symbol outside it.

Good. Let's move to the second item: cadence. Priya, what does the drop schedule look like after 0.5?

Our standard plan is a major drop every four weeks. So 1.0 on September 11th, which moves to 6.12 and adds camera and audio. Then 1.1 on October 9th with the modem and full power management. After that, we switch to maintenance drops every two weeks until your launch, with only bug fixes and security patches.

Four weeks between major drops is a long time during bring-up. When we find a blocker in your code in week one, we don't want to wait three more weeks for the fix. Could we have weekly intermediate drops, or at least a channel for hot fixes between the major drops?

Weekly full drops would be hard, because each drop goes through about four days of our own regression testing. But a hot fix channel is very reasonable. We can deliver individual patches through our customer portal within two working days for anything you classify as a blocker, and roll them into the next major drop.

Two working days for blockers sounds good. How do we define a blocker, though? I want to avoid a situation where everything gets labeled a blocker just to get faster service.

That's a fair concern, and it's happened before with other customers. I'd propose that a blocker is anything that prevents boot, causes data loss, or stops a milestone test from running. Everything else goes into the normal queue. And let's cap it informally at five open blockers at a time, so we're forced to prioritize together.

I can live with that definition. The cap of five makes me a little nervous during bring-up, but let's try it and revisit at the end of September if it's not working.

Let me map that against our side. The final platform release for the next Android version is currently planned for early December, with the last developer preview in October. Your 1.1 drop in October lines up with that preview, which is good. The thing to watch is the security patch level. For launch, you'll need a patch level no older than ninety days at the time of certification, so your maintenance drops have to keep pulling in the monthly security bulletins.

That's helpful. Kevin, could you send us the platform milestone dates in writing? Our internal plan has feature complete at the end of November, and I'd like to confirm we're not building on a moving base.

I can share the partner timeline document, which has the dates as they stand today. I'd caveat that the final release date can still move by a couple of weeks, but we typically give partners at least a month's notice if it does.

Before we wrap up the cadence topic, I'd like to talk about what quality we can expect in each drop. On Orion, we lost about a week per drop because the release notes didn't list known issues, and our engineers spent days debugging problems that your team already knew about. That's the kind of waste I really want to avoid this time.

That's completely fair, and it's something we've changed internally since then. Every drop now comes with a known issues list generated straight from our tracker, plus our own test results: which test suites ran, the pass rate, and any tests we skipped and why. If something is in the list, you shouldn't have to rediscover it.

That's great to hear. Would you also be open to sharing the raw logs from your stress runs? Sometimes a crash signature we see on our hardware matches something in your lab, and being able to compare call stacks directly saves a lot of back and forth.

We can share crash signatures and stack traces without any issue. Full logs are trickier because they sometimes contain data from other customers' configurations. Let me see if we can set up a filtered export. I don't want to promise something I can't deliver, so I'll come back to you on that one.

That's a reasonable answer. Signatures and stack traces already cover most of what Daniel's team needs, so let's start there and treat the full logs as a nice-to-have.

From the Google side, I'd encourage you to run the vendor test suite on every major drop, not just before certification. Failures in that suite are much easier to fix in September than in January, and they're often a sign that a vendor module is drifting away from the interface we expect.

We already run it nightly on our side, Kevin, so I'll include those results in the drop report as well. That way both teams are looking at the same numbers.

Great, I think we've covered the main points. Let me summarize what we've agreed, and please stop me if anything is wrong. BSP 0.5 ships on August 14th on kernel 6.6 and will be used only for hardware validation. Arvenna provides early access to the 6.12 development branch from around August 10th. BSP 1.0 on 6.12 ships on September 11th, and 1.1 on October 9th. Blockers get hot fixes within two working days, with a soft cap of five open blockers.

That's accurate from our side. On action items, I'll get the development branch agreement through legal by August 9th, and send you written confirmation of the drop dates by Wednesday.

I'll publish the content list for 0.5 and 1.0 on the portal by Tuesday, including the known issues, so your team knows what to expect before the code arrives.

And I'll send the partner timeline document today, along with the current GKI requirements for the next release.

On our side, I'll set up the hardware validation plan for 0.5 and assign two engineers to start porting against the 6.12 branch as soon as we have access. I'll also share our list of out-of-tree patches, so Priya's team can tell us which ones might already be covered upstream.

One last point on escalation. If a drop is going to slip, even by a few days, I'd like to hear about it as soon as you know, not on the planned delivery date. Our internal plan has a trigger: if the BSP is more than five working days late, we formally replan the program. I'd rather we never reach that trigger, and early warning is the best way to avoid it.

Understood, and that's a fair expectation. I'll commit to flagging any risk to a drop date at least one week ahead, together with a recovery plan. If I don't have a recovery plan yet, I'll still tell you, and we can work on it together rather than surprising you at the last minute.

Thank you, everyone. This was a difficult conversation in parts, but I think we ended up in a much better place than where we started. Let's make this a recurring vendor sync. The next one is Monday, August 10th, at 4 p.m. Korea time, which is 9 a.m. in Stockholm and midnight in Mountain View, so Kevin, please feel free to join only when there's a platform topic.

Much appreciated. I'll keep an eye on the minutes and dial in when you need me.

Thanks, Hyejin. And Daniel, thanks for being direct about the kernel issue. It's much easier to fix problems when we hear about them early.

Likewise. Talk to you on the tenth.