Kicking Off the OS Upgrade Program for Orion and Orion Lite

Good morning, everyone, and thank you for coming in on a Saturday. I know several of you were in the Atlas checkpoint at ten, so I'll try not to repeat things you've already heard today. I'm Joanne from Program Management, and I'll be running the OS upgrade program for Orion and Orion Lite. Let's go around the table.

Brian, Platform Framework. My team will do most of the heavy lifting on this one, since an OS upgrade is mostly a framework merge.

Elena, also Framework. I'll be the technical lead for the merge itself, and I'll coordinate with the app teams on compatibility.

Chris, Kernel and BSP. I'm here mainly to discuss whether we keep the current kernel or move to a newer one, and what that means for the vendor.

Minji, SQE lead for Orion. And Ryan is joining me because he'll own the carrier certification plan.

Hi, Ryan Cha, SQE. I coordinate with the carrier labs, so most of my questions today will be about dates.

Let me start with the background. Google's next Android release is planned for early December, according to the partner timeline Kevin shared last week. Our commitment to customers is that Orion gets the upgrade, and Orion Lite gets it as well, since both are within their support window. Last year, our competitors delivered their upgrades between four and ten weeks after Google's release. The business would like us to be at the front of that range this time.

So the headline target from the business is a stable rollout for Orion in mid-January, roughly six weeks after Google. Orion Lite would follow about a month later. I'll be honest: that target was set before anyone asked engineering, which is exactly why we're here today.

I appreciate you saying that up front. Mid-January would be ambitious even in a normal year, and this is not a normal year, because Atlas is pulling on the same framework engineers. I'd like to understand how much flexibility there is in that date before we commit to anything.

There's some. What the business really cares about is not being the last one. If we can give them a credible plan with a clear beta milestone, I think February is negotiable. What they won't accept is a vague answer.

Elena, let's start with the biggest piece of work. How big is the framework merge, and how long will it take?

Based on the developer preview we've already pulled, there are roughly fourteen hundred files where Google's changes overlap with our modifications. From experience, about seventy percent of those resolve mechanically. The remaining four hundred or so need someone who understands both sides. My estimate is six weeks for the merge to reach a booting, roughly functional build, and another four weeks to restore feature parity with our current Orion software.

So ten weeks of framework work before we have something we can seriously test. If we started on August 17th, that takes us to the end of October.

That's with a full team, though. Here's the problem. Atlas framework bring-up also starts in late August, and it needs about sixty percent of the same people. If I split the team, both programs slow down. Realistically, with the people I can spare, the upgrade merge takes closer to fourteen weeks.

Fourteen weeks puts us at the end of November, before Google's final release even ships. Is that actually a problem? We'd be merging against preview builds anyway.

It's not a problem by itself. But between the last preview and the final release, Google usually changes a few hundred files. We'd need a second, smaller merge in December. That typically takes two to three weeks, and it's the part that most often surprises people.

Chris, what about the kernel side? Do we need a new kernel for the upgrade?

Good news here, for once. Under Google's rules, devices that upgrade can keep their launch kernel branch, as long as it's still within its support period. Orion and Orion Lite are both on the 6.1 branch, which is supported well beyond next year. So we don't have to do a kernel uplift. That saves us easily two months of work and a lot of risk.

That's a relief. But the vendor side still changes, doesn't it? The new Android version comes with new vendor interface requirements.

Right. The kernel stays, but some hardware abstraction layers need updates to meet the new interface versions. For Orion, Qorvix has to deliver updated camera, audio, and graphics components. I asked them informally last week, and they said they could deliver a first drop by mid-October and a final one by mid-November. I'll get that in writing.

Mid-November for the final vendor drop is fine for us, as long as the first drop in October already has the new interfaces, even if the implementations are rough. We need the interfaces to compile the framework against.

I'll make that an explicit requirement when I talk to them. I'll also ask for their test results on the compatibility suites with each drop, because last year their first upgrade drop failed about three hundred vendor tests, and we only found out when we ran them ourselves two weeks later.

Let's talk about testing, because that's usually where upgrade schedules die. Minji, Ryan?

From SQE's side, an OS upgrade needs three things. First, our full regression suite, which takes about three weeks per round, and we always need at least two rounds. Second, an upgrade-specific test: we take devices with real user data on the old version, upgrade them, and make sure nothing is lost and every app still works. That's the one that catches the scariest bugs. Third, Google's compatibility test suites, which have to pass before we can ship at all.

And then there are the carriers. Orion is sold through forty-two carriers worldwide. The big ones in North America and Korea require their own certification of an OS upgrade, which takes between four and eight weeks after we submit. Some of them also have holiday freezes: two of the US carriers don't accept new submissions between December 15th and January 5th.

That holiday freeze is a big deal. If we can't submit before December 15th, those carriers effectively push us into February, no matter how fast we are.

Exactly. On the other hand, unlocked devices and markets without carrier certification, like most of Europe, could go earlier, as long as Google's compatibility tests pass. So we might want a split rollout: open markets first, then carrier markets as approvals come in.

Let me try to put this together into a draft plan, and you tell me where it breaks. Development starts on August 17th with a reduced framework team. Internal dogfood on preview-based software starts November 2nd. The final Google release lands in early December, and we finish the second merge by December 18th. A public beta for Orion opens on December 21st in Korea and the US. Stable rollout in open markets starts on February 1st, with carrier markets following through February.

November 2nd for dogfood is tight, given Brian's fourteen-week estimate. You'd be giving internal users a build that isn't feature complete. I'm okay with that for engineers, but not for the broader company dogfood population.

That's a good distinction. Let's say engineering dogfood on November 2nd, and company-wide dogfood on November 30th, once feature parity is restored.

That works for me. And for the public beta on December 21st, I'd want at least one week of company-wide dogfood on the final Google release first. December 18th to the 21st is only three days.

Then let's move the public beta to January 4th. That still gives us four weeks of beta before February 1st. Ryan, does that work with the carrier freeze?

Only if we submit to the US carriers before December 15th, which means submitting a build that isn't final yet. Some carriers accept a pre-final submission for early testing and then a quick delta review for the final build. I'd need to negotiate that with each of them, but it's been done before.

I want to flag something before we lock this. Everything we just said assumes the reduced framework team stays reduced, not that it shrinks further. If Atlas hits a crisis in October and pulls more people, this plan breaks. I'd like a rule that pulling people from the upgrade requires a conversation at the program director level, not just a hallway decision.

That's very reasonable, and I'll take it to the program directors on Monday. I'll present it as a dependency between the two programs, so it's visible to both sides.

Let's spend a few minutes on the public beta itself, since it's the first thing customers will see. How many participants are we aiming for, and what do we actually want to learn from it?

For a flagship upgrade, I'd aim for around twenty thousand participants across Korea and the US. That's enough to see crash patterns we'd never find in the lab, especially with third-party apps. What I want to learn most is the upgrade success rate and the top crashing apps after the upgrade, not opinions about new features.

I'd add one more goal: app compatibility. Every Android release changes some behaviors that apps depend on. In the beta, we should automatically report any app that crashes more than twice as often as it did on the old version, and share that list with our developer relations team every week.

One practical point. Beta users need a way back. If someone joins the beta and their banking app stops working, they need to be able to roll back to the stable version without losing data. Otherwise, we'll have angry customers and service center visits.

Rolling back without data loss is harder than it sounds, because the new version migrates databases to new formats. The safe approach is to back up the user data before the upgrade and restore it on rollback. It's doable, but it needs to be designed now, not in December.

Then let's make the rollback path a formal requirement for the beta. Elena, can you include it in the merge plan as its own work item, with an owner and a date?

Yes. I'll scope it this week and give you a realistic estimate by the fourteenth.

Now Orion Lite. The business wants it about a month after Orion. Is that realistic?

Most of the framework work is shared, so Orion Lite mainly needs its own device-specific integration and testing. Six weeks after Orion is realistic. Four weeks would mean overlapping testing with the Orion beta, and SQE would be stretched very thin.

I agree with Elena. Six weeks lets us reuse the same test devices and the same people. So Orion Lite stable around March 15th.

Let's list the top risks so I can put them in the plan. I have: Atlas pulling framework engineers, Qorvix vendor drops slipping, the carrier holiday freeze, and Google's final release moving. Anything else?

One more: data migration. Every OS upgrade changes some internal database formats. If the migration fails on even a small percentage of devices, users lose data, and that's the kind of thing that ends up in the news. I want the upgrade-specific test to start as early as engineering dogfood, not after the beta.

Agreed, and please include devices that are almost full. Storage-related migration failures almost always show up on devices with less than five percent free space.

Okay, let me summarize the plan. Development starts August 17th with a reduced framework team. Engineering dogfood November 2nd. Company dogfood November 30th. Second merge complete December 18th. Pre-final carrier submissions before December 15th. Public beta January 4th. Orion stable in open markets February 1st, carrier markets through February. Orion Lite stable around March 15th. Kernel stays on 6.1. Does anyone object?

No objection, with the staffing rule we discussed.

Noted. Action items: Elena, share the detailed merge plan and the list of risky areas by August 14th. Chris, get written confirmation of the Qorvix vendor drop dates and the interface requirement by August 12th. Minji, design the upgrade-specific test, including near-full devices, by the end of August. Ryan, start negotiating pre-final submissions with the US and Korean carriers. Brian, confirm the names of the engineers assigned to the upgrade. And I'll take the staffing rule and the February date to the program directors on Monday.

I'll start with the two US carriers that have the holiday freeze, since they're the biggest risk to the date. If either of them refuses a pre-final submission, I'll let you know immediately, so we can decide whether to move the beta or accept a later date for those markets.

Thank you, everyone. I think this is a plan I can defend, and that's what I needed. We'll meet every other Saturday at 2 p.m. Korea time while the program is ramping up. The next meeting is August 22nd, same room. By then, I'd like the merge plan, the vendor dates, and a first read from the carriers.

Sounds good. I'll start pulling the latest preview into a branch on Monday, so we're ready to go on the seventeenth.

Thanks, Joanne. It's a relief to start an upgrade program with realistic dates for once.