Q:

FireMonkey Android acceleration sensor high cpu usage

When I try to use the acceleration sensor in Android it causes high CPU usage - even when I try to stop the sensor by code and deactivate it.
I just need to read the acceleration sensor once in my app but it looks like the FireMonkey doesn't respond and can't stop the sensor.
Here is the code:
var
  Sensor: TCustomSensor;
begin
   { attempt to get and activate the sensor manager }
  FSensorManager := TSensorManager.Current;
  FSensorManager.Activate;

  { attempt to get an orientation sensor }
  FSensors := TSensorManager.Current.GetSensorsByCategory(TSensorCategory.Motion);

  FSensor := nil;
  for Sensor in FSensors do
    if TCustomMotionSensor(Sensor).SensorType = TMotionSensorType.Accelerometer3D then
    begin
      FSensor := TCustomMotionSensor(Sensor);
      Break;
    end;

  if not Assigned(FSensor) then
  begin
    Exit; { no orientation sensor is available }
  end;

  { start the sensor if it is not started }
  if not FSensor.Started then
  begin
    FSensor.Start;
    Timer1.Enabled := True;
  end;
end;

I try to stop sensor by:
FSensor.Stop;
FSensorManager.Deactivate;
FSensor.Free;
FSensorManager.Free;

but looks like this doesn't work at all!
Here are screenshots that show the increase in CPU usage:
Before 
After pushing button and activated sensor

A:

The problem is down to what appears to be an oversight in the FireMonkey Android sensor implementation. What happens is this:
When you activate the sensor manager on Android you invoke TAndroidSensorManager.Activate. This tries to instantiate a TCustomSensor descendant for all the known Android sensor types, quickly removing any that are found to not be supported on the current device. This leaves the manager managing a bunch of custom sensor objects, each of which has created a TNativeSensor object with a sensor type enumeration value, as defined in the Androidapi.Sensor unit.
No big deal so far. Each TNativeSensor object constructor has called a couple of NDK routines to set things up: ASensorManager_getDefaultSensor and ASensorManager_createEventQueue. Thus far there is no noticeable impact on the CPU.
Starting the sensor causes the underlying TNativeSensor to call the NDK ASensorEventQueue_enableSensor routine, and this is where the CPU is pummeled.
Stopping the custom sensor object calls ASensorEventQueue_disableSensor, which you might think would cease the CPU usage. However this doesn't actually seem to be the case.
To properly remove the CPU usage from a sensor it seems (just by practical experimentation) that you need to destroy the native sensor event queue, i.e. undo the earlier call to ASensorManager_createEventQueue. However the FireMonkey Android code does not do this. There is no call to ASensorManager_destroyEventQueue present in the code.
What this means is that even if you set all your references to sensors and sensor managers to nil and all those sensor objects, including the internal ones, get destroyed then you still get a CPU hit: ಠ╭╮ಠ
The only way I can get behaviour that seems valid in Delphi 10.1 Berlin (without the Update, currently) is to modify System.Android.Sensors.pas. If you want to do likewise to test this theory out, here are the steps:

In your project make a new folder called RTL
Into this RTL folder copy $(BDS)\source\rtl\common\System.Android.Sensors.pas where $(BDS) is your Delphi installation folder
Add this copied file to your project using the project manager.

Now make these changes to the copied System.Android.Sensors.pas. In TNativeSensor's public section add in a destructor declaration:
destructor Destroy; override;

Implement the destructor:
destructor TNativeSensor.Destroy;
begin
  ASensorManager_destroyEventQueue(FSensorManager, FNativeEventQueue);
  inherited;
end;

Compile and run and the CPU hit should drop off entirely when all your references to the sensor objects are set to nil.

