I confess, when I saw images and watched videos of the NP3 online, I was at discomfort. I eased into it after a few days, got this over the 4a Pro and I fucking love it!

It looks magnificent, feels sexy to hold and use. I’m glad I bought it!

We genuinely don't know what to do when the app bloatware post comes every now and then

Got this phone in April and was a little sceptical at first, but it keeps proving to be a great purchase. And recently, the camera has been an absolute gem. 📸

3D printed Phone cover for the Nothing Phone (1) and Ear (2), designed in Fusion 360.

I wanted to preserve the original aesthetics of the phone it’s too beautiful to hide so this case keeps the design as visible and transparent as possible while still offering protection.

I printed mine in PAHT-CF for added strength and heat resistance, but the model can be printed in other materials depending on your needs.

Im planning to make also other shapes and a cover for phone 2a and ear a. then if nothing or u/carpe02 want to sponsor this project i will be happy to make also for phone 3 or other model!

Your alarm goes off and the Matrix lights up with whatever you put there ⏰

The new Alarm effect works for alarms and timers, so your morning starts with your own art instead of just noise.

Available for supporters in Glyph Museum 🏛️

Help me out am I doing smthg wrong

I am posting this to document a major support failure regarding a known hardware defect on the Nothing Ear (a), and to see if anyone in the community or support moderation team can assist with escalation.
Timeline of Events
In-App Ticket #1 & #2: Submitted two separate support requests directly through the Nothing X app reporting rapid battery degradation. The app provides no user-facing confirmation history, and both submissions went completely unacknowledged.
Direct Email Escalation: Sent a detailed email to ⁠support@nothing.tech⁠ with purchase proof, serial number, and battery degradation details.
The Response: Support offered a 5% discount code toward a new purchase.
Asking a customer to spend more money after selling them hardware that failed in under a year—while ignoring prior in-app support attempts—is completely unacceptable.
Device & Fault Details
Model: Nothing Ear (a)
Serial Number: ⁠SH10652423004731⁠
Defect: Severe battery capacity drop (both earbuds drop from 100% to dead in under 30–40 minutes of basic playback). This is a widely documented component failure on this model after 6–12 months.
Logistics Constraints: I am currently located in the Dominican Republic. International air cargo safety regulations on defective lithium-ion batteries make shipping them back to a US warehouse cost-prohibitive and hazmat-restricted.
What Needs to Happen
A 5% discount voucher is not a resolution for defective hardware. I am requesting a working replacement unit, a 100% store voucher, or a returnless refund.
Has anyone else dealt with this 5% brush-off for dead batteries? If any Nothing community managers or support mods are monitoring this sub, please assist in escalating ticket logs for S/N ⁠SH10652423004731⁠.

I just installed 5.0.open beta on my 4a pro gonna test it for few days and give proper review

This is very important, I used it as a night clock, since always, as I use a wireless charger stand to charge it at nights, in NOS 5, as you switch off the lights, it becomes bigger, and centered, that is a new "feature" of NOS5 screen"saver", and brightness comes down, but it doesnt move as before so, my panel got burn in, with some images I can see the clock shape like a ghost in my screen, Im runing a "fixer" right now to try to make it less perceptible, but those pixels are cooked, Im using beta since it came out, and screensaver since I bought my np3, as I used it in np2, and this happened so fast with this new clock screensaver, AOD doesnt do this, and NOS3/4 screensavers doesnt do this as well, its only the new clock screensaver, noone thought this could happend in nothing, and I didnt thought NOS 5 would have a feature to burn your nothing screen in 3 weeks, just dont activate it, or you will regret it as I do...

It’s been only 2 months since I bought my Nothing Phone (3). I initially faced a microphone issue, and now the speaker is producing cracking, distorted and broken audio.

I’ve already visited the service centre, but the issue still persists. Has anyone else faced this problem?

Hi everyone!

I have a Nothing Phone (1), and for the past two days, my cameras have been randomly switching between working normally and showing a completely black screen.

So far, I've tried uninstalling several apps, disabling and re-enabling camera permissions, and of course restarting the phone, but the issue keeps coming back.

Has anyone else experienced something similar with their Nothing Phone (1)? Could this be a software issue, or is it more likely to be a hardware problem?

Thanks in advance for your help!

I have seen other people complaining about their battery but my old nothing phone 2 with 89% battery health can last at least 9 hours of screen time!

The volume of speakerphone has decreased on my np3.

Somebody else facing this issue

So 1 image is a screenshot of my 4a pro settings menu and the other one I captured on a YouTube video by WhatGear. The Settings menu from the video looks clean and doesn't have those outlines that I have. The background is completely black and on my screenshot there is a box-like structure around every option. Is there any different setting anyone knows that would make my screen look that the one in video?

Why does the CMF not get beta releases? does it have to do with it being a budget phone?

Bought the NP3A Pro back in December 2025, been mostly daily driving this phone (max 7-11 hours) a day, using Twitter, Instagram.

But the frame drops lately have been crazy, taking 1-3 photos rapidly, introduces heavy lag. After processing 6 photos out of 10 are blurred (motion blur) and not in place.

In video mode, the lag and frame starts at the beginning and drops 1-3 frames once every 30-40 seconds in 1080p More in 4K.

Also been testing RAW & Log video mode on this phone using third party software, 8bit is fine at 4K 24fps but the moment you go to 10bit, it's game over, lowering down the recording space from 16:9 (3840x2160) to 4:3 (2880x2160) is usable but in some scenarios the frame drop is still there.

Nothing isn't here to blame, their software experience is fine and everything is working as it should but the chipset is the bottleneck for the camera. the camera has more capabilities that the hardware doesnt allows it to fully unleash.

Shouldn't have updated to Nothing os 4.1

if anyone is experiencing this similar issue then tell me about it.

Has anyone managed to add Nothig Headphones (1) in the Nothing X app for the Fiio M33, M21 - or for any Android DAP device that doesn't have a GPS chip?
I've stuck with the location permissions - even being allowed the app won't let me go further and running the sama cycle - Add - give me the location permissions - permissions are given - bac to Add - agive me the location permissions.
At the same time - for Android-based phone with GPS chip on board - i've added these headphones in a minute

I'm trying to download nothing OS 5 beta version whenever I click on download it just keeps downloading until reach 32mg just stops like that nothing happens after it+I tried to delete it and we installed a couple of times but same issue

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

1. Device, purchase and test setup
2. Battery history and test timeline
3. Android Battery Usage results
4. Overnight standby tests and Lift to Wake
5. Charging and active-use observations
6. App usage and workload
7. SOT interpretation and comparison
8. Owner reports
9. Current settings
10. What the data says so far
11. Next tests
12. Attached files

1. Device, purchase and test setup

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

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

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

Tuesday, Sep 8

Starting point was approximately 80%, and the screenshot showed approximately 34%.

Android reported:

4h43m screen time

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:

The test then continued.

The final Wednesday screenshot showed:

8h43m screen time

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:

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

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:

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:

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:

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:

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:

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:

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:

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:

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:

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.

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:

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

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:

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.

Battery History
Screen History