For years, mobile game rendering was relatively easy to describe: target 30 or 60 FPS and try to deliver every frame on time. Modern Android displays make that strategy more complicated-and more interesting.
Understanding How Variable Refresh Rate affects frame delivery means thinking about refresh timing, presentation cadence, power usage, and frame pacing together.
Phones may support 60 Hz, 90 Hz, 120 Hz, or adaptive behavior that changes during use. A good rendering loop therefore cannot assume the display will always refresh at one predictable interval.
Refresh Rate and Frame Rate Are Different Things
Frame rate describes how quickly the game creates frames. Refresh rate describes how often the display can update what the player sees.
Ideally, these two systems work together.
Problems appear when a game produces frames at a cadence that does not align cleanly with the display.
For example, rendering 60 FPS on a 90 Hz display can create uneven presentation because the display cannot simply show every game frame for the same number of refresh cycles.
Android specifically recommends matching display refresh rate to the game’s target frame rate as closely as possible on high-refresh devices. The Frame Rate API and Android Frame Pacing library provide ways to communicate those intentions to the system.
That means the frame-delivery problem is no longer simply “render faster.” It is also “present consistently.”
Android Adaptive Refresh Rate Changes the Timing Model
Android 15 introduced Adaptive Refresh Rate, or ARR, on supported hardware.
Unlike traditional displays that operate at a fixed cadence for an active display mode, ARR hardware can adjust refresh behavior using discrete VSync steps.
Android describes this as decoupling display VSync timing from the actual refresh cadence, helping displays match content updates without traditional mode switching.
That can reduce power consumption because the display does not need to run at its maximum refresh rate when content changes slowly.
It can also reduce jank caused by switching between separate display modes.
Developers should still be careful with terminology. Android’s ARR is not simply an unrestricted continuously variable refresh system. Its implementation works around discrete timing intervals supported by the panel and platform.
For game engines, however, the practical result is similar: display timing is becoming more dynamic.
Frame Pacing Matters More Than Peak FPS
A game fluctuating between 70 and 100 FPS may sound impressive on a performance overlay.
It can still feel worse than a properly paced 60 FPS game.
Android Frame Pacing, also known as Swappy, exists to synchronize game logic and rendering with Android’s display subsystem. It uses presentation timestamps and synchronization mechanisms to prevent frames from arriving at awkward intervals.
This matters because the Android display system may repeat previous frames when new frames arrive too late.
The result of poor pacing is not always obvious tearing. Players may simply perceive inconsistent motion, strange camera movement, or slightly unpleasant responsivness.
A useful design target is therefore stable delivery first, maximum FPS second.
If your game cannot reliably maintain 120 FPS, running at a carefully paced 60 FPS may create a better experience.
Choose Frame Rates That Fit Display Cadence
Some frame-rate targets align more naturally with certain refresh rates.
Android’s FPS throttling guidance provides useful examples. A 60 Hz display works naturally with 60 or 30 FPS. A 90 Hz display can pair effectively with 90, 45, or 30 FPS, while a 120 Hz panel allows targets such as 120, 60, 40, or 30 FPS.
These values divide cleanly into the display cadence.
Imagine a demanding RPG that cannot sustain 60 FPS on a particular 90 Hz device. Instead of dropping directly to 30 FPS, a well-designed pacing system could potentially target 45 FPS.
That gives the GPU considerably more time per frame while retaining smoother motion than 30 FPS.
Android’s Frame Pacing library explicitly handles multiple supported refresh rates and can provide this kind of flexibility.
Choosing a slightly unusual target such as 40 or 45 FPS can therefore make perfect sense on modern Android hardware.
Use setFrameRate as a Hint, Not a Command
Android provides Surface.setFrameRate() and related APIs so applications can communicate their intended frame rate to the platform.
For game content, Android recommends using FRAME_RATE_COMPATIBILITY_DEFAULT. The operating system then considers that preference when choosing an appropriate display refresh rate.
The important detail is that the request is not guaranteed.
Battery Saver may restrict refresh rate. Another surface can influence display scheduling. Device temperature can also prevent the platform from granting the requested high-refresh configuration.
Your rendering system must therefore remain correct even when the display does something different from what you requested.
If you request 120 FPS but receive a 60 Hz environment, gameplay simulation should not break.
Likewise, avoid calling setFrameRate() every frame. Android warns that frequent calls can trigger display changes and potentially cause dropped frames during transitions.
Update frame-rate preferences when the actual strategy changes, not continuously.
Presentation Timestamps Become Critical
Imagine your game renders at 60 FPS while the display operates at 120 Hz.
That is perfectly workable because each game frame can effectively remain visible across two display opportunities. But frames still need to be presented at predictable moments.
Android recommends presentation timestamps when the game cannot or does not run at the display’s actual refresh rate.
Available mechanisms include EGL_ANDROID_presentation_time, VK_GOOGLE_display_timing, and other platform APIs.
This prevents frames from appearing earlier than intended and creating unnecessary judder.
Native Vulkan developers can gain particularly precise control through presentation-timing extensions.
For many teams, manually handling every timing detail is unnecessary. Swappy already manages much of this complexity for OpenGL and Vulkan games.
Unity and Unreal also include Android frame-pacing integration, reducing the need for custom low-level implementations.
Android 15 Makes High Refresh an Explicit Choice
One major platform change affects game teams targeting newer Android versions.
Android’s current game optimization guidance states that Android 15 defaults games to 60 Hz for power efficiency. Games wanting higher rates such as 120 FPS need to explicitly request them through the Frame Rate API or Swappy.
That makes high-refresh support a product decision rather than something developers should assume automatically.
A competitive shooter may benefit greatly from 120 FPS because smoother motion and lower display intervals improve the feel of aiming.
A turn-based strategy title may gain very little while significantly increasing GPU work, battery consumption, and heat.
Request high refresh where it improves the experience, not simply because the panel advertises 120 Hz.
Test Timing, Not Just the FPS Counter
A performance overlay showing “60 FPS” does not prove good frame delivery.
Teams should examine frame-time variance, presentation cadence, missed deadlines, thermal behavior, and slow frames.
Android’s Slow Sessions metric treats sessions as problematic when a significant percentage of their frames exceed defined timing thresholds. Android also identifies refresh-rate mismatch, thermal throttling, and CPU/GPU bottlenecks as potential causes of slow frames.
Real-world results show why this matters. The developers of Mir 2: Return of the King used Android Frame Pacing and reportedly reduced their Slow Session rate from about 40% to 10%.
A smooth game needs consistant frame intervals, not merely an attractive FPS maximum.
Variable and adaptive refresh behavior changes Android rendering from a fixed-cadence problem into a timing problem. Frame-rate targets, refresh matching, presentation timestamps, and pacing now need to work together.
Audit your current rendering loop on 60, 90, and 120 Hz hardware. If frame delivery becomes uneven when display conditions change, integrate proper pacing before chasing even higher peak FPS.