Testing connection with a wearable

Sleep tracking with Wear OS device requires a companion app installed from the Play Store on the watch.

How to get there:

For all currently supported devices, check out list of compatible devices.

If you’d like us to integrate another device, please add it as a suggestion to our suggestion forum. Also please check whether the device has an API so we can integrate it.

​The Sleep Duration is total sum of all your sleep phases (Light, REM, and Deep), not counting the awake phases - because when awake, you are actually not sleeping.
​So on default settings, the Sleep duration is always a bit shorter than the duration of tracking.

​If you wish your Sleep duration is the same as tracking duration:

If nothing helps please send us a debug report using Left ☰ menu → Support → Report a bug..

We use a different input than polysomnographists, and define our own sleep phases, reflecting an objective aspect of sleep, easy to measure with common devices. One naturally needs to ask whether there is any relationship between the EEG-phases and our ACT-phases.

Fortunately, several research teams raised similar questions before (See this one, or this one, or this one, or this one). They measured a bunch of people on a traditional polysomnograph and recorded their physical activity at the same time (By filming them and then counting the movements manually, or by using accelerometer readings). The published analyses show that there indeed is a significant statistical relationship between EEG-phases and body movements.

You can also read about comparison of Sleep as Android algorithms and Sleep lab results on our blog here.

Battery saving mode currently resumes full tracking before the smart wake up period in order to find the best moment for your wake up, so the tracking uses up just a fraction of the battery consumption for the whole night. If the battery would drop under your defined stand-by threshold (default: 10%) the battery saving mode will re-occur.

Accelerometric sensors are really sensitive, which is great for sleep tracking. Normally, what you see when you leave the phone on the table gets immediately dwarfed when you do some more significant move. Just leave phone on the table for a while and you will see a dramatic development, but then move the phone and you will see all the development is really tiny in comparison to the new peak.

So what you see is random noise, given by very small vibrations of the table or in very calm areas by seismic movement. We mark the data relatively, so you always get it distinguished into light and deep sleep. But the algorithm works well only in conditions that are assumed by it, i.e. in the bed with relatively large movement peaks.
To be more specific, if you leave the phone on a table, you can get values perhaps on the scale of 0.000001 to 0.000009 m/s2 (The value is made up here, but it is physically very small). In the bed, you may get values from 1 to 9 m/s2 (which is physically large). The algorithm sees though just that the high value is 9 times higher than the low value, in both cases.
We had to do this because every accelerometer (in different cell phones) measures differently, so we couldn’t assume any standard conversion formula that would respond to absolute values.

So if you use the phone in the bed, it is in fact drastically different from measuring on a calm spot, just like the table.

Please do not hesitate to ask for any clarification at support@urbandroid.org. You can also read more about comparison of our data with the sleep lab results in this post.

This depends on several factors. The general rule is to not allow the pet to move your phone, ideally only your movements should move the device. So in this case it’s best to place Your device either under the pillow or to have an armband or smartwatch/smartband. If your pet is a calm one, it may just work. However, if your pet is used to jump in and out of bed several times a night, the sleep tracking will most probably register these events as light sleep occurrences.

Ultrasound is generally considered safe if it is at normal volume. Regarding health effects, it works in a similar way to normal audible sound, i.e. very loud ultrasound can damage your hearing, whereas at low volume it is safe to hear. When using speakers, smartphones are nowhere close to be able to produce such loud sounds as to damage your hearing.
We also use ultrasound that is very close to the hearing range (around 20 kHz), so the effects of the ultrasound are almost identical to hearing a high pitched sound at the same volume (expect you can’t hear it at all).
The ultrasound volume we use is around 40 dB – which is lower than normal speech volume. You can measure the sound level yourself using e.g. this app.

For pets that are able to hear it, the ultrasound emitted from Sleep as Android is a constant low noise. The situation is similar to e.g. refrigerator noise. It is there, you can hear it, but it’s not so much disturbing. The ultrasound definitely cannot damage your pets hearing at the volume used in Sleep as Android.
Bats can be confused and fly into walls.

The only difference between normal audible sound and our sonar is that the frequency is a little higher (normal frequencies 2 Hz-20 kHz, our sonar frequencies 18 kHz-22 kHz). This is so small difference for the mic and speaker membranes that there is definitely no chance of damage, even with prolonged usage.

On Wear OS platform and ONE UI Watch (Galaxy Watch 4 + 5), we use gentle vibrations for even more natural wake up.
It starts with a single vibe, another in 30s, than again in 20s and so on. After few minutes the vibrations will be continuous.

If you are worried this won’t be enough, you can set a delayed start of alarm sound on the phone. And there is always the backup alarm.

Usually this is not caused by the sleep tracking directly as this is usually not consuming too much resources (usually around 1-3% battery per hour of tracking).
The issue appears because we hold a wake lock (keeping the phone awake) – any badly written apps may access the CPU extensively during the sleep tracking time. We suggest checking which services are running before you get to sleep.
For us it is hard to debug this. Also battery statistics are not a hint here as all battery consumption is accounted to the app which holds the lock even it did not consume the battery – this is by design in Android.

To conclude, this issue may happen, although we did not get any similar reports for a very long time now. But the most probable cause is some wrong 3rd party service or app on your device.

To see more on the issue we would need a debug report (menu > report a bug).

A good test would be to reboot your phone before sleep tracking (or kill any unnecessary services running) and see if that helps.

At first Sleep as Android may look complex with all its options, but in fact it is fairly easy to get started improving your sleep and wake up.
You can delve deep into all the amazing options Sleep as Android provides later on. But to get started just rely on our carefully selected defaults.

This can be a result of multiple things, so please make sure to do the following troubleshooting:

We have reports that on some device you can hear audible artifacts during sonar tracking. It sounds like this:

Some of the signal gets into audible spectrum probably due to either insufficient quality of the speaker or some post processing which is applied to the output on your device firmware.

We have also some reports that Sonar can get audible suddenly during tracking in the night. Unfortunately we are not sure why this could happen, we only have very few such reports and we are not able to reproduce this on our phones.

To make any audible artifacts less likely:

If you get completely flat graphs with automatic tracking with sonar sensor after upgrading to Android 11, make sure the app has permission Draw over other apps, Display over other apps or Appear on top (Samsung).
This permission is necessary for accessing the microphone from the background.

If the tracking stops completely after few minutes, the background processes are restricted by your system.

If your volume gradually lowers after a while, when the tracking is running, the option Turn off when sleeping is enabled. This feature lowers the system-wide volume, so it affects even music played outside Sleep.

Usually battery consumption issue or related issues causing phone over-heating during sleep tracking are not caused by the sleep tracking directly.

In most cases sleep tracking itself is not consuming too much battery (usually around 1-2% per hour of tracking). But because we hold a wake lock (keeping the phone awake) any other usually badly written apps may access the CPU extensively during the sleep tracking time. We would suggest checking which services are running before you get to sleep. For us it is hard to debug this. Also battery statistics are not a hint here as all battery consumption is accounted to the app which holds the wake lock even it did not consume the battery (this is by design in Android).
A good test would be to reboot your phone before sleep tracking (or kill any unnecessary services running) and see if sleep tracking will still consume too much battery afterward. Features within Sleep as Android which may cause higher CPU load during tracking include noise recording. You may try tracking without it for a reference. Also I would strongly recommend to track with airplane mode on.

The red block indicates that something went wrong with tracking at that time and the device stopped providing sensor data for some reason. Usually those are some non-standard battery optimizations or battery savers, the battery gets too low so we preserve it for the alarm or connectivity issue if you use a wearable.

Unfortunately due to dummy security restrictions the Android team introduced in 4.2 there is no option to enable airplane mode from an app automatically. You always have to use the settings or long touch power button. If you have a rooted phone you may consider using https://play.google.com/store/apps/details?id=lv.id.dm.airplanemh we have support for that in Sleep. There is a similar hack for 4.3.

If you don’t agree with the Android team design decision you can upvote issue 40497 here http://code.google.com/p/android/issues/detail?id=40497.

There is no clearcut answer to which day the sleep between them belongs.

We have decided to attach the sleep to the day after, because how you slept will largely determine how your day will be.

If you have separate mattresses there is minimum interference from your partner. If you have one big shared mattress (which isn’t recommended as you partner may need different mattress for his healthy sleep), it could still work assuming you keep your phone close to your body and ideally on your side of the bed.

You can also consider using a armbands or smartwatches. This certainly solves the problem for a little convenience trade-off.

If both of you are tracking, you can enable pair tracking, which filters out the partner’s activity.