Active Android Thread

I wish to establish a data logger using an Android phone. While I have the code to capture and record the data I am challenged by the smarts within the phone.

The threads and GPS location detectors are turned off by the operating system to preserve batteries.

Clearly some apps are able to run 24/7 in some form but I would like assurance that one can be built using Delphi.

I have been looking at Delphi Demos of Android services, permissions (Wake_Lock), and window flags all of which are very interesting but also mind bending. The help in Delphi tends to refer directly the the Android platform documentation as soon as you want details.

I have a simple Thread Execute which clearly is not sensible but which demonstrates the issue and will prove a solution.

procedure TRecordThread.Execute;
Const
  WtimeMilliSec=1000;
Var
  ThisTime:TDateTime;
begin
  if Terminated then  Exit;
  ThisTime:=Now;
  while Not Terminated do
   begin
     Sleep(WtimeMilliSec);
     ThisTime:=ThisTime+WtimeMilliSec/(60*60*24*1000);
     if FDm<>nil then
       FDm.SomeText:=FormatDateTime('dd hh:nn:ss ',Now)+ ' ['+
         FormatDateTime('dd hh:nn:ss]',ThisTime);
   end;
end;

Ideally the local time will be maintained close to the Android time for the duration of the app.

In practice, once the application looses focus or the phone is put in a pocket or left untouched for a while, ThisTime stops updating.

Any knowledge on which areas I should pursue is welcome.

The following reference may help:-

See the book ‘Delphi Programming Projects’ by William Duarte,
Chapter 3 ‘Cross-Platform Services for Windows, iOS, and Android’, pp46-76.

This book was published by Packt in May 2019.

I have a demo that is able to monitor location changes 24/7 (with possible reduced frequency determined by Androids imposed limits):

Were you wanting to monitor those, or was it something else?

What is the purpose of the time calculation?

Thanks Peter food for thought - lots more demos there.

The time calculation just tests what states put the thread to sleep. My aim is to make use of the sensors in old mobile phones, mostly an academic exercise. My initial app goes to sleep and misses samples unless you keep touching the screen. 30 minutes is the longest I could set to let it run.

Your Kastri discussion at the symposium got me fired up again and I thought Geofence would provide some insights. I also looked at service apps in the Delphi demos (mostly NotificationApp and ForegroundLocationTrackingService). I am progressing slowly building my own service and using the test thread to monitor sleep states. I did get AGDemo working and added my own locations. My recent play indicated that the AGDemo works when the app does not have focus but does not fire if the phone has gone to sleep and does not hold off the sleep state leading me to question whether I was seeking the impossible. Your CrossPlatformLocation seems to do the trick. now I just need to understand it. Thanks

Thanks for the heads up. I’ll see if I can modify it to take account of this.

Do you mean the display turning off, or “doze” mode? I assume it’s doze, which I’ll also look into.

I do not know the difference between “doze” and “display off”. I have a local car park programmed into the app and received the “arrive” and “depart” messages when we parked and went for a walk. As my screen is set for 30mins before closing I actively turned the screen off before returning to pick up the car. When I got home and opened the app I got an “arrived home” entry but no reference to going through the car park zone.

I then left the app running on and noted that the screen went blank probably after 30 minutes so I suppose that was a “display off”

OK… That’s screen lock. “Doze” is when the device has been asleep for an extended period of time. Thanks again, and I’ll look into it.

1 Like

Since this is just an academic exercise, have you tried turning on the option for keeping the screen on whilst on charge within the Android debugger options on the phone? If you just plug in a portable charger, that might solve your problem for this use case at least.

That was my fall back plan but with all the help I now have I hope to make it work without that.

1 Like