I've recently ported an application that is known to run with uptime of months (DIY Zoning Project) to Android (the accessory driver, the core process and the remote control). And, unfortunately, though techniques to keep running services alive were used (START_STICKY, startForeground()), sometimes the system^H service app just freezes up - until the user initiates an interaction with the service, after which it resumes normal operation. Most problematic is the fact that it is happening intermittently, and mostly after several days of uptime. The remote control works on the emulator for days at a time with no noticeable degradation, so the problem is most probably either in the service or in the accessory driver.
Currently, the system is targeted at API 10, so advanced service scheduling features are not available - that is, if they're related to the problem to begin with.
Now, what is the realistic way to debug and/or profile such a system? Remember, adb is not available for the Android hardware is connected to an ADK accessory.
Quite a late answer, however, did you try to use Wakelocks?
http://developer.android.com/reference/android/os/PowerManager.WakeLock.html
Possibly the system just hibernates the processor in some cases and it seems like "freezing up"
Related
I'm trying to build a limited-functionality Android system for our device, which needs to boot quickly, but everything we do seems to slow it down.
For example, our device has no camera, no bluetooth, no wifi, but turning them off wholesale in various /system/etc/init/*.rc files seems to actually slow it down, due to the interdependencies of Android. The services that are turned off end up restarting, or causing timeouts in Settings, for example.
(Android is on the device for its' UI, not for its connectivity abilities.)
Do you have any suggestions for how to do this? Surely Android for cars, TVs and tablets have had to deal with these issues before.
You did not specify what you did exactly, but if you tried to not start HAL services on startup they might just be started dynamically later. If you are using Android 8 or newer you could merge multiple HALs in one process. But I doubt that this will give you any significant speed-up.
Android does provide a guide on how to optimize boot times: https://source.android.com/devices/tech/perf/boot-times. However, you will notice that they focus on the bootloader, kernel, file system, SELinux, and parallelizing init. The elephant in the room is Zygote. It takes forever to start because it preloads the whole Android SDK.
From its history, Android did not care too much about startup times, because you typically do not restart Android. Instead, they rely on Suspend-to-RAM.
You should think about what you want to have your user experience early. Example: for Automotive Android, Google needs to support a rear-view camera that is available within two seconds after boot. They achieve that by a second, faster stack that provides first images before the application SDK is started and takes over. See https://source.android.com/devices/automotive/camera-hal
I'm developing some Android devices that are constantly performing fairly intensive tasks.
I've noticed a strange issue happen (quite rarely, generally after 2-3 weeks of running continuously) where a device ceases to function, and all communications with it die. Since I don't have any access to these devices I can only assume that the OS has killed all running processes (there are several processes on it that communicate with several different backend servers, and they all disconnect simoultaneously)
I'm currently getting around this by implementing a firmware watchdog (by compiling it from source), but I am trying to figure out what is causing the devices to die in the first place.
Is there some android functionality that kills all processes and requires a reboot to fix? What can i do to avoid this happening? Are there any logs that I can view which show when this occurs?
Don't know what have done to the AOSP, but there do have some mechanisms to make a system reboot.
In init.rc, if a service is note as "critical" then if the service crashes more than 4 times, the system will reboot to the recovery mode.
In framework, if the a service belongs to core service and crashed, the system will restart the whole android, but not the kernel.
Temperature, there are two types temperature reboot schedule. One is CPU heat, but this has nothing to do with android, it is a CPU feature. Another, battery temperature, if a battery's heart is higher than expected, the healthd(a android demon on watching battery state) will notice the framework and the framework will reboot.
If the communication logic is written in a Android App, I suggest you to make this app as persist. This will make sure the app will stay in memory forever, and if the app is crashed, the system will restart this app. This may not solve you problem, but can resume the communication job.
I think it is not hard to figure out what's going on, usually the logcat contains the detail.
One of the explanations of your scenario is that the CPU overheats. In this case, not only the device will spontaneously shut down, it also cannot immediately reboot.
You may find temperature warnings in system log, but you can monitor this in your software, and throttle down CPU-intensive tasks to keep it from overheating.
I'm developing an Android application able to connect to a BLE (Bluetooth low energy) device.
Problem is after connection, when I want to re-connect to an other device, I can't.
The only solution is to off and on phone bluetooth.
(On the iOS app, it works so problems is from Android app).
I get this error :
BLE connection generic error
I there any known bug on Android >=4.0 on BLE connections ?
There are lots of bugs in the bug tracker and the documentation and example are not good.
You have not given enough information to really be able to tell what your specific problem is but the main issue people fall over is thinking that because the api calls are asynchronous you can just use them that way. In practice you need to use them in a synchronous manner e.g. wait for one call to finish before issuing the next. I am not clear if this is by intention of just a buggy implementation but it is the case at the moment.
There are definite issues in the underlying framework / drivers as you can get the system into a state where it want allow Bluetooth to switch off, it want work without switching Bluetooth off and on again, it want work without rebooting your phone, it want work reliably with Wifi enabled. If you go through the bugs list you will find more.
In my opinion it's not at beta standard yet but we have been trying to live with it for the past 9 months and Google look to of stopped working on it as far as I can tell from the updates we have had since the initial release.
I saw a great speech from Commonsware's Mark about multithreading and using wakeful services yesterday at AppsWorld London. He recommends using WakefulIntentService or WakeFulBroadcastReceiver in some situations to ensure your app will be able to continue some long processing and prevent the device to go to sleep.
I have an app that does some background processing regularly when the device screen is off. I use AlarmManager to have it get the stuff done regularly.
Since I have a large user base (200.000 active users), I get to see all kind of weird cases when users send me some logfile. Among others I could see that on some devices after the alarm will be triggered, the app starts doing his job and then suddenly just doesn't do anything for many seconds, or even minutes (no entry in the logfile for a while). I assume this is because the phone goes to sleep.
What bugs me is that this happens only on some devices, for instance it would happen a lot on Samsung SGS2+, but not on SGS2, SGS3 or SGS4.
So what I'm wondering is: what is the policy to decide when to put the phone to sleep? Is it Android deciding or is it lower at the Linux level?
How much tweaking from the manufacturer is allowed? Shouldn't the sleep policy be part of the Android Compatibility definition?
Extra question: Are there some levels of being asleep, like several levels of CPU speed, or is it just boolean sleeping / not sleeping?
what is the policy to decide when to put the phone to sleep?
Generally speaking, if nothing is holding a WakeLock, the device is free to go into "opportunistic suspend" mode, where the CPU stops executing instructions.
Is it Android deciding or is it lower at the Linux level?
The Linux kernel -- via Android extensions originally, now rolled into the stock kernel -- handles opportunistic suspend. Userland apps, like SDK apps, can use WakeLock to block opportunistic suspend..
In terms of how the kernel is configured in terms of opportunistic suspend, I have no idea.
Shouldn't the sleep policy be part of the Android Compatibility definition?
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
Are there some levels of being asleep, like several levels of CPU speed, or is it just boolean sleeping / not sleeping?
From the standpoint of an Android SDK app, and with respect to the CPU, right now, it is "boolean sleeping/not sleeping", as compared to Intel SpeedStep-style CPU frequency changes. Certain multi-core CPUs may turn on and off cores to save power, but this is generally independent from opportunistic suspend.
Every now and then, the radio of my android phone silently dies because of some network related issues.
On the Nexus 4, it shows the empty triangle as if there where no service available in this area. On other phones it does not even do that. It looks like signal is fine.
Anyway, after the radio died silently no phone call / text message / data is going through in any direction.
The only hint I get from the System is the android.net.conn.CONNECTIVITY_CHANGE broadcast fired when the signal dies and wifi is not connected.
The only thing, that fixes the problem is restarting the phone.
Finally my question:
Does anybody know how to restart the radio completely by code?
I mean, it is a separate image running on a separate CPU. There must be a way to reboot it without rebooting the phone.
Maybe there is something, I can path into the Android ROM. I'm running CM here and be happy to patch it (again).
I tried fixing it by launching a system app by pressing *#*#4636#*#* on the dailer and stopping the radio and starting it again. But it did not help at all.
I recently made an app that checks the radio every time the connection changes. It shows a simple notification that tells me, I should reboot my phone. [1]
Issues reproduced on:
LG Nexus 4
Samsung ACE 2
multiple Apple iPhone 4*
Issues not reproduced on:
Apple iPhone 5
All phones running in the Dialog.lk network.
[1] https://github.com/felixb/network-checker
On a rooted device, one can issue the pkill command for all processes running as the user radio. I tested this on a Oneplus 3. The system seems to immediately restart the service:
pkill -u radio
Yes it is possible, but it will be difficult to perform on device without a deep understanding of the modem communications code of which multiple versions exist and even that will be dependent on if the system will permit you to even perform the communications on device.
The only one I am aware of that you can fully manipulate on device at this time is Qualcomm's (Qualcomm is standard in the majority of devices, but Samsung has used VIA in some cases which is a whole different monster, and even still another chipset or two exist), but to even be able to perform what your asking with Qualcomm's chipset, the following must be true:
The device must be rooted.
The application must have root access.
The system ROM must have the ability to place the cellular radio into modem diagnostics mode.
The device must have the appropriate permissions to permit the access.
At this point most people would connect their computer to their device and manipulate the cellular radio using QPST, CDMAWare, or QXDM. Options available to those users include everything from manipulating cellular subscriber data to restarting the cellular modem.
But, this is where things get tricky, you need to be be able to access this from the device side, which depending on the device, the operating system, and the configuration of it...may very well not be possible.
Also your application must be able to communicate with the cellular radio using the special protocol that the applications above use to do their communications which will require you becoming intimately familiar with that specification. The whitepaper for the Qualcomm diagnostics protocol is floating around on the web if you look hard enough for it.
Also on the not so cool side, if your application has access to the radio...so does any other rooted application (or even non-rooted, if you don't set the device permissions correctly) thus enabling rouge applications the ability to change your radio's configuration data potentially even bricking your device (which I have seen people do using the applications named above).
So my answer is Yes, you can do it, although:
Depending on your device you may not be able to, you should be well prepared to study and develop the needed tools to perform what you are wanting to do
No quick-start guide exist to be followed
Remember that you do so in the knowledge that your device could potentially be bricked either by a mistake in your coding or by a rouge application.
Rebooting the radio, as you have done in the device menus, may not help your problem, you may still require a device reboot
My advice is to use a much easier method and include a timer with automatic reboot in your current application, it is much safer, won't brick your device, and you won't have to become a cellular engineer to figure out how to accomplish it.
Your timer could begin counting down when the radio dies, and provide you an option to stop the reboot if your doing something important, otherwise it would restart your device and all would be ready when you reached for it to make a call or check your email.
Hopefully I was able to help, even though I know this is not the answer that you wanted.
Side note, if you could hijack Android's system configuration menus from an outside application you could potentially manipulate the radio state using the same methods used in Android...but you already discovered that restarting the radio in this method does not help your situation. Plus Android is designed to prevent such manipulation to prevent malicious applications from overtaking the UI of other apps and the system.