GAMMS GROUP / SecretOS
InicioHoyTransiciónCompatibilidadSNOSPRoadmap

THE SECRET OPERATING SYSTEM

SecretOS

Una plataforma que empieza sobre Android/AOSP, pero cuya visión a largo plazo es convertirse en un sistema nativo de GAMMS sobre GMA-64. La transición no está pensada como un corte brusco: SecretOS evolucionaría por capas, preservando aplicaciones, usuarios, servicios y compatibilidad durante el cambio.

Ver la transiciónExplorar compatibilidad
SecretOS
by GAMMS GROUP

SECRETOS TODAY

Una identidad propia sobre una base compatible.

La etapa inicial de SecretOS se construye alrededor de Android/AOSP y hardware ARM para aprovechar un ecosistema maduro mientras GAMMS desarrolla Junix UI, PGS, Secret Services, Secret Account, Setup Wizard, Secret Suite y herramientas corporativas propias.

En desarrollo

Android / AOSP

SecretOS 1.x parte de una base Android moderna, con Android 15 como referencia de trabajo inicial y compatibilidad APK como una de las piezas fundamentales de esta primera era.

En desarrollo

Junix UI + PGS

La experiencia visual y gráfica se separa conceptualmente de la base Android para que pueda evolucionar y, en el futuro, migrar a la plataforma nativa.

Dirección actual

ARM first

Los dispositivos de la primera era seguirían usando ARM. El salto a GMA-64 sería gradual y conviviría durante años con equipos anteriores.

THE TRANSITION

No reemplazarlo todo de golpe. Migrar capa por capa.

La transición propuesta de SecretOS hacia SecretOS Native está concebida como una evolución de varias generaciones. Primero se desacoplan las capas propias de GAMMS de Android; después se introducen runtimes y herramientas nativas; finalmente SNOSP y GMA-64 pasan a convertirse en la base principal.

SecretOS sobre AOSP

Android/ARM sigue siendo la base. APK es el formato principal de aplicaciones externas. Junix UI, PGS, Secret Services y Secret Suite ganan independencia.

Actual
Desacoplamiento de servicios

Más componentes propios dejan de depender directamente de APIs específicas de Android. Secret Account, servicios de identidad, sincronización, notificaciones, multimedia y administración se abstraen detrás de APIs de GAMMS.

Planificado
Secret Runtime + SPK

Aparece el formato .spk y un runtime propio capaz de ejecutar software Secret sin depender de APK. Android continúa existiendo como capa de compatibilidad.

Planificado
Dual platform

SecretOS puede existir en dos ramas hermanas: la rama legacy basada en AOSP/ARM y la rama Native basada en SNOSP/GMA-64. Ambas comparten servicios, interfaz, formatos y experiencia.

Concepto
SecretOS Native como plataforma principal

SNOSP sustituye a AOSP como base nativa en hardware GMA-64, mientras la compatibilidad mantiene el acceso a software de otros ecosistemas cuando sea técnica y legalmente viable.

Futuro

SNOSP

SecretOS Native Open Source Project.

SNOSP no sería simplemente “AOSP portado a GMA-64”. La visión es crear una base nativa propia para SecretOS: kernel, servicios del sistema, HALs, seguridad, proceso de arranque, framework, herramientas de compilación y APIs diseñadas para el ecosistema GAMMS.

Capa 7Secret Apps · .spk · software compatible
Capa 6Junix UI · PGS · Secret Framework
Capa 5Secret Services · Secret Account · Package Manager
Capa 4Compatibility Fabric · runtimes · containers
Capa 3SNOSP system framework · security · HAL
Capa 2Kernel / scheduler / memory / IPC / drivers
Capa 1GMA-64 · firmware · boot · hardware
La arquitectura exacta todavía no está congelada. Esta página presenta la dirección de diseño que GAMMS ha definido hasta ahora, separando claramente lo que existe de lo que está planificado.

SECRET COMPATIBILITY FABRIC

Una plataforma nativa no debería obligar al usuario a abandonar su software.

La propuesta es que SecretOS Native incorpore una capa de compatibilidad modular. En vez de hacer que cada formato sea “nativo”, el sistema podría detectar el paquete, seleccionar un runtime o contenedor apropiado, traducir APIs y aislar la aplicación dentro de una política de seguridad común.

.spk

Secret Package

Formato nativo de SecretOS Native. Tendría acceso directo a APIs Secret, GMA-64 y servicios propios.

.apk / .aab

Android Bridge

Compatibilidad Android mediante runtime, framework y traducción de APIs. Ideal para conservar el enorme catálogo Android durante la transición.

.exe / .msi

Windows Bridge

Capa conceptual para aplicaciones Win32/Win64, con traducción de llamadas, librerías y gráficos dentro de un entorno aislado.

.deb

Debian Bridge

Entorno Linux compatible con paquetes Debian/Ubuntu, usando contenedores, ABI Linux o traducción cuando sea necesario.

.rpm

RPM Bridge

Compatibilidad conceptual con Fedora/RHEL/openSUSE y otros ecosistemas RPM mediante un entorno Linux administrado por SecretOS.

.AppImage

Portable Linux

Ejecución de aplicaciones Linux autocontenidas en un sandbox compatible.

Flatpak

Sandbox Linux

Posible integración con runtimes y portales mediante una capa Linux de usuario.

Snap

Container Apps

Compatibilidad futura condicionada a servicios y componentes necesarios del ecosistema Snap.

.ipa

Apple App Bridge

Objetivo conceptual de compatibilidad con paquetes iOS/iPadOS. Sería el caso más complejo por dependencias de frameworks, firma, APIs propietarias y restricciones legales. No se presenta como una capacidad garantizada.

.app

macOS App Bridge

Posible capa de compatibilidad para aplicaciones macOS cuando existan APIs y binarios traducibles o recompilables.

.jar

Java Runtime

Runtime Java/JVM opcional para software multiplataforma basado en bytecode.

.wasm

WebAssembly

Runtime seguro y portable para aplicaciones, plugins y cargas de trabajo aisladas.

PWA / Web

Web Runtime

Aplicaciones web instalables con integración de sistema, notificaciones, archivos y ejecución aislada.

ELF

Linux Native ABI

Soporte conceptual para binarios ELF compatibles con el ABI ofrecido por SecretOS o ejecutados dentro de un entorno Linux.

CLI

Developer Tools

Shell, toolchains, SDKs y utilidades de desarrollo para crear y portar software directamente en SecretOS Native.

VM

Full Virtualization

Para software que no pueda traducirse de forma segura, la virtualización podría ejecutar sistemas invitados completos cuando el hardware lo permita.

HOW COMPATIBILITY WOULD WORK

Detectar. Adaptar. Aislar. Ejecutar.

En la arquitectura propuesta, el formato del archivo sería solo el primer paso. SecretOS analizaría arquitectura de CPU, ABI, dependencias, permisos, firma y APIs requeridas antes de decidir cómo ejecutarlo.

1. Package detection
.spk / .apk / .exe / .deb / .rpm / .ipa…
→
2. Compatibility profile
runtime · ABI · APIs · architecture
→
3. Translation / container
syscalls · graphics · filesystem · IPC
→
4. Secret Sandbox
permissions · identity · isolation
→
5. Junix integration
windows · notifications · files · input

COMPATIBILITY LAYERS

Más que traducir instrucciones.

Para que una aplicación externa se sienta integrada, SecretOS necesitaría varias capas coordinadas además de la traducción de CPU.

Concepto

CPU Translation

Traducción dinámica o recompilación para ejecutar software ARM, x86/x64 u otras arquitecturas sobre GMA-64 cuando sea viable.

Concepto

System Call Translation

Mapeo de syscalls y APIs del sistema invitado hacia servicios equivalentes de SNOSP.

Concepto

Graphics Bridge

Adaptación de OpenGL, Vulkan, Direct3D, Metal u otras APIs hacia PGS o las capas gráficas disponibles.

Concepto

Filesystem Bridge

Rutas virtuales, permisos, directorios de usuario y almacenamiento aislado para mantener las expectativas de cada plataforma.

Concepto

Input & Window Bridge

Teclado, ratón, touch, stylus, gamepad y ventanas transformados al modelo de interacción de Junix UI.

Concepto

Security Broker

Permisos, red, cámara, micrófono, ubicación y archivos gobernados por políticas SecretOS aunque la aplicación venga de otro ecosistema.

PACKAGE STRATEGY

.spk como formato nativo, no como cárcel.

El objetivo de .spk sería ser el formato de primera clase de SecretOS Native, pero la capa de compatibilidad permitiría convivir con otros formatos. Incluso podría existir una opción de empaquetado de compatibilidad: envolver una app externa dentro de un manifiesto Secret sin modificar el binario original.

Secret Language / C / C++
→
Compiler
→
GMA-64 binary
→
.spk
→
Secret Package Manager

MULTI-DEVICE

Un mismo sistema, varios targets.

SNOSP se piensa como una base capaz de generar imágenes diferentes según el dispositivo, manteniendo APIs y servicios comunes.

Aster Phone

sbuild build aster_phone-userdebug -j16

Aster Tablet

sbuild build aster_tablet-userdebug -j16

Junix Watch

sbuild build junix_watch-userdebug -j16

Junix Desktop

sbuild build junix_desktop-userdebug -j16

SNOSP Emulator

sbuild build snosp_emulator-userdebug -j16

Future devices

TV, automotive, embedded, enterprise terminals y otras categorías podrían usar perfiles derivados de la misma plataforma.

LONG-TERM ROADMAP

De Android a una plataforma completamente propia.

La transición está planteada como una continuidad, no como una ruptura. Las versiones y fechas finales todavía pueden cambiar conforme maduren GMA-64 y SNOSP.

AOSP / ARM era

Android como base, APK, Junix UI, Secret Services, Secret Suite, Setup Wizard y administración empresarial.

En desarrollo
Consolidación y desacoplamiento

Más APIs y servicios GAMMS dejan de estar ligados directamente a Android. Se prepara la portabilidad de la capa superior.

Dirección
Inicio de la era GMA-64

Comienza la transición oficial hacia hardware GMA-64 y SNOSP. La rama ARM/AOSP continúa para dispositivos anteriores durante un periodo de soporte prolongado.

Futuro
Dual ecosystem

Apps .spk nativas y aplicaciones heredadas conviven mediante Compatibility Fabric.

Futuro
SNOSP + GMA-64

La base nativa de GAMMS se convierte en el centro de la plataforma, con AOSP relegado a compatibilidad y soporte legacy.

Visión

CONTINUITY

Los dispositivos anteriores no desaparecen cuando nace GMA-64.

La estrategia definida para GAMMS contempla mantener capas de personalidad y soporte para SecretOS basado en ARM mientras la plataforma nativa madura. La idea es que una empresa o usuario no tenga que cambiar de dispositivo el mismo día que aparezca una nueva arquitectura.

Legacy ARM support

Actualizaciones y mantenimiento para hardware existente durante un ciclo prolongado definido por GAMMS.

Shared services

Secret Account, Secret Services, apps y sincronización buscarían funcionar entre ambas eras.

Developer migration

SDKs, toolchains, documentación y compatibilidad permitirían que desarrolladores migren a .spk y GMA-64 progresivamente.