How come android headunits in a car boot up so fast despite being very under powered compared to phones these days ?
My car's android unit has some quad core processor , and it instantly boots up and reaches the home screen where as my phone takes almost 30 seconds or a minute to reach the home screen despite having much better hardware.
One reason may be that they're not actually off when the ignition is off, they're just asleep like your phone is when the screen is off but it's still powered on.
That's exactly it.
The unit does restart about once every week and then goes back to suspend to ram.
You basically will never notice the restart unless you cut off power. And additionally drain all capacitors.
Yeah, I recall the one time I actually saw my head unit restart, it took a minute to boot up.
There's actually a documentation article on this: https://source.android.com/docs/automotive/power/boot_time
Basically, there's just much less stuff running on Android Auto.
That, and don't many of these not actually fully turn off when you shut off the car? They draw 12v standby power and keep their RAM active, just going into a sleep or suspend mode rather than powering off fully so waking up happens pretty much instantly. It's like the difference between hard powering off your phone vs. just putting the screen to sleep.
That's how the head unit installed in my car works, anyways.
Won't this eat up the car battery in long term?
Theoretically yes, if you leave it long enough. But it really isn't much power draw so probably, like, decades. I think the battery might self-discharge and sulfate by then regardless. And this is nothing new; oldschool radios have a nonzero idle draw as well to keep their clocks running and remeber all your radio stations. I imagine the milliamps required aren't that much different.
Modern cars have all kinds of standby shit constantly drawing power to check in, keep time, phone home, blink lights, listen for the remote, etc., etc. all the time regardless. The audio system is really only one small piece of that whole puzzle.
That does make sense.
Among the other things that have been said, Android auto often makes use of some tricks too. Things like hibernation that phones typically do not do (Probably the biggest one right here), Animations to hide loading time, loading some critical, but not latency sensitive services until after the boot. and some other misc service management stuff.
Phones do actually have a "deep sleep" mode, where they suspend apps, downclock the CPU, and turn off features like radios.
Yep but that's not hibernate, that's what happens when you leave your phone on bed side table for a couple hours when you sleep. You can get very low power under these, which may be comparable to your cars alarm system.
Android emulators though have the ability to suspend all activities to disk and come back in a few seconds.
I think the phone just has to do more stuff
Yeah my S23 takes way too long to start up for being the newest tech. It's stupid.
Lol I too have a Samsung phone....That's why this question came up in my mind the first place.
Android Auto or Android Automotive?
The former is basically just a screen your phone is casting to. The latter is a lightweight (stripped down) Android fork designed to boot very quickly and do a couple things very well. It probably never really "turns off" since it still has a 12v connection even when the car is off (why your clock doesn't reset).
Android on your phone is a much more general purpose operating system that runs on a (much more limited) battery. It isn't designed to be turned on and off frequently.
There has been a lot of work done in the unix universe to reduce boot times: https://www.e-consystems.com/articles/Product-Design/Linux-Boot-Time-Optimization-Techniques.asp
A lot of it has to do with deferring services not needed immediately till later. The same could be done for Android.
They don't have as much background software recording everything and phoning home.
Give it time, and they may get there.
Source: I'm just bullshitting. I don't know jack shit about what runs on a new car. I don't buy new cars.
But my DeGoogled phone boots really fast, so I might still be right, unfortunately.
Basically, that kind of is it.
They have less background services overall as well as less hardware to initialise. Probably some other differences as well.
I'm not super familiar with Android Auto, but have worked with other embedded systems that are based on customized OSs. They typically run the bare minimum subset of features to do what they're designed to do.
It's also possible they don't boot every time but just kind of hibernate.
I would bet they have their own battery and use that while the car is off
Hmm. Maybe. Or at least an internal battery to keep it in "sleep/powersave" without draining the car's battery.
Now I want to tear one down to find out 😆
::: spoiler A lot depends on the overall systems.
If you're really interested in the subject, here are the places to look around:
These are the places that I learned the basic lay of the land in this space. The boot up speed is a combination of the way the bootloader is configured, how the handles for hardware interfaces are initialized, how well the Linux kernel can trust these interfaces, and all of the software that is initialized before the user space.
Android does not require the end user to know anything about the device, networking, or OS best practices. It achieves this by eliminating the administrative user and any kernel packages that could modify the kernel or install an administrative binary. Then, Android makes all installed app developers full users on your device so that they may use their knowledge to configure all of the required interfaces and security. You ultimately have all of the same access as they do, but you are not the administrator or have any effective say over what they are or are not allowed to do on the device. There are a few measures to help block off some behaviors, but these are more like frivolous gestures to make you feel a little better rather than any kind of authority.
The reason your device gets depreciated and must be periodically replaced is because google packages the Android version of the Linux kernel with everything setup so that only the kernel hardware modules (drivers) required for the specific device need to be added at the last minute. These modules are only added in binary form at the last minute. The source code is never made public and these modules are not part of the mainline Linux kernel. This is the only reason your kernel is not updated regularly and is likely very VERY old with many security vulnerabilities. The manufacturer might recompile and send you an updated kernel if a CVE happens that enables remote code execution, but this is only likely if they have a substantial inventory of devices in the warehouse that have not already sold. It has nothing to do with you or ethical behavior. If the hardware supporting kernel modules code was merged with the mainline kernel, your devices would stay up to date with all the kernel security updates for decades automatically. If this sounds wrong, let me warn you now, saying so will put you in the Stallman camp where you will be labeled as a crazy extremist. This is the specific reason for Stallman's insanity by his detractors. Stillman's argument is that you don't own your device.
These proprietary binary kernel modules are one of the primary aspects of boot speed. There is no telling what is happening on these levels when the device has proprietary binaries.
The system works with a bootloader that powers everything in a specific order and creates handles. The handles are passed to the kernel. The kernel initializes and starts running kernel space stuff. One of the main things it is doing is abstracting memory spaces.
If you've ever seen the earliest personal computers based on the microprocessor chips like the 6502 in an Apple II, they always had a RESET button. This is because a crash in the code crashed the actual hardware. In modern computers, your user space software only runs in virtual memory. This dies not require a reset because, while your software might still freeze, it is only running virtually. There is also a CPU scheduler that is handling interrupts (like key presses that can not wait, or background tasks) and power management works with this as well. When your software freezes, in theory, the kernel processes that are actually running on your hardware still get their time to run in kernel space priority on the CPU and their memory is protected from the virtual memory space of user software using virtualization.
Okay, all this bla bla bla is to say, if the device in question has no outside connection, and if the software can not change, and if the manufacturer is the one creating the bootloader AND kernel AND user space application all of this chain can be greatly simplified and bootup can happen lightning fast. This is called embedded Linux and is the most common form of Linux.
Android also has a system called Zygote. This preloads all of your apps when the user space loads. The user space on Android is actually like a single Linux application that runs on the Linux user space. The justification for Zygote loading everything in advance is because it makes everything load faster. Thus is what it says in documentation. Benchmarking shows that the difference is orders of magnitude smaller than your persistence of vision. In other words, it only exists to boot up the other dev users before you are loaded as the final
productuser. This is why you should not run any apps you do not exclusively trust. These app developers are like your bedmates but more intimately in contact with your person all the time. This is why everyone wants you to install their app. The google framework of Android is essentially a pimp and you are the product.how is this even related to the question? this isn't about any embedded linux, op stated it's an android unit. and said it's faster "than" other android phones and zygote applies to all so it's unrelated also.
The vehicle likely does not have any protection systems or encryption. It likely has the bootloader integrated with the kernel. It is also running native or native like Android packages while altering zygote behavior so that extra applications are only loading in at execution time.
If you really want to understand the subject, intuitively grounding your understanding is a critical aspect of the processes. Telling people the simplified basics in isolation does not create useful understandings and assumes the person is on a similar foundational understanding. Someone that is genuinely curious, such as myself, but having no prior background can make use of such abstract overviews. Someone with total recall would likely find me pedantic. With abstracted intuitive thinking as a primary function, many people such as myself require such deeply embedded intuitive connections to make sense of the world with a deeper understanding of the connections involved. I retain no information in isolation in long term memory. This is neither right nor wrong in some asinine simple view of the world and the way people learn. If you find it odd, that is fine. Functional intuitive thinking is one of the rarer outlying personalities, but it is also the emulator function that can fake the rest with effort.
It is related, but on many levels, and useful to someone other than yourself. A binary perspective of learning and sharing of information is fundamentally incorrect.
A phone uses a rechargeable battery.
The car uses a supercharged 5.0 liter Dual OverHead Camshaft 8-cylinder engine running on 93 Octane.
Which one has more power, oorrgh??
1 upvote = more power, Al
1 downvote = more I don't think so, Tim