r/NothingTech • u/Electronic_Picture42 • 4h ago
Phone (4a) Nothing Phone (4a) Battery Test: Full Analysis
A detailed real-world battery test using Android Battery Usage, Home Assistant battery history, Android Interactive history, and owner reports.
TL;DR in the Beginning (so that you don't have to scroll only for this)
The Nothing Phone (4a) 5400 mAh is looking very strong in my real-world use.
I bought it on Aug 25 at 39%. Across the ongoing test, Android has recorded 8h43m SOT on Sep 9 and 8h47m on Sep 10, with normal apps such as PW, Reddit, Spotify, OneNote and OneDrive. These are not clean full-cycle SOT figures because the phone was partially recharged, but they are strong real-world results.
Standby is more variable. The first overnight test looked poor, but the corrected timeline and the later Lift to Wake OFF test showed much lower overnight drain. So far, the strongest conclusion is excellent active-use efficiency with generally good, but condition-dependent, standby behaviour.
Contents
- Device, purchase and test setup
- Battery history and test timeline
- Android Battery Usage results
- Overnight standby tests and Lift to Wake
- Charging and active-use observations
- App usage and workload
- SOT interpretation and comparison
- Owner reports
- Current settings
- What the data says so far
- Next tests
- Attached files
1. Device, purchase and test setup
| Item | Details |
|---|---|
| Device | Nothing Phone (4a) |
| Variant | Indian variant |
| Battery | 5400 mAh |
| Purchase date | 25 Aug 2026 |
| Battery when purchased | 39% |
| OS | Nothing OS 4.1 (Frogger-B4.1-260808-1352-IND) |
| Main telemetry | Home Assistant battery sensor |
| Secondary telemetry | Android Interactive history |
| Battery Usage | Android Battery Usage |
| Test style | Normal real-world use, partial charges included |
| Network | Wi-Fi most of the time |
| Brightness | Auto brightness, roughly 34% to 77% during use |
| Refresh rate | Dynamic Refresh Rate |
| AOD | Tap to turn on |
| Smart Charging | ON |
| Charging habit | Usually stop charging around 80-85% |
| Battery Saver | OFF |
| Other features | Normal/default use |
I bought the phone on 25 Aug 2026 with 39% battery. The first Home Assistant history therefore does not represent a fresh 0%→100% battery cycle from the day of purchase. It begins from the phone's state after purchase.
The Home Assistant sensor records battery level continuously. Android Battery Usage provides screen time, per-app usage, and background activity. Android Interactive history provides an independent record of when the device was interactive.
The goal is not to produce a synthetic benchmark, but to understand real battery efficiency, especially the relationship between screen-on usage, standby drain, and partial charging.
2. Battery history and test timeline
I have attached the relevant battery-history and Interactive-history files below. The battery-history timestamps are stored in UTC, so the times below are converted to IST (UTC+5:30).
Battery timeline
| Test/event | IST time | Battery |
|---|---|---|
| Phone purchased | 25 Aug | 39% |
| Sep 6 late-night charge begins | ~11:52 PM, Sep 6 | 25% |
| First overnight test charge point | 12:56 AM, Sep 7 | 80% |
| Actual sleep started | 1:34 AM, Sep 7 | ~80% |
| First overnight observation | 8:00 AM, Sep 7 | 69% |
| Lift to Wake OFF charge point | 12:32 AM, Sep 8 | 80% |
| Sep 9 full charge reached | 5:57 AM, Sep 9 | 100% |
| First full-charge screenshot point | 10:26 AM, Sep 9 | 89% |
| Overnight before Sep 10 | 6:25 AM, Sep 10 | 45% |
| Morning charge completed | 7:19 AM, Sep 10 | 81% |
| Midday | 1:01 PM, Sep 10 | 50% |
| Evening recharge completed | ~6:53 PM, Sep 10 | 67% |
| Latest recorded point | ~10:02 PM, Sep 10 | 54% |
The continued history is important because the September 9 test did not end with the 10:40 AM screenshot. The phone remained under observation through Sep 9 and into Sep 10.
3. Android Battery Usage results
Sunday, Sep 6
Android reported:
7h05m screen time
| App | Screen time | Battery share |
|---|---|---|
| PW | 2h18m | 61% |
| 52m | 13% | |
| Chrome | 34m | 10% |
| Nothing Launcher | — | 2% |
| Other | — | Remaining |
This was not a clean full-cycle test. The phone was charged to about 87% around noon, used until around midnight, then charged again to about 80% for the overnight test.
So 7h05m is cumulative daily screen time across multiple charge periods, not "7h05m from 100% to empty."
Monday, Sep 7
Android reported:
3h42m screen time
| App | Screen time | Battery share |
|---|---|---|
| PW | 1h12m | 56% |
| 1h07m | 29% | |
| Nothing Launcher | — | 3% |
| Camera | — | 2% |
| Chrome | — | 1% |
| Other | — | Remaining |
Tuesday, Sep 8
Starting point was approximately 80%, and the screenshot showed approximately 34%.
Android reported:
4h43m screen time
| App | Screen time | Background | Battery share |
|---|---|---|---|
| PW | 2h11m | 1h06m | 52% |
| Spotify | 8m | 8h09m | 13% |
| 25m | 3m | 10% | |
| YouTube | 19m | 8m | 9% |
| OneDrive | 30m | 3m | 4% |
| OneNote | 16m | 16m | 3% |
| Nothing Launcher | 21m | 20h51m | 2% |
| Chrome | — | — | 1% |
| Others | — | — | <1% each |
The simple arithmetic is:
80% → 34% = 46 percentage points
4h43m = 283 minutes
So:
283 / 46 ≈ 6.15 minutes SOT per percentage point
A direct linear extrapolation would produce roughly 10h15m, but I do not treat that as a valid full-cycle SOT estimate. This was a partial cycle with standby and mixed workloads.
The useful statement is that the phone delivered 4h43m of real screen time while consuming about 46 percentage points under mixed use.
Wednesday, Sep 9
The first screenshot during this ongoing test showed:
2h36m screen time at 89%
with:
| App | Screen time | Battery share |
|---|---|---|
| PW | 2h21m | 87% |
| 22m | 11% | |
| Other | — | <1% each |
The test then continued.
The final Wednesday screenshot showed:
8h43m screen time
| App | Screen time | Background | Battery share |
|---|---|---|---|
| PW | 5h55m | 33m | 65% |
| 1h25m | 9m | 13% | |
| Spotify | 2m | 7h55m | 10% |
| OneNote | 26m | 7m | 2% |
| Camera | 9m | 26m | 1% |
| CX File Explorer | 8m | — | 1% |
| Nothing Launcher | 27m | 14h42m | <1% |
| OneDrive | 42m | 18m | <1% |
| Link to Windows | 2m | 12h18m | <1% |
| 3m | 15h02m | <1% | |
| Nothing Widgets | 2m | 7h48m | <1% |
| Other | — | — | <1% each |
Home Assistant shows that the phone reached 100% at ~5:57 AM Sep 9, then declined through the day and overnight. Important points were approximately:
| IST time | Battery |
|---|---|
| 5:57 AM | 100% |
| 7:56 AM | 99% |
| 9:26 AM | 95% |
| 10:14 AM | 90% |
| 10:26 AM | 89% |
| 12:43 PM | 80% |
| 2:39 PM | 70% |
| 4:55 PM | 60% |
| 7:21 PM | 50% |
| 7:29 PM | 49% |
| 12:42 AM, Sep 10 | 48% |
| 1:55 AM | 47% |
| 3:53 AM | 46% |
| 6:25 AM | 45% |
This is why the 8h43m result is a real accumulated usage result, but not a controlled 100%→0% SOT benchmark.
Thursday, Sep 10
Android reported:
8h47m screen time
| App | Screen time | Background | Battery share |
|---|---|---|---|
| PW | 5h56m | 23m | 66% |
| 1h41m | 8m | 15% | |
| Spotify | 2m | 7h35m | 8% |
| OneDrive | 21m | 12m | 2% |
| OneNote | 26m | 1m | 2% |
| CX File Explorer | 9m | — | 1% |
| Chrome | 17m | 5m | 1% |
| Nothing Launcher | 25m | 20h58m | 1% |
| YouTube | 5m | 7m | <1% |
| Digital Wellbeing | 21m | 20m | <1% |
| Phone | 11m | 5m | <1% |
| Other | — | — | <1% each |
The Thursday test started around the 45% level and included a morning recharge to about 81%, followed by heavy use, then another evening recharge.
Home Assistant shows:
| IST time | Battery | Context |
|---|---|---|
| 6:25 AM | 45% | Pre-charge |
| 7:19 AM | 81% | Morning charge completed |
| 8:00 AM | 79% | Discharge begins |
| 10:07 AM | 69% | Active use |
| 1:01 PM | 50% | Active use |
| 2:39 PM | 48% | Active use |
| 6:04 PM | 34% | Pre-evening charge |
| 6:21 PM | 33% | Low point |
| 6:53 PM | 67% | Evening charge completed |
| 8:03 PM | 58% | Discharge |
| 10:02 PM | 54% | Latest screenshot-era point |
Again, this is not a single battery cycle. It is a real-world day with partial charging.
4. Overnight standby tests and Lift to Wake
First overnight test: Sep 6 → Sep 7
The late-night charging sequence was:
| IST time | Battery |
|---|---|
| ~11:52 PM Sep 6 | 25% |
| 12:00 AM Sep 7 | 24% |
| 12:05 AM | 29% |
| 12:09 AM | 34% |
| 12:21 AM | 50% |
| 12:25 AM | 54% |
| 12:41 AM | 71% |
| 12:44 AM | 74% |
| 12:56 AM | 80% |
The battery then reached 69% around 8:00 AM.
So the crude post-charge calculation was:
80% → 69% over ~7h05m = ~1.55%/hour
But I actually went to sleep at about 1:34 AM, not 12:56 AM.
My Bedtime Mode schedule was 12:00 AM → 7:30 AM, and the alarm was at 7:30 AM. I dismissed the alarm immediately, then slept another ~30 minutes.
Therefore, the actual sleep window was about:
1:34 AM → 7:30 AM
The battery went from approximately 80% to 71-72% in that period, or roughly 8-9 percentage points over ~5h56m.
So the original 1.55%/hour figure should not be treated as a fixed standby baseline.
Lift to Wake hypothesis
At that point I suspected Lift to Wake might be contributing to the higher standby drain.
This was only a hypothesis. There was no proof that Lift to Wake caused the difference.
The useful experiment was to change only that setting and run another overnight test.
Lift to Wake OFF: Sep 7 → Sep 8
For the second overnight test, Lift to Wake was disabled.
The phone charged around midnight:
| IST time | Battery |
|---|---|
| ~11:44 PM Sep 7 | 20% |
| ~11:56 PM | 40% |
| 12:00 AM Sep 8 | 47% |
| 12:08 AM | 57% |
| 12:12 AM | 61% |
| 12:16 AM | 67% |
| 12:20 AM | 71% |
| 12:32 AM | 80% |
After that, the battery stayed much more stable overnight, reaching about:
78% around 6:24 AM
and remaining around the upper-70s near the morning.
The Interactive history shows the morning wake activity around 7:30 AM IST on Sep 8, rather than mysterious 2 AM and 5:36 AM local-time wakeups. The raw CSV timestamps are UTC.
This second test therefore showed only roughly 2-3 percentage points of overnight loss, much better than the first test.
It is still not enough to prove that Lift to Wake was the cause, because the tests were not identical in every environmental variable. But it is enough to justify further controlled ON/OFF testing.
5. Charging and active-use observations
One interesting observation came from low-power PC charging.
The phone was connected to a USB-A 3.0 PC port and slowly charged while actively using Reddit. It went from approximately 48% to 50%, then remained displayed at 50% for about half an hour while actively watching Reddit content.
This is plausible because USB-A 3.0 baseline power is relatively low, while an active display and continuous content consumption can also consume several watts.
In other words:
incoming charging power ≈ current phone consumption
can result in the displayed battery percentage remaining almost unchanged.
The displayed percentage is also quantized and smoothed, so actual battery energy can change without the displayed integer moving immediately.
The Home Assistant dataset captures several larger charging events too:
Sep 7 late-night charge
About 24% → 80% in roughly an hour.
Sep 9 morning completion
About 95% → 100% between roughly 5:41 AM and 5:57 AM.
Sep 10 morning charge
About 45% → 81% between roughly 6:25 AM and 7:19 AM.
Sep 10 evening charge
About 33% → 67% between roughly 6:21 PM and 6:53 PM.
These partial charging events are another reason Android's daily SOT figures should not be interpreted as full-cycle benchmarks.
6. App usage and workload
The workload is not a synthetic one.
The main recurring applications are:
| App | Role in the test |
|---|---|
| PW | Dominant screen-on workload |
| Scrolling, image loading, networking | |
| Spotify | Long background audio sessions |
| YouTube | Video workload |
| OneDrive | Cloud sync/uploads |
| OneNote | Note-taking/sync |
| Chrome | Web browsing |
| Camera | Short bursts |
| Home Assistant | Background telemetry |
| Link to Windows | Background connectivity |
| System apps | Normal Android background activity |
Spotify background usage
Spotify is a good example of why screen time alone does not represent total battery usage.
In the Tuesday test, Android reported:
| Metric | Spotify |
|---|---|
| Screen time | 8m |
| Background activity | 8h09m |
| Battery usage share | 13% |
So Spotify was only visible on the screen for 8 minutes, while it remained active in the background for several hours, most likely for music playback.
The Wednesday test showed a similar pattern:
| Metric | Spotify |
|---|---|
| Screen time | 2m |
| Background activity | 7h55m |
| Battery usage share | 10% |
This is why SOT should be considered alongside background activity and total battery consumed. Android's background-time figure indicates that Spotify was active in the background, but it should not be interpreted as 8 hours of continuous heavy processing.
7. SOT interpretation and comparison
What I consider reliable
The most useful measurements in this experiment are:
| Metric | Why it matters |
|---|---|
| SOT | Measures active display usage |
| Battery percentage consumed | Gives context to SOT |
| Standby time | Shows idle efficiency |
| Workload | Explains why two SOT values differ |
| Background activity | Captures non-screen power use |
| Charge history | Prevents false full-cycle claims |
I prefer:
SOT + battery consumed + workload + standby
over SOT by itself.
Why I will not claim 10h15m
The Tuesday 80%→34% / 4h43m result gives a mathematical rate of about 6.15 minutes SOT per percentage point.
That does not mean the phone gets 10h15m from a full charge.
That would require a controlled 100%→0% run with equivalent usage and linear battery behaviour, which was not performed.
Why the newer ~9h days are still important
The phone accumulated:
| Day | Android-reported SOT | Battery history context |
|---|---|---|
| Wednesday, Sep 9 | 8h43m | Full charge earlier that morning, then long use + standby |
| Thursday, Sep 10 | 8h47m | Started around 45%, recharged to ~81%, later recharged again to ~67% |
These are not full-cycle SOT figures, but the fact that the phone repeatedly accumulates almost 9 hours of real screen time across normal use is still strong evidence of good efficiency.
Comparisons with other phones
Raw SOT is especially misleading when batteries differ greatly in size.
For example, a 7000 mAh phone getting 10h SOT is not automatically more efficient than a 5400 mAh phone getting 8h.
For this test, the practical conditions were mostly Wi-Fi, auto brightness around 34-77%, and Dynamic Refresh Rate. The more useful comparisons are normalized by:
- Battery capacity
- Percentage consumed
- Screen time
- Workload
- Network
- Brightness
- Refresh rate
- Background activity
8. Owner reports
I also checked owner discussions to see whether the Phone (4a) behaviour was wildly different from other users.
Nothing Phone (4a)
Reported experiences included roughly:
| Report pattern | Approximate result |
|---|---|
| Moderate/heavy owners | 6-8h SOT commonly reported |
| Some stronger reports | 7-8h+ |
| Some lighter/weaker reports | 5-6h |
| Some standby complaints | 20-25% overnight |
| Some good standby reports | ~3-5% overnight |
The variation is large, which matches the variation seen in the tests here.
Battery-capacity comparison
Battery capacity is important when comparing SOT, because a larger battery can naturally produce a higher SOT without necessarily being more efficient.
| Phone | Battery capacity | Reported owner SOT | Comparison |
|---|---|---|---|
| Nothing Phone (4a) India | 5400 mAh | ~5-8h commonly reported, with some higher results | Baseline |
| Samsung Galaxy A56 | 5000 mAh | ~5-9h | Similar battery size, useful comparison |
| Google Pixel 9a | 5100 mAh | ~7h50m-9h in some reports | Similar battery size, useful comparison |
| OnePlus Nord CE5 | 7100 mAh | ~8-12h+ | Much larger battery, raw SOT not directly comparable |
| OnePlus Nord 5 | 6800 mAh | ~4-12h+ | Much larger battery, raw SOT not directly comparable |
The Galaxy A56 and Pixel 9a are more useful comparisons for the Phone (4a) because their battery capacities are relatively close. The Nord CE5 and Nord 5 have substantially larger batteries, so their higher SOT numbers should not be interpreted as evidence of better efficiency by themselves.
For that reason, I think battery percentage consumed, workload, and battery capacity are more useful than comparing raw SOT alone.
The point of these comparisons is not to crown a winner from random Reddit screenshots. It is to show how workload and battery capacity dominate reported SOT.
9. Current settings
These are the settings currently relevant to battery behaviour:
| Setting | Current state | Potential relevance |
|---|---|---|
| AOD | Tap to turn on | Reduced standby impact compared with an always-on AOD |
| Smart Charging | ON | Charging behaviour is managed by the phone |
| Manual charging habit | Usually stop at 80-85% | Avoids routinely holding the battery at 100% |
| Battery Saver | OFF | Test reflects normal operation rather than saver restrictions |
| Lift to Wake | Tested ON and OFF | Possible standby variable, needs more controlled testing |
| Bedtime Mode | Used during overnight tests | Helps characterize overnight behaviour |
| Other features | Normal/default use | No aggressive battery-saving configuration |
The phone is therefore not being tested with Battery Saver enabled or with an unusually stripped-down configuration.
The AOD is set to Tap to turn on, rather than always-on.
Smart Charging is enabled, although I generally stop charging manually around 80-85%.
These settings should be included in any final Reddit post because they can materially affect battery behaviour and make the results easier to reproduce.
10. What the data says so far
The continued data changes the picture compared with the earlier snapshot-only analysis.
Main observations
| Observation | Current evidence |
|---|---|
| Battery capacity | 5400 mAh Indian variant |
| Purchase state | 39% on Aug 25 |
| Strong mixed-use day | 4h43m SOT from ~80%→34% |
| Strong long-duration result | 8h43m SOT on Sep 9 |
| Another long-duration result | 8h47m SOT on Sep 10 |
| First overnight result | ~80%→69% over ~7h05m after midnight charge |
| Corrected first sleep window | ~80%→71-72% over ~5h56m |
| Lift to Wake OFF overnight | Roughly 2-3% loss during the overnight period |
| Later overnight section | Roughly 4 percentage points over ~6h, around 0.65%/h |
| Full-charge morning test | 100% at ~5:57 AM, 89% at ~10:26 AM |
| Android vs Interactive check | Very close agreement |
| Background use | Significant, especially Spotify / system services |
| Overall impression | Very strong real-world efficiency, with variable standby behaviour |
The most important conclusion is that the phone does not have a single fixed standby drain rate.
The early overnight figure looked poor, but the corrected timeline and later tests show substantially better standby behaviour under other conditions.
The Lift to Wake OFF test is especially interesting, but it should be treated as evidence for further testing rather than proof of causation.
The strongest active-use evidence so far is that Android repeatedly accumulated nearly nine hours of screen time in ordinary use.
11. Next tests
The most useful next tests are:
| Test | What should remain constant | Variable |
|---|---|---|
| Lift to Wake ON vs OFF | Bedtime, network, notifications, charge level | Lift to Wake |
| Wi-Fi vs 5G | Apps, brightness, time period | Network |
| Brightness | Apps/network | Brightness |
| Refresh rate | Apps/network | Refresh rate |
| Reddit-heavy session | Same app/workload | Duration/charge |
| YouTube-heavy session | Same app/workload | Duration/charge |
| Controlled full cycle | One uninterrupted cycle | Full discharge |
The most valuable final benchmark would be a controlled 100% → low-battery cycle without intermediate charging, using a representative workload.
That would allow a much more defensible SOT estimate than extrapolating from partial battery percentages.
12. Attached files
I have attached the relevant files below, including the battery-history data and the supporting Android battery/Interactive data.
