Extended Performancehud - #1776
Conversation
User can set limits for batterylevel and temperature. Warning if batterylevel is under the chosen value. Warning if batterytemperature is over the chosen value. If Limits are reached a beep sound is played and background of performancehud is blinking.
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThe performance HUD adds configurable battery level and temperature warnings. Numeric battery values are added to snapshots, runtime warnings trigger tones and background colors, and localized labels support the new QuickMenu controls. ChangesPerformance HUD battery warnings
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant PerformanceHudView
participant HudSnapshot
participant PerformanceHudConfig
participant ToneGenerator
participant backgroundDrawable
PerformanceHudView->>HudSnapshot: read batteryPercent and batteryTempValue
PerformanceHudView->>PerformanceHudConfig: read warning limits and enabled flags
PerformanceHudView->>ToneGenerator: play warning tone when threshold is exceeded
PerformanceHudView->>backgroundDrawable: apply warning or backup background color
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (5)
app/src/main/res/values-it/strings.xml (1)
353-356: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win"temp." abbreviation inconsistent with existing terminology.
performance_hud_battery_temp_warning/_limitabbreviate to "temp." whileperformance_hud_battery_temperature(line 349) spells out "Temperatura batteria" in full. Same root cause as de/es/fr — see the consolidated comment for details and per-file fixes.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/src/main/res/values-it/strings.xml` around lines 353 - 356, Update the Italian translations for performance_hud_battery_temp_warning and performance_hud_battery_temp_limit to use the full “Temperatura batteria” terminology, matching performance_hud_battery_temperature instead of the “temp.” abbreviation.app/src/main/res/values-es/strings.xml (1)
364-367: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win"temp." abbreviation inconsistent with existing terminology.
performance_hud_battery_temp_warning/_limitabbreviate to "temp." whileperformance_hud_battery_temperature(line 360) spells out "Temperatura de la batería" in full. Same root cause as de/fr/it — see the consolidated comment for details and per-file fixes.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/src/main/res/values-es/strings.xml` around lines 364 - 367, Update the Spanish strings performance_hud_battery_temp_warning and performance_hud_battery_temp_limit to use the full “temperatura” terminology, matching performance_hud_battery_temperature, and remove the inconsistent “temp.” abbreviation.app/src/main/res/values-de/strings.xml (1)
346-349: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win"Temp" abbreviation inconsistent with existing terminology.
The new strings use "Batterie Temp Warnung"/"Batterie Temp Limit", but every other temperature string in this file spells it out (
performance_hud_battery_temperature= "Akkutemperatur",performance_hud_cpu_temperature= "CPU-Temperatur",performance_hud_gpu_temperature= "GPU-Temperatur"). This is part of a shared root cause also present in the es/fr/it locale files — see the consolidated comment for a full breakdown and fix per file.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/src/main/res/values-de/strings.xml` around lines 346 - 349, Update the German strings performance_hud_battery_temp_warning and performance_hud_battery_temp_limit to use the established full temperature terminology consistent with the other battery, CPU, and GPU temperature strings; change only these two localized values.app/src/main/java/app/gamenative/ui/component/QuickMenu.kt (1)
1103-1109: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winTemperature value bypasses string resources, unlike every other adjustment row.
valueTextfor the battery temperature limit is built with a raw Kotlin template ("${...} °C"), while every other row in this file (FPS target, background opacity, color intensity, and the sibling battery level limit row) usesstringResource(...). This hardcodes the°Cunit and format, breaking the localization pattern the rest of the composable follows.♻️ Suggested fix: add a formatted string resource
- valueText = "${(performanceHudConfig.batteryTemperatureWarningLimit * 100f).roundToInt()} °C", + valueText = stringResource( + R.string.performance_hud_temperature_value, + (performanceHudConfig.batteryTemperatureWarningLimit * 100f).roundToInt(), + ),Add to
strings.xml:<string name="performance_hud_temperature_value">%1$d °C</string>Separately (informational, not a bug):
batteryTemperatureWarningLimitis stored as a 0–1 fraction and multiplied by 100 for display/comparison, reusing the percentage-slider convention for what is actually a Celsius value. It's internally consistent withPerformanceHudView.kt's comparison logic, but a raw temperature field (e.g., 0–100 Float) would read more clearly to future maintainers.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/src/main/java/app/gamenative/ui/component/QuickMenu.kt` around lines 1103 - 1109, Replace the raw valueText interpolation in the battery temperature QuickMenuAdjustmentRow with stringResource using a formatted performance_hud_temperature_value resource, passing the rounded Celsius value as its argument. Add the corresponding localized string resource in strings.xml and preserve the existing limit conversion and progress behavior.app/src/main/res/values-fr/strings.xml (1)
353-356: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win"temp." abbreviation inconsistent with existing terminology.
performance_hud_battery_temp_warning/_limitabbreviate to "temp." whileperformance_hud_battery_temperature(line 349) spells out "Température de la batterie" in full. Same root cause as de/es/it — see the consolidated comment for details and per-file fixes.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/src/main/res/values-fr/strings.xml` around lines 353 - 356, Update the French strings performance_hud_battery_temp_warning and performance_hud_battery_temp_limit to use the established full “température de la batterie” terminology, matching performance_hud_battery_temperature instead of the abbreviated “temp.” wording.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt`:
- Around line 122-125: Update the appearance initialization in
PerformanceHudView so backupBackgroundColor is refreshed after init applies
applyAppearance(), capturing the configured HUD background rather than the
pre-appearance value. Ensure the restore logic in the non-warning update path
around currentBackgroundColor uses this refreshed backup, preserving later
opacity changes.
- Around line 245-248: Update the battery warning evaluation in
PerformanceHudView so unavailable battery percentage values do not trigger the
low-battery warning. Preserve BatterySnapshot.percent nullability through the
snapshot handling near the referenced conversion, or explicitly require a
non-null value before comparing against batteryLevelWarningLimit; keep normal
threshold evaluation unchanged for available values.
- Around line 250-255: Update PerformanceHudView’s warning-tone handling to
reuse a persistent ToneGenerator instead of allocating one in each levelWarning
or tempWarning branch. Stop and release the generator during
onDetachedFromWindow(), ensuring repeated update cycles do not accumulate
unreleased instances.
- Line 3: Remove the resource-attribute reference from PerformanceHudView and
derive both immutable warning colors from the clamped config.backgroundOpacity
value. Update the color values during applyAppearance() or setConfig() so they
refresh when the HUD opacity changes, while preserving the existing warning
color behavior otherwise.
In `@app/src/main/res/values/strings.xml`:
- Around line 352-355: Replace the German values for
performance_hud_battery_level_warning, performance_hud_battery_level_limit,
performance_hud_battery_temp_warning, and performance_hud_battery_temp_limit in
the default strings resource with the specified English labels, preserving the
existing resource names.
---
Nitpick comments:
In `@app/src/main/java/app/gamenative/ui/component/QuickMenu.kt`:
- Around line 1103-1109: Replace the raw valueText interpolation in the battery
temperature QuickMenuAdjustmentRow with stringResource using a formatted
performance_hud_temperature_value resource, passing the rounded Celsius value as
its argument. Add the corresponding localized string resource in strings.xml and
preserve the existing limit conversion and progress behavior.
In `@app/src/main/res/values-de/strings.xml`:
- Around line 346-349: Update the German strings
performance_hud_battery_temp_warning and performance_hud_battery_temp_limit to
use the established full temperature terminology consistent with the other
battery, CPU, and GPU temperature strings; change only these two localized
values.
In `@app/src/main/res/values-es/strings.xml`:
- Around line 364-367: Update the Spanish strings
performance_hud_battery_temp_warning and performance_hud_battery_temp_limit to
use the full “temperatura” terminology, matching
performance_hud_battery_temperature, and remove the inconsistent “temp.”
abbreviation.
In `@app/src/main/res/values-fr/strings.xml`:
- Around line 353-356: Update the French strings
performance_hud_battery_temp_warning and performance_hud_battery_temp_limit to
use the established full “température de la batterie” terminology, matching
performance_hud_battery_temperature instead of the abbreviated “temp.” wording.
In `@app/src/main/res/values-it/strings.xml`:
- Around line 353-356: Update the Italian translations for
performance_hud_battery_temp_warning and performance_hud_battery_temp_limit to
use the full “Temperatura batteria” terminology, matching
performance_hud_battery_temperature instead of the “temp.” abbreviation.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 434fd344-eec9-4b7d-8ff1-0d1beaebc49e
📒 Files selected for processing (19)
app/src/main/java/app/gamenative/ui/component/QuickMenu.ktapp/src/main/java/app/gamenative/ui/data/PerformanceHudConfig.ktapp/src/main/java/app/gamenative/ui/widget/PerformanceHudModels.ktapp/src/main/java/app/gamenative/ui/widget/PerformanceHudView.ktapp/src/main/res/values-da/strings.xmlapp/src/main/res/values-de/strings.xmlapp/src/main/res/values-es/strings.xmlapp/src/main/res/values-fr/strings.xmlapp/src/main/res/values-it/strings.xmlapp/src/main/res/values-ja/strings.xmlapp/src/main/res/values-ko/strings.xmlapp/src/main/res/values-pl/strings.xmlapp/src/main/res/values-pt-rBR/strings.xmlapp/src/main/res/values-ro/strings.xmlapp/src/main/res/values-ru/strings.xmlapp/src/main/res/values-uk/strings.xmlapp/src/main/res/values-zh-rCN/strings.xmlapp/src/main/res/values-zh-rTW/strings.xmlapp/src/main/res/values/strings.xml
| @@ -1,5 +1,6 @@ | |||
| package app.gamenative.ui.widget | |||
|
|
|||
| import android.R.attr.opacity | |||
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'Files matching PerformanceHudView.kt:\n'
fd -a 'PerformanceHudView\.kt$' . || true
file=$(fd 'PerformanceHudView\.kt$' . | head -n1 || true)
if [ -n "$file" ]; then
echo "FILE=$file"
wc -l "$file"
sed -n '1,190p' "$file" | cat -n
fi
printf '\nSearch for backgroundOpacity/optical config usage:\n'
rg -n "backgroundOpacity|PerformanceHud|opacity|warningBackgroundColor|backgroundColor|applyAppearance" -S .Repository: utkarshdalal/GameNative
Length of output: 48107
🌐 Web query:
Android resource attribute android.R.attr.opacity returns int resource identifier not configured value documentation
💡 Result:
The android.R.attr.opacity identifier is an integer constant used to reference a specific styleable attribute, not a direct resource value [1][2][3]. In the Android resource system, classes like android.R.attr contain static integer constants that function as keys or identifiers for attributes, which are used to look up values defined in themes or styles [2][4]. If you are attempting to retrieve a value associated with android.R.attr.opacity (or any other attribute), you cannot do so by reading the identifier directly [2]. Instead, you must resolve the attribute against the current theme using TypedArray or TypedValue [4][5]. Standard process for resolving an attribute: 1. Obtain a theme from your Context [4][5]. 2. Use theme.resolveAttribute(int resid, TypedValue outValue, boolean resolveRefs) to populate a TypedValue object with the data associated with that attribute [4][5]. 3. Alternatively, use context.obtainStyledAttributes(int[] attrs) to extract values into a TypedArray [4][5]. If you observe "not configured value" or similar behavior, it is likely because the attribute has not been assigned a value in the current theme or the specific theme context you are using does not define it [2][4]. Attributes in android.R.attr are definition-only; they do not have inherent values until a theme or style provides them [2].
Citations:
- 1: https://emanual.github.io/Android-docs/reference/android/R.attr.html
- 2: https://stackoverflow.com/questions/4114585/loading-resource-represented-by-android-r-attr
- 3: https://www.android-doc.com/reference/android/R.attr.html
- 4: https://stackoverflow.com/questions/45218271/how-to-get-an-attr-value-programmatically
- 5: https://stackoverflow.com/questions/17277618/get-color-value-programmatically-when-its-a-reference-theme
🏁 Script executed:
#!/bin/bash
set -euo pipefail
file="./app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt"
echo "Relevant config/class sections:"
sed -n '122,140p' "$file" | cat -n
sed -n '187,198p' "$file" | cat -n
sed -n '278,332p' "$file" | cat -n
echo
echo "Field assignments and warning color usages:"
rg -n "batteryLevelBackgroundColor|batteryTempBackgroundColor|setBackgroundColor|currentBackgroundColor|backgroundDrawable|Color\\.argb\\(|Color\\.rgb\\(" "$file"
echo
echo "Kotlin/Android resource identifier semantic facts from repo metadata/constants (read-only):"
python3 - <<'PY'
from pathlib import Path
import re
p=Path("app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt")
text=p.read_text()
imports=[line.strip() for line in text.splitlines() if line.startswith("import android.R.attr")]
ops=[line.strip() for line in text.splitlines() if "opacity" in line]
print("imports:")
for line in imports:
print(line)
print("opacity usages:")
for line in ops:
print(line)
PYRepository: utkarshdalal/GameNative
Length of output: 5261
Derive the HUD warning colors from the actual opacity value.
android.R.attr.opacity is a resource attribute ID, not config.backgroundOpacity, so both immutable warning colors use an incorrect alpha and cannot react when the user changes the HUD background opacity. Compute the warning colors from the clamped config opacity, and refresh them in applyAppearance()/setConfig() if they must update at runtime.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt` at line 3,
Remove the resource-attribute reference from PerformanceHudView and derive both
immutable warning colors from the clamped config.backgroundOpacity value. Update
the color values during applyAppearance() or setConfig() so they refresh when
the HUD opacity changes, while preserving the existing warning color behavior
otherwise.
| private var currentBackgroundColor = (backgroundDrawable as? GradientDrawable) | ||
| ?.color?.defaultColor ?: Color.BLACK | ||
|
|
||
| private val backupBackgroundColor = currentBackgroundColor |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Refresh the backup background color after applying appearance.
backupBackgroundColor is captured before init calls applyAppearance() and is never updated. On the first non-warning update, Lines 263-268 restore that stale fallback instead of the configured HUD background, and later opacity changes are also lost.
Also applies to: 263-268
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt` around
lines 122 - 125, Update the appearance initialization in PerformanceHudView so
backupBackgroundColor is refreshed after init applies applyAppearance(),
capturing the configured HUD background rather than the pre-appearance value.
Ensure the restore logic in the non-warning update path around
currentBackgroundColor uses this refreshed backup, preserving later opacity
changes.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 19 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="app/src/main/java/app/gamenative/ui/component/QuickMenu.kt">
<violation number="1" location="app/src/main/java/app/gamenative/ui/component/QuickMenu.kt:1107">
P3: The battery temperature value display uses inline string interpolation (`"${...} °C"`) instead of a localized string resource. The battery level row already follows the proper pattern using `stringResource(R.string.performance_hud_percentage_value, ...)`. Consider adding a string resource like `<string name="performance_hud_temperature_value">%1$d °C</string>` to `strings.xml` and referencing it from code for consistency and localization support.</violation>
</file>
Tip: cubic used a learning from your PR history. Let your coding agent read cubic learnings directly with the cubic MCP.
Re-trigger cubic
| { | ||
| QuickMenuAdjustmentRow( | ||
| title = stringResource(R.string.performance_hud_battery_temp_limit), | ||
| valueText = "${(performanceHudConfig.batteryTemperatureWarningLimit * 100f).roundToInt()} °C", |
There was a problem hiding this comment.
P3: The battery temperature value display uses inline string interpolation ("${...} °C") instead of a localized string resource. The battery level row already follows the proper pattern using stringResource(R.string.performance_hud_percentage_value, ...). Consider adding a string resource like <string name="performance_hud_temperature_value">%1$d °C</string> to strings.xml and referencing it from code for consistency and localization support.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At app/src/main/java/app/gamenative/ui/component/QuickMenu.kt, line 1107:
<comment>The battery temperature value display uses inline string interpolation (`"${...} °C"`) instead of a localized string resource. The battery level row already follows the proper pattern using `stringResource(R.string.performance_hud_percentage_value, ...)`. Consider adding a string resource like `<string name="performance_hud_temperature_value">%1$d °C</string>` to `strings.xml` and referencing it from code for consistency and localization support.</comment>
<file context>
@@ -1054,6 +1052,77 @@ private fun PerformanceHudQuickMenuTab(
+ {
+ QuickMenuAdjustmentRow(
+ title = stringResource(R.string.performance_hud_battery_temp_limit),
+ valueText = "${(performanceHudConfig.batteryTemperatureWarningLimit * 100f).roundToInt()} °C",
+ progress = normalizedProgress(performanceHudConfig.batteryTemperatureWarningLimit, 0f, 1f),
+ onDecrease = {
</file context>
Remove use of opacity
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Warnings only if valid values.
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt (1)
381-381: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winPreserve
nullfor unavailable temperatures.
batteryTempValueis nullable, and the warning guard relies on null to skip invalid readings, but this assignment converts a missing temperature to0. Pass throughbatterySnapshot.temperatureCdirectly.Based on the PR objective, warning checks should run only when battery values are valid.
Proposed fix
- batteryTempValue = batterySnapshot.temperatureC ?: 0, + batteryTempValue = batterySnapshot.temperatureC,Also applies to: 247-248
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt` at line 381, Update the battery temperature assignments in the Performance HUD update logic to pass batterySnapshot.temperatureC directly instead of converting null to 0. Preserve null through both referenced assignment locations so the existing warning guard skips unavailable temperature readings.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt`:
- Line 381: Update the battery temperature assignments in the Performance HUD
update logic to pass batterySnapshot.temperatureC directly instead of converting
null to 0. Preserve null through both referenced assignment locations so the
existing warning guard skips unavailable temperature readings.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 358e23c5-f5af-41ae-9185-cb1d58f70d4e
📒 Files selected for processing (2)
app/src/main/java/app/gamenative/ui/widget/PerformanceHudModels.ktapp/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
1 issue found across 4 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt">
<violation number="1" location="app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt:247">
P2: The null guard `snapshot.batteryTempValue != null` on the temperature warning is ineffective because `batteryTempValue` is constructed as `batterySnapshot.temperatureC ?: 0` — always non-null, defaulting to 0 when no temperature reading exists. This means a missing temperature reading will not prevent the false-positive guard from passing. Fix by making `batteryTempValue` properly nullable at the construction site, matching the pattern used for `batteryPercent`.</violation>
</file>
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
| val levelWarning = snapshot.batteryPercent != null && config.batteryLevelWarningEnabled && | ||
| snapshot.batteryPercent < (config.batteryLevelWarningLimit * 100) | ||
|
|
||
| val tempWarning = snapshot.batteryTempValue != null && config.batteryTemperatureWarningEnabled && |
There was a problem hiding this comment.
P2: The null guard snapshot.batteryTempValue != null on the temperature warning is ineffective because batteryTempValue is constructed as batterySnapshot.temperatureC ?: 0 — always non-null, defaulting to 0 when no temperature reading exists. This means a missing temperature reading will not prevent the false-positive guard from passing. Fix by making batteryTempValue properly nullable at the construction site, matching the pattern used for batteryPercent.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt, line 247:
<comment>The null guard `snapshot.batteryTempValue != null` on the temperature warning is ineffective because `batteryTempValue` is constructed as `batterySnapshot.temperatureC ?: 0` — always non-null, defaulting to 0 when no temperature reading exists. This means a missing temperature reading will not prevent the false-positive guard from passing. Fix by making `batteryTempValue` properly nullable at the construction site, matching the pattern used for `batteryPercent`.</comment>
<file context>
@@ -241,9 +241,10 @@ class PerformanceHudView(
snapshot.batteryPercent < (config.batteryLevelWarningLimit * 100)
- val tempWarning = config.batteryTemperatureWarningEnabled &&
+
+ val tempWarning = snapshot.batteryTempValue != null && config.batteryTemperatureWarningEnabled &&
snapshot.batteryTempValue > (config.batteryTemperatureWarningLimit * 100)
</file context>
There was a problem hiding this comment.
6 issues found across 19 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt">
<violation number="1" location="app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt:124">
P2: HUD background becomes opaque black after its first update, ignoring `backgroundOpacity`. Keep the non-warning color synchronized with `applyAppearance()` rather than capturing the uninitialized drawable color.</violation>
<violation number="2" location="app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt:125">
P3: Warning colors are embedded in the view instead of named shared color resources, making theme changes and visual maintenance harder. Define named warning colors in resources and resolve them here.
(Based on your team's feedback about hardcoded UI colors.) [FEEDBACK_USED]</violation>
<violation number="3" location="app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt:259">
P2: A temperature exactly at the selected limit does not warn; default 40 °C only starts alerting above 40 °C. Include the limit in the high-temperature condition.</violation>
<violation number="4" location="app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt:265">
P2: When both conditions are active, the temperature call replaces the low-battery tone, so users hear only one of the promised distinct cues. Choose an explicit priority or queue the tones instead of starting both on one `ToneGenerator`.</violation>
</file>
<file name="app/src/main/res/values-de/strings.xml">
<violation number="1" location="app/src/main/res/values-de/strings.xml:349">
P2: `performance_hud_battery_temp_limit` = "Batterie Temp Limit" is inconsistent with existing German battery terminology. The base string `performance_hud_battery_temperature` uses "Akkutemperatur" and the sibling `battery_temp_warning` correctly uses "Akkutemperatur-Warnung". This string mixes "Batterie" vs "Akku", uses the abbreviation "Temp" instead of the full word, and lacks hyphenation. Change to "Akkutemperatur-Limit" for consistency with the existing term and with the pattern used in `battery_temp_warning`.</violation>
</file>
<file name="app/src/main/java/app/gamenative/ui/widget/PerformanceHudModels.kt">
<violation number="1" location="app/src/main/java/app/gamenative/ui/widget/PerformanceHudModels.kt:42">
P2: `batteryTempValue` declared `Int?` but the view populates it with `?: 0`, making it never null. The null check at line 258 is therefore always true, so the safety guard against missing temperature readings is effectively dead code. Either drop the `?: 0` in the view (preferred — keeps the null contract honest) or align the model type to `Int` to reflect actual behavior.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| getToneGenerator().startTone(ToneGenerator.TONE_PROP_ACK, 150) | ||
| } | ||
| if (tempWarning) { | ||
| getToneGenerator().startTone(ToneGenerator.TONE_CDMA_PIP, 150) |
There was a problem hiding this comment.
P2: When both conditions are active, the temperature call replaces the low-battery tone, so users hear only one of the promised distinct cues. Choose an explicit priority or queue the tones instead of starting both on one ToneGenerator.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt, line 265:
<comment>When both conditions are active, the temperature call replaces the low-battery tone, so users hear only one of the promised distinct cues. Choose an explicit priority or queue the tones instead of starting both on one `ToneGenerator`.</comment>
<file context>
@@ -216,6 +251,33 @@ class PerformanceHudView(
+ getToneGenerator().startTone(ToneGenerator.TONE_PROP_ACK, 150)
+ }
+ if (tempWarning) {
+ getToneGenerator().startTone(ToneGenerator.TONE_CDMA_PIP, 150)
+ }
+
</file context>
| snapshot.batteryPercent < (config.batteryLevelWarningLimit * 100) | ||
|
|
||
| val tempWarning = snapshot.batteryTempValue != null && config.batteryTemperatureWarningEnabled && | ||
| snapshot.batteryTempValue > (config.batteryTemperatureWarningLimit * 100) |
There was a problem hiding this comment.
P2: A temperature exactly at the selected limit does not warn; default 40 °C only starts alerting above 40 °C. Include the limit in the high-temperature condition.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt, line 259:
<comment>A temperature exactly at the selected limit does not warn; default 40 °C only starts alerting above 40 °C. Include the limit in the high-temperature condition.</comment>
<file context>
@@ -216,6 +251,33 @@ class PerformanceHudView(
+ snapshot.batteryPercent < (config.batteryLevelWarningLimit * 100)
+
+ val tempWarning = snapshot.batteryTempValue != null && config.batteryTemperatureWarningEnabled &&
+ snapshot.batteryTempValue > (config.batteryTemperatureWarningLimit * 100)
+
+ if (levelWarning) {
</file context>
| snapshot.batteryTempValue > (config.batteryTemperatureWarningLimit * 100) | |
| snapshot.batteryTempValue >= (config.batteryTemperatureWarningLimit * 100) |
| private var currentBackgroundColor = (backgroundDrawable as? GradientDrawable) | ||
| ?.color?.defaultColor ?: Color.BLACK | ||
|
|
||
| private val backupBackgroundColor = currentBackgroundColor |
There was a problem hiding this comment.
P2: HUD background becomes opaque black after its first update, ignoring backgroundOpacity. Keep the non-warning color synchronized with applyAppearance() rather than capturing the uninitialized drawable color.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt, line 124:
<comment>HUD background becomes opaque black after its first update, ignoring `backgroundOpacity`. Keep the non-warning color synchronized with `applyAppearance()` rather than capturing the uninitialized drawable color.</comment>
<file context>
@@ -109,6 +118,21 @@ class PerformanceHudView(
+ private var currentBackgroundColor = (backgroundDrawable as? GradientDrawable)
+ ?.color?.defaultColor ?: Color.BLACK
+
+ private val backupBackgroundColor = currentBackgroundColor
+ private val batteryLevelBackgroundColor = Color.argb(
+ 102,
</file context>
| <string name="performance_hud_battery_level_warning">Batteriestand Warnung</string> | ||
| <string name="performance_hud_battery_level_limit">Batteriestand Limit</string> | ||
| <string name="performance_hud_battery_temp_warning">Akkutemperatur-Warnung</string> | ||
| <string name="performance_hud_battery_temp_limit">Batterie Temp Limit</string> |
There was a problem hiding this comment.
P2: performance_hud_battery_temp_limit = "Batterie Temp Limit" is inconsistent with existing German battery terminology. The base string performance_hud_battery_temperature uses "Akkutemperatur" and the sibling battery_temp_warning correctly uses "Akkutemperatur-Warnung". This string mixes "Batterie" vs "Akku", uses the abbreviation "Temp" instead of the full word, and lacks hyphenation. Change to "Akkutemperatur-Limit" for consistency with the existing term and with the pattern used in battery_temp_warning.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At app/src/main/res/values-de/strings.xml, line 349:
<comment>`performance_hud_battery_temp_limit` = "Batterie Temp Limit" is inconsistent with existing German battery terminology. The base string `performance_hud_battery_temperature` uses "Akkutemperatur" and the sibling `battery_temp_warning` correctly uses "Akkutemperatur-Warnung". This string mixes "Batterie" vs "Akku", uses the abbreviation "Temp" instead of the full word, and lacks hyphenation. Change to "Akkutemperatur-Limit" for consistency with the existing term and with the pattern used in `battery_temp_warning`.</comment>
<file context>
@@ -343,6 +343,10 @@
+ <string name="performance_hud_battery_level_warning">Batteriestand Warnung</string>
+ <string name="performance_hud_battery_level_limit">Batteriestand Limit</string>
+ <string name="performance_hud_battery_temp_warning">Akkutemperatur-Warnung</string>
+ <string name="performance_hud_battery_temp_limit">Batterie Temp Limit</string>
<string name="touchpad_help">Touchpad-Hilfe</string>
<string name="hide_controls_with_controller">On-Screen-Controller bei Gamepad ausblenden</string>
</file context>
| <string name="performance_hud_battery_temp_limit">Batterie Temp Limit</string> | |
| <string name="performance_hud_battery_temp_limit">Akkutemperatur-Limit</string> |
| val power: String?, | ||
| val runtime: String?, | ||
| val batteryTemp: String?, | ||
| val batteryTempValue: Int?, |
There was a problem hiding this comment.
P2: batteryTempValue declared Int? but the view populates it with ?: 0, making it never null. The null check at line 258 is therefore always true, so the safety guard against missing temperature readings is effectively dead code. Either drop the ?: 0 in the view (preferred — keeps the null contract honest) or align the model type to Int to reflect actual behavior.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At app/src/main/java/app/gamenative/ui/widget/PerformanceHudModels.kt, line 42:
<comment>`batteryTempValue` declared `Int?` but the view populates it with `?: 0`, making it never null. The null check at line 258 is therefore always true, so the safety guard against missing temperature readings is effectively dead code. Either drop the `?: 0` in the view (preferred — keeps the null contract honest) or align the model type to `Int` to reflect actual behavior.</comment>
<file context>
@@ -35,9 +35,11 @@ internal data class HudSnapshot(
val power: String?,
val runtime: String?,
val batteryTemp: String?,
+ val batteryTempValue: Int?,
val clock: String,
val cpuTemp: String?,
</file context>
| ?.color?.defaultColor ?: Color.BLACK | ||
|
|
||
| private val backupBackgroundColor = currentBackgroundColor | ||
| private val batteryLevelBackgroundColor = Color.argb( |
There was a problem hiding this comment.
P3: Warning colors are embedded in the view instead of named shared color resources, making theme changes and visual maintenance harder. Define named warning colors in resources and resolve them here.
(Based on your team's feedback about hardcoded UI colors.)
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At app/src/main/java/app/gamenative/ui/widget/PerformanceHudView.kt, line 125:
<comment>Warning colors are embedded in the view instead of named shared color resources, making theme changes and visual maintenance harder. Define named warning colors in resources and resolve them here.
(Based on your team's feedback about hardcoded UI colors.) </comment>
<file context>
@@ -109,6 +118,21 @@ class PerformanceHudView(
+ ?.color?.defaultColor ?: Color.BLACK
+
+ private val backupBackgroundColor = currentBackgroundColor
+ private val batteryLevelBackgroundColor = Color.argb(
+ 102,
+ 128,
</file context>
1 participant
User can set limits for batterylevel and temperature. Warning if batterylevel is under the chosen value. Warning if batterytemperature is over the chosen value. If Limits are reached a beep sound is played and background of performancehud is blinking.
Description
User can set limits for batterylevel and temperature. Warning if batterylevel is under the chosen value. Warning if batterytemperature is over the chosen value. If Limits are reached a beep sound is played and background of performancehud is blinking.
Recording
Type of Change
Checklist
#code-changes, I have discussed this change there and it has been green-lighted. If I do not have access, I have still provided clear context in this PR. If I skip both, I accept that this change may face delays in review, may not be reviewed at all, or may be closed.CONTRIBUTING.md.Summary by cubic
Add configurable low-battery and high-battery-temperature warnings to the Performance HUD. When a limit is hit, the HUD background blinks with a distinct color and a short tone; limits and toggles are in the Quick Menu.
New Features
Bug Fixes
Written for commit 8ece481. Summary will update on new commits.
Summary by CodeRabbit