Free Common Mobile OS and Application Issues practice questions

When one app fails only on a specific Wi-Fi network but works over cellular, the problem follows the network path rather than the app itself. Hotel and public Wi-Fi commonly use a captive portal sign-in page, a DNS filter, or a VPN profile that can block a banking app's risk and authentication checks. Opening a browser to trigger the portal login, or disabling a VPN, usually restores access. The battery being too low is unlikely because the app works fine over cellular on the same device, so power is not the constraint. A corrupted app cache would cause the app to fail on all networks, not selectively over one Wi-Fi network. A pending OS update would also cause consistent failures across connections rather than a network-specific symptom. The key troubleshooting principle is scoping: if the failure follows the network, fix the network; if it follows the account, focus on sign-in; if it follows the device, stabilize the device first.

Clearing the app cache is the correct first step because cache is temporary data meant to be rebuilt, and clearing it can remove a corrupted image, index, or temporary database that causes slowness or glitches after an update. Importantly, clearing cache does not remove logins or stored content, so it is a low-risk, reversible action. Clearing the app data resets the app to a first-run state, which will likely sign the user out and can delete offline files and settings, so it is a higher-risk step saved for when cache clearing fails. Uninstalling and reinstalling the app also risks losing device-only local data and is more disruptive than clearing cache. A factory reset is the most drastic action, wipes the entire device, and would never be the first response to a single misbehaving app. The correct methodology is to start with reversible, low-risk actions and only escalate to data-erasing steps when the evidence points to deeper local corruption.

Date and time settings should be checked first because sign-in failures that appear right after travel are a classic symptom of an incorrect device clock. Many apps rely on TLS certificates and time-based tokens; if the clock is wrong, the phone may treat a valid certificate as expired or a login token as "not yet valid," producing errors that look like bad passwords or endless loading. Enabling "Set Automatically" for date and time (and automatic time zone) usually resolves this quickly. Available storage space is unrelated because the symptom is authentication failure across multiple apps, not installation or write failures. Account payment and billing status affects the ability to download or update apps, not the ability to sign in to already-installed apps. Background app refresh controls whether apps update content while idle, but it would not cause a sudden multi-app sign-in failure tied to travel. When sign-in fails right after a time change or trip, correcting the clock is one of the fastest causes to confirm and one of the easiest to overlook.

A store account, billing, or management policy issue is most likely because a clean rule applies: if only one app fails, suspect the app; if every install and update fails, suspect the account, store, or management policy. Common triggers include an expired password, an account lock, a payment hold, family restrictions, or MDM enforcement that blocks or hides apps. A corrupted cache in each individual app would not prevent new installs and updates system-wide, and would affect app behavior rather than store authorization. A failing WebView component causes crashes in apps that render web content, not store-wide install failures. A denied permission affects the functionality of a specific app, not the store's ability to authorize downloads. Because the device is connected and has storage, the hidden gatekeeper is almost always the store account or an enterprise policy, which often requires re-authentication or a server-side change by an administrator.

Bluetooth operates in the 2.4 GHz band, which it shares with 2.4 GHz Wi-Fi, smart home devices, and even USB 3.0 ports. This shared spectrum means interference can cause audio stutter and brief disconnects, especially in crowded environments like apartments or classrooms. NFC operates over a much shorter range using a different technology and is not affected by 2.4 GHz congestion in the same way. Cellular uses licensed carrier frequencies that are separate from the 2.4 GHz band. GPS is a satellite positioning system operating on entirely different frequencies and is unrelated to Wi-Fi band congestion. Understanding that Bluetooth and 2.4 GHz Wi-Fi coexist in the same crowded band explains why moving closer to a device, reducing the number of active radios, or switching Wi-Fi to the 5 GHz band can improve Bluetooth audio quality.

Checking the battery usage screen first is correct because rapid idle drain, especially overnight, points to background syncing, poor signal causing constant reconnection attempts, or a misbehaving app. The battery usage data lets you identify apps with unusually high background use and compare screen-on time to the overall drain. On a two-month-old device, normal chemical wear is not the explanation, so a failing battery from age is unlikely. Checking for physical swelling is a valid safety step, but swelling causes physical warning signs like a bowing case or lifted screen rather than gradual overnight drain, and a two-month-old battery rarely swells. The charging cable and adapter affect charging, not idle discharge, so they are unrelated to drain while the phone is not plugged in. Screen brightness and timeout are the largest power draw during active use, but they do not explain drain while the screen is off and idle. Verifiable data in Settings should always guide the diagnosis rather than guessing at hardware.

The device requiring unlocking and authentication is the most likely cause because NFC payments have strict security rules by design. Many NFC actions, particularly payments, require an unlocked device and a biometric or passcode prompt. If a user attempts to pay with a locked screen, the terminal may show a decline even though the NFC hardware is working perfectly. Clearing the wallet app cache would not address a security prompt that was never satisfied, and it is not the first step for a payment decline. A physically damaged NFC antenna would prevent the tap from being detected at all rather than producing a decline after contact. A captive portal affects Wi-Fi internet access and has nothing to do with NFC tap-to-pay, which does not rely on that connection during the transaction. Recognizing that NFC payment security depends on an unlocked, authenticated device is essential for troubleshooting tap-to-pay scenarios.

Disabling the VPN and any security filtering, then retrying, is the correct first action because a VPN or filtering app can interfere with the download and certificate verification stages of an OS update. Removing these variables is a low-risk, controlled step that often clears the blocker when the signal is otherwise strong. A factory reset is a drastic, data-erasing step that is never appropriate as a first response to a failed update and would not address a VPN-related interference issue. Manually deleting the system update folder from storage is explicitly discouraged because guessing at file locations can break future installs; the system update cache should only be cleared through supported settings when available. Declaring the device end-of-life and replacing it is premature because that conclusion is only valid after repeated over-the-air failures and confirmation that the hardware cannot support a newer OS version. The proper approach treats updates like surgery: stable power, a clean network, and enough room to work, with controlled changes made one at a time.

The headset supporting HFP but not A2DP best explains the behavior because Bluetooth devices support specific profiles that define what jobs they can perform. HFP (Hands-Free Profile) handles call audio and hands-free features, while A2DP (Advanced Audio Distribution Profile) handles stereo media audio. If calls work but music does not, the device is providing call audio through HFP while lacking or failing to negotiate the A2DP profile needed for media. A critically low battery would typically cause the headset to disconnect entirely or shut off, not selectively play calls but not music. NFC being disabled is irrelevant because NFC is used for tap pairing convenience, not for streaming audio once a device is already paired. An incorrectly entered pairing code would prevent pairing from completing at all, but the device is shown as successfully paired. Understanding that a device can pair and support one audio job but not another is key to separating pairing success from function.

Opening a browser to trigger the captive portal sign-in is the correct first action because a full signal with no internet access at a public location is a classic captive portal symptom. Public and guest Wi-Fi commonly block all traffic until the user accepts terms or signs in, and the sign-in page often appears only after you attempt to load a plain site in a browser. Resetting network settings is a last-resort, disruptive action that erases all saved networks, Bluetooth pairings, and VPN profiles, and it would not help with a portal that simply needs acknowledgment. Forgetting the network and re-entering the password addresses stale configurations or wrong credentials, but the device is already connected, indicating the password is correct. Enabling airplane mode and leaving it on would disable all radios and prevent any connectivity, which does not resolve the issue. Always treat Wi-Fi internet access as separate from Wi-Fi signal strength, and test for captive portals before attempting resets.