Logging coordinates with a frequency EVERY 10 seconds is probably the main issue of why your phone overheats. Do you really need to sample that often? Consider the precision of the GPS hardware (the GPS receiver is probably overheating) and the ability of your phone to accurately post your user's position.
You have certainly read how your LocationSensor works and about Accuracy and precision of measurements. The device isn't always where it thinks it is. Asking for a distance of 5 meters in code does not guarantee the device WILL actually post at that interval.
I set the GPS logging interval to 10 seconds to help verify whether a surveyor thoroughly covered their assigned area—similar to what’s shown in the attached image below. The green lines represent the tracking path, while the red dots indicate the locations of surveyed diseases.
I'm having an issue with Motorola devices (I tested it on a Moto e22).
The same blocks work perfectly for Xiaomi devices.
The problem: Location doesn't update in the background
Notification appears: Yes
Permissions granted: Yes
iToo notification appears: Yes
No visible difference, just doesn't update.
Blocks:
I had a similar problem when following the extension's block example.
When you register an event each time the OnLocationChanged block is triggered, this accumulates receivers, probably because RegisterBroadcast or similar is called.
Did you try my example project locationservice. aia from the download folder? Does it work there?
What is the Android version for the Motorola device?
EDIT
The errors from the log are completely unrelated to the locationservice extension
You might want to add Notifier.Loginfo blocks into your code for debugging
I asked Gemini about advice. Below is the answer
Taifun
This is a very common issue in Android development, where code that works on one manufacturer's device fails on another. The core reason is that different manufacturers, like Motorola and Xiaomi, implement their own power-saving and background task management features on top of the standard Android OS. These features are often aggressive and can interfere with background processes, including location services.
Here's a breakdown of the special considerations for Motorola devices and why you might be seeing a difference from Xiaomi.
Aggressive Battery Optimization and Power Saving
Motorola devices are known to have strict battery optimization features. While Xiaomi also has its own version of this, the implementation and defaults can differ.
Adaptive Battery: This standard Android feature learns your usage patterns and limits battery consumption for apps you don't use often. Motorola's implementation might be more aggressive, classifying your app as "unused" and preventing it from getting frequent location updates in the background.
"Unrestricted" Battery Usage: To fix this, users often need to manually go into the app's settings and change its battery usage to "Unrestricted." This setting is often hidden behind an extra tap on the "App battery usage" toggle. The path is typically: Settings > Apps > Your App > App battery usage > Unrestricted.
https://dontkillmyapp.com and Manufacturer-Specific Quirks
The website https://dontkillmyapp.com is a well-known resource that documents these manufacturer-specific behaviors. It highlights that Motorola, along with other brands, can have non-standard background process limitations that are not always documented.
Background Process Management: The OS on Motorola devices may terminate background services and processes more quickly than on other phones, especially if the phone's power-saving mode is enabled or if the battery is low.
Data Saver Mode: The "Data Saver" feature on some Motorola devices can also be configured to limit background data usage, which can affect location services that need to report data to a server.
Permission Differences (Android 10 and higher)
While this is a standard Android consideration, the user experience for granting permissions can vary.
Background Location Permission: On Android 10 and higher, you must explicitly request the ACCESS_BACKGROUND_LOCATION permission in addition to ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION.
User Dialogue: The way the permission dialog is presented and the options available to the user can vary. Some manufacturers may make it less obvious how to grant "Allow all the time" permission, which is necessary for background location. Users might have to go to a separate settings page to enable this.
What to Check and How to Fix It
Check for Permissions: Double-check that your app is properly requesting and handling all necessary location permissions, especially ACCESS_BACKGROUND_LOCATION on devices running Android 10+.
Educate the User: Prompt the user to grant the necessary "Allow all the time" permission for location access. It's often helpful to provide a clear explanation of why the permission is needed and a direct link to the app's settings where they can change it.
Check Power Saving Settings: On the Motorola device, manually go into Settings > Apps > Your App > Battery and set the battery usage to "Unrestricted." This is a good way to test if battery optimization is the root cause of the problem.
Review Manufacturer Documentation (if available): While less common for consumer-facing documentation, sometimes a deep dive into developer forums or specific device model behavior can reveal unique quirks.
In the original itoo thread there are several examples with register an event continuously... let's ask @Kumaraswamy about his opinion on that.
I agree that the better solution is to register an event only once and if you use itoo then this should be done in the main procedure as you have shown it.
The locationservice extension up to now does not have a main event which gets triggered after starting the service, I will check if I can implement something like this.
Can you elaborate on that? For example: How long do you keep the background process running, This error occurred after many hours? This happened with the original MySQL background example project or did you additionally add other blocks in the event handler?
Hi, in an ideal scenario, the register event block is only called once.
There's even a better way, that is to not use the Register Event block at all! You need to just create a procedure with the following convention: ComponentName_ComponentEvent e.g. Web1_GotText with correct number of arguments, and it'd be automatically registered.
I'm not sure how this error correlates to event registration process, this has something to do with message communication between Itoo Service and the UI.
Why this alert log? I'm not defining anything from the assets:
08-15 19:32:43.794 W/TaifunLocationService( 8915): None does not exist in the assets
08-15 19:32:53.795 W/TaifunLocationService( 8915): None does not exist in the assets
08-15 19:33:03.769 W/TaifunLocationService( 8915): None does not exist in the assets
08-15 19:33:13.818 W/TaifunLocationService( 8915): None does not exist in the assets
)