The app crashed when search

[z2203659098]

Summary

as the titile. My device is Honor 10. The input method I use is Tongwen.

Steps to Reproduce

1. Open the app.
2. Hit the Magnifier button.
3. Input some words like sun, moon, mars.
4. And on my phone its will crash.

Expected Behavior

can find whats i have inputed.

Observed Behavior

when i hit the button its crashed.

Device

Honor 10

Android Version

10(29)

Sky Map Version

2.0.0:Apollo (1726) [F-Droid]

Screenshots

No response

[jaydeetay]

Another user reported the same issue. Here are the diagnostics with sensitive parts removed:
General

Device: moto z4 (qcom) en
Android version: 10 (29)
Sky Map version: 2.0.2:Apollo (1729) [Gms]

Graphics

Renderer: Adreno (TM) 612
OpenGL: OpenGL ES-CM 1.1 [gles1]
GL limits: tex 16384, line 1.0–8.0, point 1.0–1023.0

Sensors

Accelerometer: -2.23,9.82,2.03
Compass: -1.99,-35.32,-25.66
Gyroscope: 0.06,-0.03,-0.02
Rotation: 0.67,-0.06,-0.19,0.71,0.00
Light level: 0.38
Rot Matrix: 0.92,0.19,-0.34
-0.35,0.02,-0.94
-0.17,0.98,0.08

Location and Time

Location Permission: Denied
GPS: Disabled
[redacted]

Network

Connection: Connected (wifi)

Satellites

Orbit data: Not downloaded
Last fetch: Never

[jaydeetay]

Can't see any stack traces for this yet in the Play Store. Cannot repro on either test Pixel phone or the test OnePlus 7T. Doesn't seem to have been caught by the Google Play Store tests (but they only test on 5 devices). Could be locale-specific but the last report was in English.

@claude Can you trace the search code and look for possible sources of a crash? No stack traces yet.

[claude]

Claude finished @jaydeetay's task in 30s —— View job

---

Tasks

• Read repo context (AGENTS.md, CLAUDE.md)
• Locate search feature code (stardroid-v2, confirmed by versionCode 1729 / versionName "2.0.2:Apollo" in stardroid-v2/app/build.gradle.kts)
• Trace the search flow for possible crash sources
• Check for related tests
• Report findings

Findings

Both reports are on stardroid-v2 (Kotlin/Compose), not the legacy v1 app — confirmed by the version strings ("2.0.0/2.0.2:Apollo", builds 1726/1729).

I traced the full pipeline: SearchUi.kt → SearchViewModel.kt → RoomCatalogRepository/CatalogDao → math/projection. Ranked by likelihood:

1. Most likely — Compose text field / third-party IME interop crash (outside this repo's control).
stardroid-v2/app/src/main/kotlin/com/google/android/stardroid/ui/search/SearchUi.kt:249-264 uses a plain Material3 OutlinedTextField bound 1:1 to a StateFlow<String> — the safe pattern, so this isn't the classic "controlled field fights the IME" bug. This instead points at Compose's long-documented family of IndexOutOfBoundsException/StringIndexOutOfBoundsException crashes in EditingBuffer/TextFieldValue, triggered by certain third-party CJK IMEs sending setComposingRegion/setComposingText with offsets that race committed text. That matches both reports closely: a named third-party IME ("Tongwen", a Chinese IME) on an EMUI device, and a second report on a Motorola/qcom device — different OEMs, same symptom, crash specifically while typing (not tied to "sun"/"moon"/"mars" content — no code path treats those words specially). Compose BOM is 2024.09.03. This can't be fixed by patching our code directly, but see the mitigation note below.

2. Plausible — unguarded suspend call in the suggestions pipeline.
SearchViewModel.kt:113-119 and submit() at SearchViewModel.kt:174-183 both call catalog().searchByPrefix(...) with no try/catch, inside mapLatest/viewModelScope.launch. Any RuntimeException from Room/SQLite here (e.g. disk pressure, DB corruption) would propagate uncaught and crash the app on every keystroke after the debounce. The FTS query itself is defensively tokenized against injection (RoomCatalogRepository.kt:98-100, 366-367 strips to \p{L}\p{N} and lowercases before building the MATCH clause), so a plain word like "sun" shouldn't produce malformed SQL — but this remains an unguarded failure path worth wrapping regardless of root cause.

3. Lower likelihood — SkyMapDatabaseFactory.createWithRecovery (SkyMapDatabaseFactory.kt:43-60) explicitly documents that a retry failure "is a real bug or a full disk — that one propagates" uncaught. This is DB-open-time rather than search-specific, so it'd likely surface at app startup, not specifically when typing a query.

Ruled out after reading the code in full: CoordinateParser (no digits in "sun"/"moon"/"mars", short-circuits safely), locale-sensitive casing (all call sites use invariant lowercase()/Locale.ROOT), NaN/divide-by-zero in Vector3/SkyProjection/SearchGeometry (explicit guards throughout), and LazyColumn duplicate-key crashes (searchByPrefix dedupes by objectId before returning).

Tests: SearchViewModelTest.kt has thorough coverage of debounce, locale switching, coordinate parsing, and solar-system resolution — but nothing exercises actual IME/Compose text input, and no androidTest specifically searches "sun"/"moon"/"mars" (the exact names in both reports).

Regression check: inconclusive — this checkout is a shallow clone (1 commit), so I couldn't diff between the 2.0.0 and 2.0.2 tags to see what changed between builds 1726 and 1729. Recommend running, with full history:

git log --oneline -- stardroid-v2/app/src/main/kotlin/com/google/android/stardroid/ui/search \
  stardroid-v2/data/src/main/kotlin/com/google/android/stardroid/data/RoomCatalogRepository.kt \
  stardroid-v2/data/src/main/kotlin/com/google/android/stardroid/data/CatalogDao.kt

or gh api repos/sky-map-team/stardroid/compare/<2.0.0-tag>...<2.0.2-tag>.

Recommendation

Given how defensively the surrounding code is written (explicit NaN guards, FTS-injection-safe tokenization, locale-safe formatting, exhaustive ViewModel tests), the most likely culprit is an external Compose/IME interop crash, not app logic — but #2 (wrapping the suggestions/submit search calls in try/catch to fail soft with searchFailed() instead of crashing) is a cheap, safe defensive improvement regardless of root cause. If Crashlytics/Play Console vitals are wired up, getting an actual stack trace is the highest-leverage next step — it would immediately confirm whether the crash is in androidx.compose.foundation.text (framework) vs. this repo's code. I have not made any code changes, since this was a trace/investigation request — happy to implement the defensive try/catch in #2 if wanted.

[jaydeetay]

Will try to run on Firebase's test lab, but they have neither of these phones, and only a couple using API29 (in case that's a factor - the second reporter is on API29). Will try an API 29 phone and another random moto phone and something like the first user's phone.
Moto G Play (2021) might be a good choice - it's almost as old, has Motorola's custom UX framework overlay and is running API30. CPH2195 (OPPO A54 5G) might be a reasonable standin for the Honor.

[jaydeetay]

@claude while the tests run, proceed with implementing the guard you suggested. It's worth doing anyway. Question is, if we swallow the exception how will we get data on it? And although the app won't crash, will search work?

[claude]

Claude finished @jaydeetay's task in 4m 30s —— View job • claude/issue-1003-20260908-0242 • Create PR ➔

---

Tasks

• Read repo context (AGENTS.md, CLAUDE.md)
• Read SearchViewModel.kt and SearchUi.kt in full
• Add try/catch guard around searchByPrefix calls (suggestions + submit)
• Wire error reporting so swallowed exceptions are still visible in diagnostics
• Ensure search UX degrades gracefully instead of crashing
• Update SearchViewModelTest.kt for the new behavior
• Commit, push, and provide PR link
• Build/test locally — could not run, see note below

What changed

SearchViewModel.kt:227-245 — new searchByPrefixSafely() wraps the single Room/SQLite call
both suggestions (as-you-type, SearchViewModel.kt:119) and submit()
(SearchViewModel.kt:177) go through. CancellationException is explicitly rethrown first —
otherwise a plain catch (e: Exception) would also swallow mapLatest's own cancellation of a
superseded query — everything else is caught, logged via Log.e, and turned into an empty
result instead of an app crash.

Your two questions

"If we swallow the exception, how will we get data on it?" — We don't have Crashlytics
wired up (gms flavor only has Firebase Analytics, fdroid has none at all — checked
FirebaseAnalyticsAdapter.kt and Analytics.kt), so a caught exception can't surface as a
Play Console crash no matter what we do. Instead I added a new analytics event,
AnalyticsEvents.SEARCH_QUERY_ERROR_EVENT (search_query_error_ev), fired with the
exception's class name (AnalyticsEvents.SEARCH_QUERY_ERROR_TYPE) — same pattern already used
for SATELLITE_FETCH_FAILED_EVENT (AnalyticsEvents.kt:71-78), where the code comment
explains this repo already relies on aggregate GA4 counts in place of per-device stack traces
for exactly this reason. It won't give us a stack trace, but a spike in that event (and which
exception class is spiking) would confirm a systemic bug exists and roughly where. It's
gms-only, same as every other analytics event here — fdroid users get the crash fix but not
the telemetry, which is the existing tradeoff for this whole event system, not something new
to this change. The full exception with stack trace is still logged via Log.e, so anyone
with adb logcat access (e.g. reproducing on a loaner device) still gets it directly.

"Will search work?" — For a transient failure (a momentary disk hiccup, lock contention),
yes: it's a per-keystroke retry, so the very next debounce tick issues a fresh query and can
succeed. If the failure is deterministic — e.g. this IME sends something that reliably breaks
the query for a given input — every attempt with that input will keep failing the same way,
and the user sees the existing "No results were found" dialog (search_no_results string)
rather than a crash. That message is slightly misleading for a real error vs. a true no-match,
but I reused it rather than adding a new string/UI state, since the ask was specifically "the
guard you suggested" — a distinct error UI would be a reasonable follow-up if the telemetry
shows this firing often.

Tests

Added two SearchViewModelTest.kt cases: a thrown exception while typing leaves suggestions
empty and fires search_query_error_ev with the exception's class name; a thrown exception on
submit() leaves target null, sets noResults, and fires both search_query_error_ev and
the pre-existing search_failed_ev (submit's empty-hits path was already unconditional, so the
error event stacks with it rather than replacing it).

Note on verification

I could not run ./gradlew ktlintCheck or ./gradlew testDebugUnitTest — the sandbox blocked
gradlew invocations as requiring approval that isn't available in this non-interactive run.
I checked line lengths by hand (all new/changed lines are ≤100 chars, ktlint's limit) and
traced the logic manually, but this needs a real ./gradlew check run — CI should catch it on
the PR either way. If you'd like me to be able to verify locally next time, gradlew would
need to be added to --allowedTools.

[jaydeetay]

@claude OK, let's try this. If the telemetry shows it's a big issue we'll think about how to address it properly. We should also file an issue to look at crashlytics.

[claude]

Claude finished @jaydeetay's task in 2m 36s —— View job

---

Tasks

• Read repo context (AGENTS.md, CLAUDE.md)
• Re-check state of previous guard implementation (branch claude/issue-1003-20260908-0242)
• File a new issue to investigate adding Crashlytics/crash reporting
• Final summary

Status on the guard implementation

Nothing further needed from me there — it's already committed and pushed to
claude/issue-1003-20260908-0242.
That branch never got turned into an actual PR (only a prefilled link was generated), so if you
want it merged, use this link:
Create PR for the search-guard fix.
(This session started on a fresh branch, claude/issue-1003-20260908-0249, with no commits of its own — the guard code lives only on ...0242.)

Crashlytics follow-up issue

I couldn't file it directly — gh CLI calls in this sandbox require an approval step that isn't
available in this non-interactive run (same limitation noted for ./gradlew earlier in this
thread). If you'd like me to be able to open issues/PRs via gh directly in future runs, that
tool would need to be added to --allowedTools.

As a workaround, here's a prefilled "new issue" link with the context from this thread — one
click to file it:

Create "Investigate adding Crashlytics (or similar) crash reporting" issue

No code changes were made in this session (no PR from this branch).
• branch claude/issue-1003-20260908-0249

[jaydeetay]

The Firebase tests didn't shed any light - no crashes. But they're just monkey tests - there's a screenshot showing the search dialog but no proof anything was typed.

[jaydeetay]

So to recap, we think this a bug in the phone itself @z2203659098 . I'll push a release out with this fix and it'll go to FDroid in a few days. It might not work - we're just 'coding around' the problem I think - but I'd be interested to hear from you if it helps.

[jaydeetay]

https://github.com/sky-map-team/stardroid/releases/tag/v2.0.3 might fix it.