Skip to main content

Fixing 'Broken Functionality' Rejections in Google Play Review

 Few notifications trigger as much anxiety in an Android development team as the vague, generic rejection email from the Google Play Console: "Issue: Broken Functionality."

You have likely passed your internal QA. Your unit tests are green. You may have even run Firebase Test Lab. Yet, the reviewer claims your app crashed, showed a dead screen, or failed to log in.

The rejection typically cites "Policy: Minimum Functionality", which states that apps must provide a stable, engaging, and responsive user experience. When Google rejects an app under this banner, it is rarely a logic error in your business core. Instead, it is almost always a failure to handle the specific, often antiquated, edge cases of the Google Play Review environment.

This guide provides a root cause analysis of why these rejections happen and details the code-level architectural changes required to pass the review permanently.

The Reviewer Environment: Why "It Works on My Machine" Fails

To fix the rejection, you must understand who—or what—is testing your app.

Google Play reviews are a hybrid of automated scripts (Pre-launch reports) and human review. The human reviewers do not test on the latest Samsung Galaxy S24. They frequently use emulators or older hardware reference devices, notoriously the Pixel C tablet or the Nexus 9.

These devices introduce specific constraints:

  1. Unusual Aspect Ratios: Tablets force UI rendering into states often ignored by phone-centric development.
  2. Aggressive Orientation Changes: Reviewers test for crashes by rotating the device while network requests are in flight.
  3. IPv6 / Geolocation: Reviewers connect from IP addresses (often in India, Ireland, or California) that may be flagged by strict backend firewalls or strict IPv4-only configurations.

If your app crashes during a rotation, displays a generic "Error" toast without retry logic, or has a button that does nothing, you will be rejected for Broken Functionality.

Problem 1: The "Coming Soon" Trap (Dead Links)

The most common reason for rejection is "dead clicks." This occurs when a user clicks a UI element (like a "Settings" gear or a "Premium" tab) and nothing happens, or a Toast appears saying "Coming Soon."

Google interprets "Coming Soon" as "Unfinished App." Under the Broken Functionality policy, an app cannot be in a beta state within the Production track.

The Fix: Build-Time Feature Flagging

Do not hide unfinished features with UI logic (e.g., view.visibility = GONE). Hacky UI suppression often fails, leading to empty whitespace or layout shifts that reviewers interpret as bugs.

The architectural solution is Build-Time Feature Flagging. We use Gradle to completely strip the code path for unfinished features from the release artifact.

Step 1: Define Flags in Gradle (Kotlin DSL)

In your module-level build.gradle.kts:

android {
    buildTypes {
        val release by getting {
            // Disable unfinished features in Production
            buildConfigField("Boolean", "ENABLE_EXPERIMENTAL_DASHBOARD", "false")
            isMinifyEnabled = true
            proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro")
        }
        
        val debug by getting {
            // Enable for internal testing
            buildConfigField("Boolean", "ENABLE_EXPERIMENTAL_DASHBOARD", "true")
        }
    }
    
    buildFeatures {
        buildConfig = true
    }
}

Step 2: Conditional Composition (Jetpack Compose)

In your UI code, the compiler will now see a constant boolean. If you use R8/ProGuard, the false branch will be dead-code stripped entirely, meaning the unfinished code doesn't even exist in the APK sent to Google.

@Composable
fun MainNavigationMenu(
    onDashboardClick: () -> Unit,
    onSettingsClick: () -> Unit
) {
    Column(modifier = Modifier.padding(16.dp)) {
        MenuButton(
            text = "Home",
            onClick = { /* Navigate Home */ }
        )

        // This block is stripped from Release builds by R8
        if (BuildConfig.ENABLE_EXPERIMENTAL_DASHBOARD) {
            MenuButton(
                text = "Beta Dashboard",
                onClick = onDashboardClick,
                colors = ButtonDefaults.buttonColors(containerColor = Color.Red)
            )
        }

        MenuButton(
            text = "Settings",
            onClick = onSettingsClick
        )
    }
}

By removing the entry point physically, you eliminate the possibility of a reviewer clicking a dead link.

Problem 2: The "Pixel C" Crash (Process Death)

Reviewers test robustness by launching your app, initiating a network load (like logging in), and immediately rotating the device or putting the app in the background to simulate low-memory process death.

If your app crashes or loses state (e.g., the loading spinner disappears but the data never shows), it is flagged as broken. This is usually caused by failing to handle SavedStateHandle or improper coroutine scoping.

The Fix: ViewModel State Persistence

You must ensure that UI state survives configuration changes (rotation) and process death.

Here is a robust pattern using SavedStateHandle and Kotlin Flow. This ensures that if a reviewer rotates the device while data is loading, the request continues, and the state is preserved.

@HiltViewModel
class LoginViewModel @Inject constructor(
    private val loginRepository: LoginRepository,
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {

    // Key to persist state across process death
    private val KEY_IS_LOADING = "is_loading"
    private val KEY_USER_EMAIL = "user_email"

    // StateFlow derived from SavedStateHandle implies immediate restoration
    val emailInput = savedStateHandle.getStateFlow(KEY_USER_EMAIL, "")
    
    private val _uiState = MutableStateFlow<LoginUiState>(LoginUiState.Idle)
    val uiState: StateFlow<LoginUiState> = _uiState.asStateFlow()

    fun onEmailChange(newEmail: String) {
        savedStateHandle[KEY_USER_EMAIL] = newEmail
    }

    fun attemptLogin(password: String) {
        // Prevent double clicks
        if (_uiState.value is LoginUiState.Loading) return

        viewModelScope.launch {
            _uiState.value = LoginUiState.Loading
            
            // Simulation of network delay
            val result = loginRepository.login(emailInput.value, password)
            
            _uiState.value = when (result) {
                is NetworkResult.Success -> LoginUiState.Success(result.data)
                is NetworkResult.Error -> LoginUiState.Error(result.message)
            }
        }
    }
}

sealed interface LoginUiState {
    data object Idle : LoginUiState
    data object Loading : LoginUiState
    data class Success(val token: String) : LoginUiState
    data class Error(val message: String) : LoginUiState
}

Why this passes review: Even if the reviewer rotates the tablet (destroying the Activity), the ViewModel survives. If the OS kills the process to free memory (simulated by "Don't Keep Activities" in developer options), SavedStateHandle restores the email the reviewer typed.

Problem 3: The Infinite Spinner (Network & Geo-Blocking)

If a reviewer sees an infinite loading spinner, they mark the functionality as broken. Reviewers frequently connect via VPNs or from regions that might trigger your backend's security rules (WAF).

If your API returns a 403 Forbidden or a 500 Internal Server Error and your app ignores it, the UI hangs.

The Fix: Robust Error Interceptors

You must catch connectivity issues globally and inform the user. Do not leave the user guessing.

Implement a Retrofit/OkHttp Interceptor that normalizes network errors into human-readable failures.

class ErrorHandlingInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain.request()
        try {
            val response = chain.proceed(request)
            
            if (!response.isSuccessful) {
                // Handle 503 Service Unavailable or 403 Forbidden specifically
                // This prevents the "Silent Fail" that reviewers hate
                if (response.code == 503) {
                    throw MaintenanceModeException("Server is under maintenance. Please try again later.")
                }
            }
            return response
            
        } catch (e: Exception) {
            val msg = when (e) {
                is SocketTimeoutException -> "Connection timed out. Please check your internet."
                is UnknownHostException -> "Unable to reach server. You may be offline."
                is MaintenanceModeException -> e.message ?: "Service Unavailable"
                else -> "An unexpected error occurred."
            }
            // Re-throw as a custom IO exception to be caught by the Repository layer
            throw IOException(msg, e)
        }
    }
}

By converting cryptic network failures into UI-friendly exceptions, you can display a Snackbar or Dialog with a "Retry" button. This proves to the reviewer that the app functions correctly, even if the network environment is hostile.

Pre-Submission Checklist

Before re-submitting to the Play Console, run through this specific "Reviewer Simulation":

  1. The Dead Click Test: Tap every single actionable element in your release build. If it doesn't navigate or perform an action, remove it via the Gradle flag.
  2. The Airplane Mode Test: Turn on Airplane mode and open the app. Does it crash? Or does it show a "No Connection" screen? It must be the latter.
  3. The Rotation Test: Open your heaviest screen (likely a dashboard or list). Rotate the phone rapidly 3 times. If it crashes, fix your SavedStateHandle.
  4. The Tablet Test: If you don't have a tablet, create an Android Emulator with the "Pixel C" skin. Ensure your UI doesn't clip off the screen or look broken in landscape mode.

Conclusion

"Broken Functionality" rejections are rarely about your code's logic; they are about your app's resilience. Google wants to ensure that when things go wrong—network failures, weird device rotations, or unfinished features—the app handles them gracefully rather than crashing or stalling.

By stripping incomplete code at the build level and implementing robust state preservation, you not only pass the review but also ship a significantly more stable product to your users.

Labels: