[Verizon Galaxy Note 3 Q&A, Help & Troubleshooting] bftb0:
Better Information About Battery Charge Animation on unlocked Phones

[MENTION=882465]Zzim[/MENTION] [MENTION=2022239]VJmac15[/MENTION] [MENTION=4306233]Captain Skeet[/MENTION]

I have some unambiguous clarifying information now about the "battery charge animation" when the phone is supposedly in an "off" state but plugged to a charger. Read on.

I took a stock (MJ7) boot image and unpacked it, and then simply repacked it, and flashed it to the boot partition in my (MJ7-firmware) SM-N900V.

Because there are very slight differences in "cpio" and libgz from linux release to release, this has the effect of making very tiny differences in the re-packed ramdisk image - enough that the Samsung signature is now broken, but likely nothing different at all from a functional perspective with the stock kernel or ramdisk (The kernel itself and it's device tree are bit-for-bit identical).

So what do it observe when I turn the device "off" and then plug to a dumb charger? The exact same stock "battery charge animation" that you would see on a retail device with a locked bootloader - plus one additional detail: that "Warranty bit set: kernel" message on the screen. After the battery animation runs for a while, the screen goes dark and the LED lights up according to charging state (red=charging, blue=charged, etc).

So the implication here is quite clear: the "off state" charging behavior you get depends on the kernel you have installed, and there is no difference in animations between signed and unsigned versions of the same stock kernel+ramdisk. An unlocked bootloader gives the same animations and LED illuminations as pure stock - so long as you are using a stock kernel.

Before I thought this was the bootloader running the (battery animation) show; but now I am beginning to believe that the bootloader fires up the kernel in some sort of jail when you plug power to the device. So if you are using a kernel that defaults to using a lot of power in it's idle state, (especially if it uses "init" to tweak into place battery savings) it's not going to charge as well as a less hungry kernel does - even when the device is supposed to be "off". It's even possible that the kernel could use more power when in this curious "off " state than when the ROM was running! (For instance, if the kernel developer decided "I'm gonna make this thing boot fast by setting the governor to performance; I'll reset it back to "interactive" with init in the late boot")

I watched the stock boot (MJ7) carefully, and realized that I couldn't conclude anything from USB behavior, as the MJ7 stock boot doesn't do anything with USB until well after init() has started running. I guess that the "jail" the bootloader creates for the kernel is probably a dummy ramdisk, perhaps including a very thin "init" program. That would explain why USB activity is seen with CM13 in this case, but not with the stock kernel. In the stock ROM that happens late in the boot after init has begun running, whereas the CM13 kernel fiddles with the USB interface before init is started.

Based on the evidence we have, I think this suggests that even with 100% stock retail devices & locked bootloaders, the same thing is going on - it's just not easily noticed because there is no on-screen activity other than that battery charge animation.. (It could be detected perhaps with an EMI sniffer or something)

So anyway - are the missing animations the fault of the kernel? Yeah, looks that way. Is it possible that the charging rate you get when the device is supposed to be "off" depends on the boot image kernel? Yeah, sure looks that way.

cheers