HelixOTA У развојулиценца: Apache-2.0

Helix OTA је универзални, дубоко независни систем за овер-тхе-аир ажурирања: Go контролна раван уз клијентске агенте по оперативном систему, намењен безбедном, фазном испоручивању ажурирања фирмвера/апликација на флоте уређаја — од једне плоче до милиона уређаја. Први циљ је Android 15 на Оранге Пи 5 Max.

OTA се обично реинвентира за сваки уређај и сваки оперативни систем, а лоша ажурирања могу да онеспособе читаву флоту. Helix OTA је створен као један универзални систем за ажурирања с приоритетом безбедности, који сваки оперативни систем може да усвоји путем адаптера, с уграђеним гаранцијама враћања на претходну верзију и валидације – а не као накнадно додате функције.

Он одбија да третира „никада не онеспособи уређај" и „постепено и уочљиво ажурирање" као најбоље напоре које се надате да ће издржати под оптерећењем – то су архитектонске инваријанте уграђене у пут покретања и контролну раван. А тиме што су мотор за ажурирање и слој оперативног система заменљиви шавови, а не чврсто уграђене претпоставке, иста контролна раван данас покреће Android, а спремна је да покреће и друге оперативне системе у будућности – само додавањем адаптера, без гранања, преписивања или поновног измишљања сигурносних гаранција којима већ верујете.

• Два издвојива шава – шав адаптера за оперативни систем и шав мотора за ажурирање независног од оперативног система – који претварају „универзалност" из маркетиншке пароле у структурно својство кодне базе.
• Сигурност у дубини: уређајска А/Б ажурирања на нивоу оперативног система (update_engine) + АВБ/дм-verity + аутоматско враћање на претходну верзију у случају грешке при покретању, слојевито *поврх* серверске валидације артефаката – ажурирање мора да прође кроз више независних провера пре него што се трајно примени.
• Децомпозиција заснована на каталогу, одвојено: подела на шест поново употребљивих, независно верзионисаних ota-* потмодула које можете користити по избору, уместо да гутате монолит.
• Примарни транспорт HTTP/3 (QUIC) са аутоматским повратком на ХТТП/2 и преговараном Brotli/гзип компресијом – модеран, нисколатентни пренос који се прилагођава уместо да откаже.
• Инжењеринг без блефирања: дизајн и статус су експлицитно означени као фаза спецификације, а ништа што није изграђено никада се не представља као испоручено – поштење је уграђено као основна инжењерска вредност, а не као одрицање у фуснотама.

• Гарантовање да лоше ажурирање никада не онеспособи уређај – најтеже обећање у OTA. Решено обавезном уређајском А/Б ажурирањем на нивоу оперативног система: update_engine уписује у неактивни слот док активни слот и даље ради, АВБ/дм-verity криптографски проверава ланац покретања, а ако нови слот не успе да се покрене, уређај се аутоматски враћа на претходну верзију – све то подржано обавезном предимплементационом валидацијом артефаката, тако да се оштећени садржај ухвати пре него што икада напусти сервер.
• Један систем, више оперативних система – решено одбијањем да се претпоставке специфичне за Android уграде у језгро. Заменљиви шав адаптера за оперативни систем изолује специфичности платформе, а шав мотора за ажурирање независног од оперативног система чува логику кампање преносивом, при чему је сваки задржан као посебан потмодул, тако да је додавање новог оперативног система проширење, а не хируршка интервенција на целом систему.
• Постепена, заустављива ажурирања – решено посвећеним мотором за ажурирање који размишља у процентуалним кохортама са праговима успеха/грешке и експлицитном контролом заустављања/настављања, намерно ослобођеним од спрега са ХТТП-ом, тако да исти мотор може да покреће кампање независно од транспортног слоја.

• Go + Gin — изабрани због модела конкурентности и минималног отиска при имплементацији; покрећу контролну раван, мотор за испоруку ажурирања и валидатор артефаката, нудећи примарни интерфејс REST /api/v1.
• Kotlin/KMP — изабрани како би Android агент OTA на уређају могао да дели логику на различитим циљним платформама; управља целим циклусом уређаја: провера / преузимање / верификација / примена / извештавање.
• HTTP/3 (QUIC) → ХТТП/2 — QUIC изабран као примарни транспортни протокол за испоруку са ниском латенцијом и отпорношћу на нестабилне мобилне везе, уз аутоматско враћање на ХТТП/2 како ниједан уређај не би остао изолован; Brotli/гзип се преговарају по захтеву ради смањења величине пакета.
• PostgreSQL — изабран због релационог интегритета у регистру уређаја, кампањама и телеметрији, где је исправност стања флоте важнија од брзине уписа.
• MinIO / S3 — изабрани као складиште артефаката како би велике слике фирмвера биле смештене у стандардно складиште објеката, одвојено од релационог слоја.
• AOSP update_engine + АВБ/дм-verity + boot_control — изабрани јер је поновна употреба Андроидовог већ испробаног механизма Виртуал А/Б и верификације покретања сигурнија од креирања сопственог решења за ажурирање; користе се за управљање променом слотова и криптографском верификацијом покретања на уређају.
• React — изабран за управљачки панел где оператори пријављују, отпремају артефакте, покрећу испоруке и прате стање флоте на једном месту.
• OpenTelemetry + Prometheus/Grafana — изабрани за неутралну инструментацију произвођача; користе се како би свака фаза испоруке била видљива у метрикама и панелима, уместо да се нагађа.

• Статус: у развоју. У складу са правилима пројекта против преувеличавања, још не постоји функционални продукциони сервер нити агент — ово је фаза спецификације/истраживања и изградње тестног покрића. Репозиторијум садржи ауторитативни корпус дизајна, пипелине за извоз документације и скелу за подмодуле.
• Шест јавних, поново употребљивих подмодула (ota-protocol, ota-artifact-validator, ota-rollout-engine, ota-update-engine-bridge, ota-android-agent, ota-telemetry-schema) налази се на github.com/HelixDevelopment/.
• Покривеност тестовима и подаци о латенцији у репозиторијуму представљају пројектну евиденцију у току, а нису независно потврђени. Бројеви клаузула HelixConstitution наведени у РЕАДМЕ фајлу СУ НЕВЕРИФИКОВАНИ.
• Лиценца: Апацхе-2.0.

Приоритетни ниво: Helix-primary.