​[Audit] OS 2.1 Nav Bar: AOSP Java Implementation & The Sideloading Paradox

Thanks for your message and audit!

As far as I know (and adding my grain of sand) this isn’t a simple AOSP UI tweak on Quest.

The system UI (nav bar, menus) is part of a closed compositor layer, not a standard Android View you can theme or apply alpha to. That’s why sideloading/APK tweaks don’t affect it as I think it’s rendered outside the app/UI layer.

So it’s not about complexity, it’s about platform control + UX consistency + safety (passthrough/contrast/readability).

That said, this is really valid feedback and the best way to submit it would be via Meta → Report a problem / feature request, since there’s no exposed API or setting for UI transparency.

Hello,

What you said was interesting. Are you saying the UI is injected directly into the final frame buffer by the system's "TimeWarp" or compositor engine to ensure it stays stable even if an app crashes? Wait a minute. Ok, bare with me, I think I see where this is going, this is going to be a long one. I've been coding for 20 years, so, I think I know a thing or two but maybe I'm wrong, but even if it is rendered in a separate compositor layer, that layer still has properties. Whether it’s a standard View or a specialized "Shell" layer, the Alpha and RGB values are still variables somewhere in the code.

Even if these are high-priority Surface Layers, the OVR Overlay API itself allows for alpha blending. If the API exists for developers to use, it exists for the system to utilize as well. Claiming it's "outside the UI layer" seems like a semantic shield for your "we hard-coded these values and don't want to expose the API" rebuttal. That Fixed Contrast actually harms accessibility. A "one size fits all" elevation shadow often fails in high-brightness Passthrough environments. By not allowing users to adjust these variables, you (Meta/OculusQuest) are actually creating the very "safety" and "readability" issues you claim to be preventing. And pointing out that sideloading doesn't affect it actually strengthens my argument. If the community can't fix it via sideloaded tools because it's locked in a "closed compositor," then it is entirely on Meta to provide the toggle. You're proving that the "Tenant" vs. "Owner" dynamic is real. The users are physically locked out of the very hardware they bought.

As i repeat, I have litterally been doing coding for 20+ years. Whether it’s a standard View or a Compositor Layer, the layer's properties (Alpha/Hex) are still defined by variables. The 'Platform Control' argument is a choice, not a technical impossibility. As I repeat from my previous statement; If we can achieve low-level engine ports in a browser, telling a developer that a transparency slider on a system overlay is 'too deep' in the architecture is a tough pill to swallow. Fixed UI elements in Passthrough are inherently exclusionary. If a user's specific environment washes out the Nav Bar, they need those variables to make the OS usable.

Even if the UI is rendered via a compositor, the values feeding that compositor are ultimately controlled by an API or a system service. Meta OS is an AOSP derivative, the System UI should handle these views. If the Navigation Bar is a View within the system, a simple SeekBar (slider) can be linked to the alpha value of the layout.

For example:

Java/Kotlin

// Example of linking a SeekBar to UI Alpha in an AOSP-based environment

SeekBar opacitySlider = findViewById(R.id.opacity_slider);

View navBarContainer = findViewById(R.id.nav_bar_container);

opacitySlider.setOnSeekBarChangeListener(new SeekBar.OnSeekBarChangeListener() {

    @Override

    public void onProgressChanged(SeekBar seekBar, int progress, boolean fromUser) {

        // Convert slider (0-100) to alpha float (0.0 - 1.0)

        float alphaValue = progress / 100f;

        navBarContainer.setAlpha(alphaValue);

        // If it's a compositor layer, the system would call a native method here:

        // InternalCompositor.setLayerOpacity(NAV_BAR_LAYER_ID, alphaValue);

    }

});

The "Platform Control" is just a variable away from "User Control." If the "three dots" or menus are rendered via a specialized WebView, a CSS variable makes the most sense for the "Anchor".

For example:

CSS/React Native/AOSP XML

/* Using a CSS Variable for global opacity control */

:root {

  --nav-bar-opacity: 0.85; /* The variable the slider would change */

}

#system-nav-anchor {

  background-color: rgba(30, 30, 30, var(--nav-bar-opacity));

  backdrop-filter: blur(10px); /* Essential for Figure-Ground stability */

  transition: background-color 0.2s ease;

}

The architectural complexity is not an excuse for omitting a fundamental variable. I propose that the "three dots" menu (with the anchor), as well as the search bars, stays at 100% opacity for accessibility/visibility, while the surrounding window/nav-bar uses the slider-defined alpha as well as the General Options Menus. This should solve "safety/contrast" concern. Even if the layer is "closed," there must be a Setter function in the OS that tells the compositor what to draw. If the developer can set it to 1.0, they can set it to a variable x.

The reality is that whether you call it CSS, Java, or "Compositor Layer Properties," the underlying logic is exactly the same: It is a display layer with an alpha (opacity) variable. Meta’s "Navigator" and many system menus are essentially WebViews or use a React-like framework. You use these for 2D overlays. If they are using a web layer, the fix is literally one line of CSS. If this is a Web-based overlay (which much of the Horizon UI is), you are telling me you can't implement a global variable? It’s basic styling.

Like I said in one of my posts; this is just for dev stuff here. Why do you have two folders for two different color versions of the same UI? That's madness and definitely backwards to me. I mean this is stuff I learned 15 years ago. Why are we still relying on static XML resource buckets that require a SystemUI restart, rather than dynamic Runtime Resource Overlays (RROs) which have been standard in Android for years? If you're using Native AOSP, then it’s even simpler. For the Android framework, every View has an alpha property. If you’re claiming this is a native Java View, then the code to link a slider to the UI is standard Android 101. Are you saying your engineers can't handle a simple setter? That's interesting.

Because here's the code for example:

// Connecting the UI Slider to the Nav Bar Alpha

public void onOpacitySliderChanged(int progress) {

float alpha = progress / 100f;

// 'mNavigationBarView' is a standard View in the AOSP SystemUI

mNavigationBarView.setAlpha(alpha);

}

Even if the Nav Bar is a texture submitted directly to the compositor (to bypass the app layer), that texture still has a Layer Alpha value in the compositor's stack. If you can render it at 1.0 (Opaque), you can render it at 0.7 (Transparent). By locking it, you are choosing Gatekeeping over Accessibility. Also, keep the "Three Dots" and the "Clock" at 100% Opacity (the anchors) while letting the user fade the actual bar.

I have already submitted the formal report as suggested. Interestingly, it appears a team is already moving in this direction—I am literally seeing the OS evolve in real-time. The Store interface has recently transitioned to a transparent UI, which is a significant and welcome first step. This proves that the 'closed compositor' isn't an architectural wall; it’s a design choice.

That transparency now needs to be applied globally—from the Main Menu to the App Library. To address your concerns about readability and safety, there is a logical compromise: keep the high-interaction zones solid. The Search Bar, input fields, and text-entry areas should remain at 100% opacity to ensure 110% legibility. By keeping these functional 'anchors' solid while allowing the rest of the UI layer to remain transparent, you solve the Figure-Ground failure without sacrificing the platform's UX consistency.

Now to harp in this one thing one last time (for now). This is very lazy of a $billion corporation to waste recourses, or is this a way for someone to get paid more by having multiple resource buckets for the same UI.?! Claiming "it's hard work", when the user could just slide the hex code from #FFFFFF (White) to #000000 (Black) or any color, instantly instead of restarting the system. innovation with a simple code, one folder, little recourses. Stop forcing a system reboot for a simple color shift. By moving away from hard-coded 'Light/Dark' folders and moving to a Float Variable for Opacity and a Hex Variable for Color, you eliminate the need for a restart entirely. Keeping the "Interactive" elements (Search, Keyboard, Confirm buttons) at 100% solid ensures that even if a user turns the rest of the UI down to 10% opacity, they can still navigate and type.

I said a lot already but its time to double down, because let’s be direct, it is that easy. As a developer, I know that whether we are discussing a Java-based AOSP View or a specialized compositor layer, the UI is ultimately rendered based on variables. If the Store can transition to a transparent state, the 'Platform Control' excuse for the rest of the OS is officially void. We aren't asking for a complete architectural overhaul; we are asking for the exposure of a single Alpha (Opacity) variable that already exists in the code. Map a UI slider to the background alpha of the Navigation Bar and System Menus. Keep the Search Bar and high-interaction nodes at 100% solid opacity. This ensures '100% legibility' and safety while giving the user the transparency they need for a professional-grade OS experience.

If a community can port Quake to HTML5, Meta's engineering team can certainly implement a basic transparency toggle. It’s time to stop gatekeeping the UI and start treating us like owners of the hardware. In 2010, developers ported Quake II to HTML5, proving that even complex 3D rendering engines can be opened up and manipulated with standard web variables, and not some specialized "closed" engine. It's now 2026. Telling a developer that a 2D Navigation Bar is too 'architecturally closed' for a transparency slider doesn't hold water. If we could run Quake in a browser 16 years ago, you can give us an Alpha slider today. Claiming that they can't put a transparency slider on a 2D menu is historically embarrassing. They used WebGL, which handles the "compositor" and rendering layers in a browser, the exact type of "complex" architecture you (Meta) are currently using as an excuse.

Degly, I have been writing this for about 2 days to fit in my current main concerns, rebuttal to your comment, and the updated comment towards the new implementation to the Store; I appreciate the context, but the technical reality is that it is that easy. I am seeing the OS evolve in real-time—the Store has already transitioned to a transparent UI, proving the 'closed compositor' isn't an architectural wall, but a design choice. Whether we’re talking about React Native style props, AOSP XML attributes, or Compositor variables, these are just simple Alpha (Opacity) and Hex (Color) variables that already exist in the code. There is no excuse for a static 'Light/Dark' binary that forces a system reboot in 2026, especially when developers could port Quake to HTML5 back in 2010.

Please relay this to the engineering team: implement a Double Slider for both Opacity and Color, while keeping high-interaction zones like the Search Bar and input fields at a 100% solid functional anchor to ensure 100% legibility. It’s time to stop gatekeeping basic UI variables and start treating us like owners of the hardware.