Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "bootloop os"
-
!rant & story_time
This happend to the startup I was working for at ~2011. I was a junior Android dev, working on a very popular app.
During experiments for a new feature, I discovered that the system AlarmManager has a serious bug - you can set a repeating alarm with interval=0ms. If your app takes more then 1 ms to handle the Intent, then the AlarmManager will start to fill up the intent Queue, with unexpected results to the OS. causing it to slow down, and reboot when it ran out of Ram. Why? my guess was that because the AlarmManager was part of the OS, then any issues caused by it caused the system process to ran out of ram, crashing it, and the whole system with it. the real kicker was that even after a reboot, the AlarmManager still had Intents queued, causing the device to bootloop for a while, untill the queue was cleared. My boss decided to report the problem to google, as this was an issue in the OS. I built an example app, that caused the crash 10-30 seconds after starting, and submitted to Google. Google responded later that day with "not an issue, no one will ever do this".
Well... At this point I decided to review the autoupdate feature in our app, to make sure this will not happen to us. We just released a new feature where a user can set an update schedule option in the app settings - where you could setup a daily, weekly, or hourly update for the app. after reviewing it, It looked good, and the issue was not triggered in the manual QA I did. So, it was all good. And we released an updated version to the store.
After we did an update-install, we discoverd that, there was a provlem reading the previous version SharedPrefs value for the update schdule settings, and the value defaulted to 0...
the result was, our app caused all our users to go into a bootloop, and because the alarm was reset when the devices booted up, the bootloop could only be solved in a factory reset, or removing our app, before the device rebooted, and then waiting a few reboot cycles.
We lost 50 places in the market, and it took us 6 months to get back to where we were.
It was not my fault, but it sucked big time!4 -
*wondered for 4 years how a bootloop looks like*
Nexus: yOU wAnE kNoW wHaT a BoOtLoOp LoOkS LiKe?!
*bootloops itself to shit*
Well I guess that I know what I'll be doing tonight then. Flash that new StatixOS build because the phone shat itself.
*tries to reflash the recovery*
*still bootloops*
*tries to flash the stock OS*
*still fucking bootloops*
*finds a post on XDA saying something about fucked big cores that need to be disabled*
Fucking piece of junk. So not only the battery is shit, but also the CPU is shit, huh. Certified pieces of shit.
*flashes the patched boot.img that disables the big cores*
*phone loads Google logo.. good*
*BOOTLOOPS FUCKING AGAIN*
MJHUIETHNIUBESZPTUIBG ESVGU d
FUCK!!! Fuck you Google, fuck you Nexus, fuck you Huawei, HOW DIFFICULT CAN IT BE TO DESIGN A FUCKING PHONE?!!!
So yeah. Looking for suggestions for a new phone. Anything of which the kernel source is released and of which the battery is halfway decent (unlike this fucking piece of shit) should do.7