Is Gemini 3.8 a huge regression? How could a regression that magnitude be released?

Google Antigravity IDE + gemini 3.8 , I am getting reasoning failures that are Gemini 2.5 level bad.

Here for instance on trivial reasoning question Gemini 3.8 is hallucinating over basic stuff like whether an Android Fragment can go back gtom RESUMED to STARTED with or without an onPause() callback being called.

This is a completely basic Android lifecycle question without which NO POSSIBLE software can be written by Gemini.

How is that possible for 3.8 to be confused to that level on basic Google Software (Android) questions?

Pierre

------> first answer

The Exact Failure Scenario: Transient Dialog / Window Overlays (No onResume() Triggered)

In Android, Fragment.onResume() is not called when dismissing a dialog or system overlay if the hosting Activity was never paused.

The Mechanism:

  1. When a system overlay, permission prompt, or biometric prompt appears on top of the Activity:
    • The hosting TmonMainActivity can remain in the foreground (or in multi-window / picture-in-picture).
    • However, the Fragment’s lifecycle state can drop to Lifecycle.State.STARTED (or view lifecycle drops).
  2. When the dialog or prompt is dismissed:
    • Because the parent Activity was already in the foreground, the Android framework does not fire onResume() on the Fragment again.
  3. The Fragment simply regains window focus and returns to the RESUMED state internally without triggering the lifecycle callback.

------> second answer

can an android fragment leave the ONResumed state without onPause being called?

5:12 PM

No. An Android Fragment cannot leave Lifecycle.State.RESUMED without onPause() being called.

Why:

In Android’s architecture (LifecycleRegistry and FragmentManager):

  • Lifecycle states (INITIALIZED, CREATED, STARTED, RESUMED, DESTROYED) are strictly driven by paired lifecycle events.
  • The only event that transitions a lifecycle out of RESUMED down to STARTED is Lifecycle.Event.ON_PAUSE.
  • FragmentManager always invokes fragment.performPause(), which directly executes fragment.onPause(), before lifecycle.currentState drops below RESUMED.

I can also confirm that gemini 3.7 doesnt have this problem. It answer perfectly to these Android fragment lifecycle questions.

Comparing Gemini 3.7 and 3.8, both in medieum thinking mode on Antigravity IDE, on basic Android kotlin fragment question the difference is staggering. 3.8 is stageeringly wrong and bad.