iOS follow-up: checklist of isAndroid() call sites to review for isMobile() migration

[liminalwarmth]

With iOS support merged (#11190), GuiBase.isAndroid() no longer implies "not desktop" — iOS currently takes the desktop path at every isAndroid() call site. As @Jetz72 noted in review, the existing uses need a pass to see which should apply to iOS too. #11382 adds a GuiBase.isMobile() helper (and converts the two sites that already spelled out isAndroid() || isIOS(): Config.resPath(), FSkin.useFallbackDir()).

This issue is a survey of the remaining isAndroid() call sites in shared code as a migration checklist. Caveat: isMobile() differs from isAndroid() exactly on iOS, so every conversion below is a live iOS behavior change — the current desktop-path behavior is what was device-verified in #11190, so each flip should ideally be checked on an iOS device/simulator before landing.

Candidates (semantics look like "any touch/mobile platform")

Touch input vs. mouse pointer:

• Forge.java:303 — hasKeyboard(): whether the platform has a physical keyboard (feeds hasExternalInput())
• Forge.java:376 — always-on gamepad listener vs. only-when-connected (battery/perf concession for touch devices)
• Forge.java:475 — skips setting a desktop mouse cursor image
• Forge.java:1516 — skips mouseMoved/hover-listener handling (has a "todo: mouse listener for android?" comment)
• toolbox/FDisplayObject.java:131,136 — precise card-hover detection and hover bookkeeping gated to desktop ("TODO: mouse detection on android?")
• screens/match/MatchScreen.java:404 — hover-based card magnifier gated to desktop-or-gamepad (!isAndroid() || hasGamepad())
• adventure/util/RewardActor.java:183,488,626,728,892,993 — repeated isAndroid() || hasGamepad() selecting hold-to-view tooltip (touch/gamepad) vs. hover tooltip (mouse)
• adventure/util/RewardActor.java:1388-1391 — hold-tooltip centered on screen (touch/gamepad) vs. anchored at hover position (mouse)
• adventure/util/KeyBinding.java:59 — hides keyboard-key glyph labels when no controller is connected (no physical keyboard to label)

Adventure map movement / HUD:

• adventure/stage/GameHUD.java:108,150,206,223,332 — touch HUD layout JSON, on-screen virtual touchpad, console/notification positioning, and touch-to-move routing (one coupled group)
• adventure/stage/GameHUD.java:1056 — long-press gesture to toggle the debug console
• adventure/stage/GameStage.java:521,533 — suppresses mouse-drag/click-to-move on touch platforms (which use the virtual touchpad instead)

Screen size / fixed fullscreen:

• adventure/scene/SettingsScene.java:128 — hides the video-mode/resolution dropdown (mobile is fixed fullscreen)
• adventure/scene/SettingsScene.java:190 — hides the "Full Screen" toggle
• adventure/scene/SettingsScene.java:321 — swaps a desktop texture-filtering checkbox for a "Landscape Mode" toggle
• screens/settings/SettingsPage.java:120 — shows the "Landscape Mode" toggle only on Android
• screens/settings/SettingsPage.java:594 — hides the mouse-hover "Enable Magnifier" setting
• adventure/util/RewardActor.java:676-677 — reward-card zoom sized to 95% of screen vs. 70% on desktop
• screens/TransitionScreen.java:179 — larger transition-text font scale on mobile
• screens/FScreen.java:90 — landscape layout handling triggers on Android+landscape-pref in addition to width > height (rotation edge case that likely applies to iOS)

Platform services:

• GuiMobile.java:52 — routes UPnP config through the platform IDeviceAdapter; iOS already implements getUpnpPlatformService() but this check makes it unreachable (falls back to DefaultUpnpServiceConfiguration)
• adventure/world/World.java:293,809 — preventSystemSleep() around long world generation; iOS's device adapter already implements it, and the download services call it with no platform check at all
• assets/Assets.java:103,108 — Gdx.files.internal (bundled) vs. classpath (desktop) for fallback textures — same pattern FSkin.useFallbackDir() already fixed for iOS, and forge-gui-ios/fallback_skin/ bundles the same files; probably the safest conversions on this list
• Forge.java:210 — orientation auto-detection "Desktop default" branch. Caveat: the iOS launcher hardcodes androidOrientation = false, so this desktop branch currently doubles as iOS's orientation detection — converting it without also fixing the iOS launcher param would regress iOS startup orientation

Android-only (should NOT become isMobile())

• Forge.java:184 + assets/FSkin.java:405 — allowCardBG gate on androidVersion > 25 && totalDeviceRAM > 3400; iOS passes hwInfo = null / AndroidAPI = 0, so the non-Android branch already applies there correctly
• Forge.java:395 — splash-screen RAM/cache diagnostic based on Android hardware detection
• assets/AssetsDownloader.java (~15 sites) — the whole APK self-update and post-install asset-download flow; iOS bundles full resources in the IPA and App Store policy prohibits self-updating
• adventure/util/Config.java:65 — Android assets-dir vs. desktop-relative path; already effectively correct on iOS via resPath()'s existing isAndroid() || isIOS() branch
• screens/settings/SettingsPage.java:475 — Auto Cache Size, commented "this option does nothing except on Android"
• net/NetworkLogWriter.java:115 — skips ProcessHandle PID logging; iOS/MobiVM is already handled by the inner catch (noted in a comment there)

Unclear — needs a decision, not just a rename

• adventure/scene/SettingsScene.java:338 — hides advanced settings (border-mask crop, Auto Cache Size, Dispose Textures) on Android only, while SettingsPage.java:475 shows Auto Cache Size only on Android — the two settings screens gate the same pref in opposite directions today, independent of iOS. Worth resolving that inconsistency before deciding what iOS should see.
• gamemodes/match/HostedMatch.java:167 — AI_CAN_USE_TIMEOUT = !isAndroid() || androidAPILevel > 30, gating on CompletableFuture.completeOnTimeout (Java 9) availability. iOS currently gets true — whether MobiVM's backport actually supports completeOnTimeout is unverified (cf. the ProcessHandle gap in NetworkLogWriter), so this may be silently assuming iOS support that needs a runtime check.

Happy to send PRs for any subset of the candidates, but flagging them here first since each one needs an iOS eye.

[liminalwarmth]

Just noting that my agent obviously assembled this list, but I read it and wanted to document it in case it's helpful for figuring out where to apply a combined mobile helper.