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.
this post was submitted on 03 Aug 2024
71 points (96.1% liked)
Android
27947 readers
176 users here now
DROID DOES
Welcome to the droidymcdroidface-iest, Lemmyest (Lemmiest), test, bestest, phoniest, pluckiest, snarkiest, and spiciest Android community on Lemmy (Do not respond)! Here you can participate in amazing discussions and events relating to all things Android.
The rules for posting and commenting, besides the rules defined here for lemmy.world, are as follows:
Rules
1. All posts must be relevant to Android devices/operating system.
2. Posts cannot be illegal or NSFW material.
3. No spam, self promotion, or upvote farming. Sources engaging in these behavior will be added to the Blacklist.
4. Non-whitelisted bots will be banned.
5. Engage respectfully: Harassment, flamebaiting, bad faith engagement, or agenda posting will result in your posts being removed. Excessive violations will result in temporary or permanent ban, depending on severity.
6. Memes are not allowed to be posts, but are allowed in the comments.
7. Posts from clickbait sources are heavily discouraged. Please de-clickbait titles if it needs to be submitted.
8. Submission statements of any length composed of your own thoughts inside the post text field are mandatory for any microblog posts, and are optional but recommended for article/image/video posts.
Community Resources:
We are Android girls*,
In our Lemmy.world.
The back is plastic,
It's fantastic.
*Well, not just girls: people of all gender identities are welcomed here.
Our Partner Communities:
founded 1 year ago
MODERATORS
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:
- OpenWRT is the goto embedded Linux starring point. It is hard if you're only familiar with desktop distros that use the Bash shell as the default. OpenWRT only has busybox with the Ash shell by default. OpenWRT is common on routers and is an entire distro that fits within 8-32 MB of flash memory on these devices or others like single board computers. Often, using an old router board just to hack around like it is an SBC is a great way to learn.
- Try working your way through a Gentoo install on any old computer. Unlike Arch, Gentoo is a foundational distro that has a plethora of tutorial based content to guide you through all the different parts of an operating system. Gentoo packages very little for you in binary form. It shows you how to compile almost everything and allows you to learn how to customize and compile and package to your liking. You will likely need advanced-intermediate level skills to cope with the competence level that Gentoo assumes in documentation. Docs are written from the foundation up, but they assume infinite ability to learn and do not continue to hold your hand. By contrast, Arch de facto assumes you have a CS degree and have completed all courses on POSIX operating systems in how pacman is managed. Arch provides an excellent set of reference documentation, but is a fractal bottomless links chasm if you try to use it like a tutorial for contextualization like what Gentoo offers. If you ever wish to learn the next level and what Gentoo is actually packaging for you, Linux From Scratch (LFS) is a thing.
- On a more practical side, base Debian is another foundational distro. It serves two primary purposes. It is the stable distro of choice. This means that most packages and libraries are frozen in time and only updated for security patches or packages that maintain backwards compatibility as an absolute priority. If you're building some project using a bunch of high level Linux stuff but it needs to be safely online, doing so on a long term supported stable distro means, once the project is up and working, keeping the software up to date should not break anything. Debian is also the primary hacking distribution where hardware support for Linux is done. There are a bunch of Debian specific tools to get into and boot new hardware, called bootstrapping. This is how there is support for many hardware devices that have no public documentation or OEM support. The wonderful folks within this space make much of our world possible. I mention this one because a lot of the things happening with the initialization of hardware are better fundamentally documented in this space.
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 ~~product~~ user. 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
