>Facebook reads the accelerometer all the time. Facebook actually shows a support prompt if a shake event is detected across the app. This could be one reason why Facebook reads accelerometer data.
No. Shake gestures are handled at the OS level and you only get began/changed/ended callbacks. Raw accelerometer data requires the CoreMotion framework, and it’s a lower level API. They are definitely using it for something else.
This is also confirmed by this:
>The prompt has an option to switch this feature off. However, switching it off doesn’t stop the app from reading the accelerometer.
I've heard unreliable and whispered rumors (from the tech grapevine) that the accelerometer was a bot-farm mitigation strategy.
The idea is that a bot farm with thousands of phones on racks won't have some signature that the accelerometer should see when the screen is tapped (for example, when typing a message or hitting a like button).
It's probably being used for multiple purposes, regardless of the original intent. Recall that FB originally collected phone numbers for 2FA, but years later decided to use the information for ad targeting[1]. Not that Facebook is unique in this regard, of course; my own experience at companies which collect various bits and pieces of customer data is that, once the data is in a database somewhere, people are pretty good at finding excuses to use it.
It's been a few years but I do recall adding a framework that claimed to use the accelerometer to help with bot detection. I believe it was PerimeterX.
It uses essentially no battery. IIRC, it uses so little that even when your phone battery runs out and the phone turns off, the accelerometer keeps counting your steps.
That’s what you’d see if the raw accelerometer data was continuously recorded and the actual step math was done in batches on that data possibly along with other computations. If separate hardware was already doing all the math up front it’d make no sense to not pull it once every 10s or something, and there certainly wouldn’t be visible lag between opening the health app and the distance / steps numbers updating
Entire reason to have separate hardware is so that you don't have to wake up the main processor. If you wake up the main processor every 10 seconds you've completely lost the advantage. The idea is if someone's phone is asleep in their pocket you need to wake it up occasionally to check for notifications and so on, but you don't want to be waking it up constantly.
Even if accelerometer data is free, IPC’ing the data to the app consumes a small amount of power. It adds up over time. If it’s not needed, the app shouldn’t subscribe to it.
If apps were worried that phoning home with the data they recorded used significant battery, we might be in a different position in terms of how frequently they do it.
Several such "motion chips" have onboard motion processing. As a random example the MPU-9250[1], a 9-DOF IMU, has a low-power pedometer feature which can keep step count while host processor sleeps or is offline.
Even without onboard processing it's a very obvious move to offload it to a tiny microcontroller. Apple actually started by using a physically separate NXP micro that they branded "M7". Now it is of course on the main chip, but still a separate Cortex-M core.
It can't be that intensive considering Apple's done that parallax homescreen effect since like iOS7. Also when you're in the Safari tab overview, it reads the gyroscope to do a 3D effect where the tabs tilt forwards/backwards. Probably a few other areas I'm not thinking of too.
No. Shake gestures are handled at the OS level and you only get began/changed/ended callbacks. Raw accelerometer data requires the CoreMotion framework, and it’s a lower level API. They are definitely using it for something else.
This is also confirmed by this:
>The prompt has an option to switch this feature off. However, switching it off doesn’t stop the app from reading the accelerometer.