CAT S60 boot loop fix (#P17F1)
Good fucking Lord, that was a ride.
Last Sunday, my phone went out of juice and failed to come back to life. I had some issues with VERY high standby power consumption the entire week before, which caused the 3.8Ah battery to go flat within a work day. And so it did on Sunday when nobody was using it and nobody cared.
Long story short: A friggen weather app created an invalid (cron?) job, which caused the OS to reset indefinitely.
Long version: Boys and girls, root your phones. Even if some idiot banks (1822direkt, *cough*) will block you from running their apps “for security reasons”, having the option to fully backup and restore your phone outweighs that by far.
As ranted previously, I did change my phone not too long ago, so in addition to having the backup from back then, I was also able to make a full backup of the faulty system. And to reset it, and to do other backup and restore tasks in my six day journey of making the damn thing work again without data loss.
Now, for Android phones there’s a safe mode that can usually be selected by some power and volume key combination on power-on. Apparently that doesn’t work with the S60, because why should it, this thing only has 4 function keys, three navigation buttons and a hidden SOS button. Eight hardware buttons in a world of touchy-touch button phones. Jeez.
From a minimal clean installation, I ran two tests, did backups and reverted to the original state. One doing nothing but a clean shutdown, one activating the safe mode from the power-off menu (a little bit like Start -> Shutdown in Windows). Turns out it’s as simple as creating /data/property/persist.sys.safemode with file content “1”, and the phone will boot in safe mode next time. Now that I know this it’s easy to find on the web, but I didn’t manage to do that before. Besides, the usual way of doing that over USB via adb shell su -c 'echo "1" > /data/property/persist.sys.safemode' wouldn’t work for me, as it never got to the point where ADB would be available. Without root, it’d be rather difficult to do that. Second issue: That didn’t fix my problem…
So my second guess was that this was caused by a recent update. Again, I had power consumption issues before, so the last full reboot wasn’t that long ago, and I only install updates manually. Yet wiping the apps (via time stamps from the backup of the faulty state) didn’t change anything, wiping their data didn’t, and doing both was just more pain in the butt as I had to do this via the TWRP recovery terminal. This confirmed that this issue was not caused by an app update although the very last thing that showed before rebooting was some app optimization notification. It had to be on the system level.
Finally I took the time on a day off (for a shared work phone! Idiot me…) to run smaller batches of recovery. TWRP does allow for recovery of single partitions like system, data or EFS from a full backup, but that was too coarse. My system went into boot loop when restoring the data partition – a chunk of roughly 8GB. TWRP backups are just tar files (called “data.ext4.win000” and so on, though), so this is pretty convenient. Restoring the first three of those independent 1.5GB files did work as expected, as this just restored APK, ODEX and some other binary-related files that I ruled out before. The fourth one contained some more data from elsewhere, mostly the /data/data directory, which also turned out to be fine. And the fifth one was a convenient 400MB in size and actually caused the boot loop after restore. Which, I should mention, is done via the terminal again, just running tar -xvf [file] while being in the root directory. tar on Android does not care about the recording of the absolute path that TWRP does, and ark on my main machine totally craps itself, so I needed to perform any changes to the archive on a Windows machine with 7zip. WinRAR also has some issues with it…
A couple of tries later I was down to /data/system* causing the loop, and I found that there’s helpful log files inside of /data/system/dropbox/. “Dropbox”, WHY? Totally ignored that folder because I do not use it and the phone does not have the app installed. Yet there’s logs in there that everybody on the interwebs says aren’t there, one needs to run ADB logcat – which didn’t friggen work for me. So aside from “system_app_wtf@41348.txt” files that log in nice 30min increments that some system phone app dies pretty frequently, there’s also files like “system_server_crash@536041.txt”. That one says the following:
Process: system_server
Build: Cat/CatS60/CatS60:6.0.1/MMB29M/LTE_D0201121.0_S60_0.038.00:user/release-keys
java.lang.RuntimeException: Failed to create service com.android.server.job.JobSchedulerService: service constructor threw an exception
at com.android.server.SystemServiceManager.startService(SystemServiceManager.java:100)
at com.android.server.SystemServer.startOtherServices(SystemServer.java:897)
at com.android.server.SystemServer.run(SystemServer.java:272)
at com.android.server.SystemServer.main(SystemServer.java:170)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
Caused by: java.lang.reflect.InvocationTargetException
at java.lang.reflect.Constructor.newInstance(Native Method)
at com.android.server.SystemServiceManager.startService(SystemServiceManager.java:89)
... 6 more
Caused by: java.lang.IllegalArgumentException: You're trying to build a job with no constraints, this is not allowed.
at android.app.job.JobInfo$Builder.build(JobInfo.java:451)
at com.android.server.job.JobStore$ReadJobMapFromDiskRunnable.restoreJobFromXml(JobStore.java:638)
at com.android.server.job.JobStore$ReadJobMapFromDiskRunnable.readJobMapImpl(JobStore.java:491)
at com.android.server.job.JobStore$ReadJobMapFromDiskRunnable.run(JobStore.java:429)
at com.android.server.job.JobStore.readJobMapFromDisk(JobStore.java:265)
at com.android.server.job.JobStore.
at com.android.server.job.JobStore.initAndGet(JobStore.java:86)
at com.android.server.job.JobSchedulerService.
... 8 more
Okay, I do hate Java error messages, but there seems to be something wrong with “jobs”, as similar messages are repeated in other files that also match the current date/time. I’m familiar with cron jobs, not with Android jobs, so constraints is a somewhat diffuse concept. But that’s something we can build on.
Very conveniently, there’s not THAT much in /data/system/, /data/system_app and /data/system_priv_app left, but there is a “job” subfolder with one file, “/data/data/system/job/jobs.xml”. And lo and behold, before and after some other job entries that do have no constraints but at least mention delays or extras, there’s this bastard on line 282ff:
<job jobid="42613" package="com.weawow" class="io.huq.sourcekit.wifi.HICellularJobService" uid="10088">
<constraints />
<one-off />
<extras />
</job>
No constraints, not a one-time job, no extras. Yup – restore the full “faulty” backup, remove the lines from this very file, and the thing boots up as if nothing ever happened. Fuck you, com.weawow.
As I cannot spot a plethora of angry users over there, this either means nobody made the connection to this app yet, or this was a one-off glitch, maybe caused by a corrupted update download or really bad luck when writing the jobs file. In any case, this shit left me without a usable phone for a week and also made me miss last weeks blog post. And it made me dig deep into Android, much further than I ever intended to.
Well – root your devices, and make backups. Maybe automate them if you’re the type of person that likes to skip pesky but vital tasks of the modern era. Do however think about if want to save them “into the cloud”, which is, as we all know, just a fancy term for someone else’s computer…
Hi Mathias,
).
I suffered from this same issue three times (two in the last two days on two different smartphones
Firstly, many thanks for your research
, I was starting to think that weawow could be the problem, that’s why I found you, but couldn’t get anywhere near the solution. Unfortunately for me I have the stock bootloader so I had to reset the phone once again.
I am wondering if this is an issue of that app alone or it is a combination of more than one, given how rarely it seems to happen to people. The only other app candidates for my case are Poco Launcher 2.0, Feedly Classic RSS reader and Telegram, but I am thinking at the launcher mostly. I am running Android 6 on both phones, a Xiaomi Mi4W (6.0.1) and a Motorola MotoG 2nd Gen 4G (6.0), so that could be a requirement too
.
I wrote a comment also on Google Play, linking this page.
Thanks again!
Giacomo Roversi,
Italy
Dear Giacomo,
I do not run any of the other apps that you’ve mentioned, but of course there could be some kind of cross incompatibility with any piece of software. Maybe Android 6(.0.1) is the root cause, we’ll probably never know. I fixed the issue as described and got rid of weawow, no boot problems ever since. There’s something slurping battery like crazy at times, but at least that can be fixed by a simple reboot. Chances are I’ll get an upgrade to the S61 soon, as the huge battery typically lasts 12 hours now, and its pocket warming features aren’t that sought after in summer.
Cheers!
Hi Mathias,
I found it to be the thermal camera that is causing the “pocket warming features”. I have a coupple of S60 and they all have the same issue. After running the thermal camera, the thermal camera unit is still running (you can hear the calibration shutter operating). Closing the app, force stopping the thermal camera app and putting the phone into standby doesn’t help. I only found a restart to fix the issue, until the thermal camera is used again. I don’t know what it would take to stop it without shutting down, or how to an approach to find that out would look like. Do you have any idea?
Thanks,
Fritz
Hi,
at this stage, this could be some electrical failure of the entire module, where it needs a full power-down to (forcefully) switch into the off-state. It’s most interesting that you report this to be the case on multiple S60s.
Does root access make any difference when closing/killing the Flir application?
I have moved on and are now using a Doogee phone with Infiray sensor, are you still using the S60 as a daily driver? I guess the camera is useful for debugging and stuff, but given how picky e.g. banking apps are nowadays regarding Android versions, I don’t think I would recommend picking up S60 phones for that purpose, even at the sub-100€ price point that they’ve come down to.
Hi Mathias,
thanks for your reply! Yes it seems to be a common problem with the S60. All 3 devices that I own have the exact same behaviour. I haven’t rooted one of them, so I can’t try right away. I don’t know much about software, but I think you’re right about a possible problem with the hardware, rather that a software issue, because even a hard reset doesn’t fix the problem. A previous owner suspected battery problems and replaced the battery with little effect. No, I’m not using them as a daily driver. I’m planning on tinkering with thermal stuff, so the now outdated and obsolete Cat S60 is a cheap and easy option to get a thermal camera with display and battery. It also wouldn’t financially ruin me if I break one or two in the process.
Hi all. It looks like CAT phones are not meant for the dummy or ordinary users or person’s in the streets.
I do not understand a thing on what to do here. I am stuck with CAT 60 that reboots willynilly.
Please on simple terms,…. None scientific…. For a person who do not know what a programme or computer is…
WHAT MUST I DO TO STOP THE PHONE FRON BOOT LOOPING? Or from BOOTING AL THE TIME?
Hand it over to someone who does understand the technical mumbo jumbo and shell out some cash for the effort.
Or buy something else right away and stay away from CAT entirely, as the S61 is indeed a better phone, but that one too has its flaws. Not being able to root it is one of them.