I already tried your sample project. No error displays.
Yes, the phone has enough storage.
I am using Doogee S96 GT, a rugged phone. Android version is 12.
Other devices did not experience the same thing. Based on my observation, the error displays when the phone is too hot and the phone is in idle for a few minutes.
I manually stop the app during break time and resume after break time. To fix the error, I manually restart the phone. Is there any other way to stop the error from displaying?
I checked the phone, battery saver option was disabled. I am really confuse what might be the cause of the error. Is it the app itself or the phone since it only happens when the battery is too hot and the app is in idle mode for few minutes.
Unfortunately, I don't have a power bank, and I'm not planning to buy one just for this app — but I appreciate your suggestion. I'll try this approach if it solves the problem.
It's frustrating when a rugged phone, designed for durability, still succumbs to overheating issues! Your observations about the Doogee S96 GT, Android 12, and the app crashing when hot and idle are key. This strongly suggests a thermal throttling issue, where the phone's system automatically reduces performance (or even shuts down apps) to prevent damage from excessive heat.
Since other devices don't experience this, it points to either a specific characteristic of your Doogee S96 GT or how the app interacts with its hardware and thermal management.
Here's a breakdown of potential causes and ways to address this, without manually restarting the phone every time:
Processor (SoC) Type: Doogee phones often use MediaTek processors. Some MediaTek chips, especially in rugged devices that may not have as robust cooling as flagship phones, are known to be more prone to overheating under sustained load.
App Intensive Usage: Running an app for 8 hours a day is a significant workload. Even if it seems "idle" to you, it might be performing background tasks, calculations, network requests, or maintaining an active connection that keeps the CPU and GPU working.
Heat Dissipation: While rugged phones are durable, their thick casings and protective layers can sometimes trap heat, making dissipation less efficient than on slimmer, more ventilated phones.
Battery Degradation (Less likely if new, but possible): An aging or faulty battery can generate more heat during operation.
Software Glitch/Optimization: There might be an issue with how Android 12 or the Doogee firmware handles thermal management, or the app itself might not be optimized for sustained operation on this particular hardware.
Ways to Mitigate and Potentially Stop the Error:
Optimize the App (If you have control over the app):
Reduce Background Activity: If the app is doing heavy processing in the background when "idle," can this be reduced?
Polling intervals: Can data refresh rates be extended?
Unnecessary computations: Are there parts of the app that are constantly calculating even when not actively used?
Network activity: Can network calls be batched or reduced when idle?
Graphics and Animations: If the app has complex UI or animations running even when "idle," simplify them. Lowering frame rates or using less resource-intensive rendering can help.
Resource Management: Ensure the app properly releases resources (like network connections, GPS, camera) when they are not actively needed.
Memory Leaks: Long-running apps can sometimes suffer from memory leaks, where memory is allocated but never released, leading to increased resource usage and heat. This would require proper debugging by the app developer.
Developer Tools: If you are the app developer, use Android Profiler in Android Studio to monitor CPU, memory, and network usage over extended periods to identify bottlenecks.
Optimize Phone Usage and Environment:
Remove the Phone Case (Temporarily for testing): If you're using an additional protective case on top of the phone's rugged design, it might be trapping heat. Try running the app for a period without any extra case to see if it helps.
Improve Airflow:
Ensure the phone isn't placed on soft surfaces (like blankets or pillows) that can block vents or trap heat.
If possible, place the phone in an upright position or on a stand that allows air to circulate around it.
Avoid direct sunlight or hot environments while the app is running.
Reduce Screen Brightness: A brighter screen consumes more power and generates more heat.
Close Unnecessary Background Apps: Even if your main app is in focus, other background apps can consume resources and contribute to overall heat. Regularly clear recent apps.
Disable Unused Features: Turn off Wi-Fi, Bluetooth, GPS, NFC, etc., if they are not actively needed by the app or for phone functionality.
Use Battery Saver Mode: While this might slightly impact performance, it can help reduce CPU/GPU activity and thus heat generation.
Avoid Charging While Using Heavily: Charging a phone generates heat. If you're running a demanding app while charging, it significantly increases the thermal load. Try to charge the phone when the app isn't running, or during periods of low usage.
Software Solutions on the Phone:
Update Firmware/Android: Check for any available system updates for your Doogee S96 GT. Doogee might release updates that improve thermal management or optimize performance for Android 12.
Go to Settings > System > System update.
Clear App Cache and Data: For the specific app that's crashing:
Go to Settings > Apps > See all apps > Find your app.
Tap Storage & cache > Clear cache. If the problem persists, try Clear storage (be aware this will delete all app data, so back up anything important first).
Reinstall the App: Sometimes a fresh installation can resolve corrupt data or installation issues.
Factory Reset (Last Resort): If none of the above works and you suspect a deeper software issue, a factory reset might help, but it will erase all your data. Back up everything first!
External Cooling (Workaround, not a fix):
Cooling Fan/Pad: For very specific, stationary use cases, you could consider placing the phone on a small USB-powered cooling fan or a specialized phone cooling pad. This is more of a band-aid than a permanent solution to the underlying thermal issue, but it might keep the app running.
Thermal Paste (Advanced, Risky): This is highly discouraged for the average user. Some advanced users might consider replacing the thermal paste on the phone's CPU. This involves disassembling the phone and carries a high risk of damaging the device and voiding the warranty. It's generally only for experienced technicians.
Why restarting helps:
When you restart the phone, you clear all active processes, reset the operating system, and allow the hardware to cool down completely. This temporarily resolves the overheating state and resets any thermal throttling measures that were in place.
Given that your Doogee S96 GT is a rugged phone, its design priorities are protection over ultimate thermal efficiency in prolonged, high-load scenarios. Addressing the root cause (app resource usage and phone cooling) is the best long-term strategy.
I'd like to provide some details about the app. It is configured to store GPS coordinates every 10 seconds, with a distance interval of 5 meters. These settings were chosen to track the walking pattern of surveyors in the farm. The app works entirely offline, with no use of mobile data or network during the tracking activity.
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
)