Skip to content

Update index.js#2373

Open
peak-load wants to merge 1 commit intositespeedio:mainfrom
peak-load:main
Open

Update index.js#2373
peak-load wants to merge 1 commit intositespeedio:mainfrom
peak-load:main

Conversation

@peak-load
Copy link

@peak-load peak-load commented Mar 23, 2026

The current Android battery temperature parsing looks a bit too broad and can pick up unrelated numeric values from dumpsys battery output.

Today it uses:

dumpsys battery | grep temperature | grep -Eo '[0-9]{1,3}'

That works only if the output contains a single relevant temperature match. On at least one real device I tested (Samsung A16 / Android 16), dumpsys battery returns both the expected battery field and additional log-style lines that also contain temperature, for example:

temperature: 242
03-23 14:19:54.299  Sending ACTION_BATTERY_CHANGED: ... temperature: 293, ...
03-23 14:27:46.675  Sending ACTION_BATTERY_CHANGED: ... temperature: 281, ...

With the current implementation, those extra matches can make the parser extract multiple unrelated numbers instead of the actual battery temperature field, which can then lead to invalid numeric values and downstream NaN warnings.

I’d suggest narrowing the parsing to the real temperature: field only, for example:

async getTemperature() {
  const output = await this._runCommandAndGet(
    `dumpsys battery | awk '/^ *temperature:/ { print $2; exit }'`
  );
  const temperature = Number(output.trim());
  return Number.isFinite(temperature) ? temperature / 10 : undefined;
}

Why this looks safer:

  • matches only the actual battery temperature line
  • avoids unrelated numbers from additional output
  • preserves the existing / 10 conversion, which is correct for Android battery temperature values
  • returns undefined instead of propagating invalid values

The current Android battery temperature parsing looks a bit too broad and can pick up unrelated numeric values from `dumpsys battery` output.

Today it uses:

```js
dumpsys battery | grep temperature | grep -Eo '[0-9]{1,3}'
```

That works only if the output contains a single relevant temperature match. On at least one real device I tested (Samsung A16 / Android 16), dumpsys battery returns both the expected battery field and additional log-style lines that also contain temperature, for example:
```
temperature: 242
03-23 14:19:54.299  Sending ACTION_BATTERY_CHANGED: ... temperature: 293, ...
03-23 14:27:46.675  Sending ACTION_BATTERY_CHANGED: ... temperature: 281, ...
```

With the current implementation, those extra matches can make the parser extract multiple unrelated numbers instead of the actual battery temperature field, which can then lead to invalid numeric values and downstream NaN warnings.

I’d suggest narrowing the parsing to the real temperature: field only, for example:

```js
async getTemperature() {
  const output = await this._runCommandAndGet(
    `dumpsys battery | awk '/^ *temperature:/ { print $2; exit }'`
  );
  const temperature = Number(output.trim());
  return Number.isFinite(temperature) ? temperature / 10 : undefined;
}```

Why this looks safer:
	•	matches only the actual battery temperature line
	•	avoids unrelated numbers from additional output
	•	preserves the existing / 10 conversion, which is correct for Android battery temperature values
	•	returns undefined instead of propagating invalid values

This should make Android battery temperature collection more robust across vendor-specific dumpsys battery output formats.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant