I see a lot of people talking about flashing kernels and stuff, but what actually is it? What does it do? What benefits does it bring to your device?
In the world of Android term kernel refers to a modified Linux kernel. The kernel represents the lowest layer of the operating system in that it is responsible for controlling the hardware. Processor clock, memory accesses and other accesses to the hardware are executed by the kernel,
In other words the kernel generally serves as an interface between the hardware and the rest of the operating system with the program control, the Android runtime ("ART" or formerly "Dalvik"). Since the kernel is, among other things, responsible for the timing of hardware accesses, you can achieve significant improvements in terms of performance and battery life by changing the kernel.
xXx yYy said:
In the world of Android term kernel refers to a modified Linux kernel. The kernel represents the lowest layer of the operating system in that it is responsible for controlling the hardware. Processor clock, memory accesses and other accesses to the hardware are executed by the kernel,
In other words the kernel generally serves as an interface between the hardware and the rest of the operating system with the program control, the Android runtime ("ART" or formerly "Dalvik"). Since the kernel is, among other things, responsible for the timing of hardware accesses, you can achieve significant improvements in terms of performance and battery life by changing the kernel.
Click to expand...
Click to collapse
Thank you so much
I assume you aren't talking about this
The Linux kernel, which Android runs on, is essentially the "core" of the operating system. It interfaces with the device hardware and provides a software platform for applications to run on.
Here's something that should help put things in perspective:
"Devices" in this context means camera, display, digitizer (touchscreen), I/O's such as WiFi and Bluetooth, etc.
Related
I have been reading some of the items about people modifying ROMS, porting ROMS, etc. and I am not certain if I have all of the terminology correct. I am wondering if there is some type of architecture definition or diagram that would indicate the different parts of a ROM.
I found one web post that broke items down to kernel, libraries, bootloader, recovery, radio, framework, core, android runtime. What I don't know is what kind of correlation there is between a framework and runtime to a kernel. Is this a situation like Linux where you have a kernel with all of its drivers and you would run the Android GUI on top of that and any version of the Android GUI is going to work with pretty much any kernel, or is there some type of match-up between a kernel and specific versions of Android?
I have an Elocity A7+ which uses a Tegra II 1ghz dual core CPU. It was only built with Android 2.2. It seems like this tablet should be able to run ICS fairly well since I have seen a number of single core tablets running it. The manufacturer made the kernel source available for this tablet, but what I don't understand is if it is possible to build the ICS framework and runtime with this kernel.
Without detailed information it would seem to me that the kernel is taking care of interfacing directly with items like the touch screen, the camera, the audio system, the buttons, the wi-fi, etc. Do requirements for kernel interfaces change from android version to android version or can an ICS framework communicate with the kernel from a 2.2 device? Is there any kind of documentation that indicates what kernel calls have to be available to the different Android versions?
I apologize if I am not asking the right questions.
I was just wondering what exactly were 4.4's minimum system requirements. Is it possible that a device with 512MB RAM can really run it or is it just a gimmick?
Ya hope so!!!!
Sent from my GT-S7562 using xda app-developers app
adarshsosale said:
I was just wondering what exactly were 4.4's minimum system requirements. Is it possible that a device with 512MB RAM can really run it or is it just a gimmick?
Click to expand...
Click to collapse
I'm not sure that a lot of that technical data is released yet. If you are referring to older, legacy devices, then it's likely not possible to get those running KitKat, simply because the various drivers and hardware need to be compatible with one another. This was a major issue with older devices trying to run ICS, which needed hacks to run properly.
Yes Android 4.4 was developed to support low-end devices.
look at:
hxxp://gadgets.ndtv.com/mobiles/news/android-44-kitkat-supports-devices-running-just-512mb-of-ram-440357
Well, if you look after Nexus S' forums, you'll see a lot of people working to port the Nexus 5's ROM or even compiling the KitKat sources to their devices. So, yes, it is possible using 512mb of RAM. The problems, instead, are all related to drivers' compatibilities.
i heard that its going to be supported for lower end devices, such as your 512mb of RAM
Android 4.4 is designed to run fast, smooth, and responsively on a much broader range of devices than ever before — including on millions of entry-level devices around the world that have as little as 512MB RAM.
KitKat streamlines every major component to reduce memory use and introduces new APIs and tools to help you create innovative, responsive, memory-efficient applications.
OEMs building the next generation of Android devices can take advantage of targeted recommendations and options to run Android 4.4 efficiently, even on low-memory devices. Dalvik JIT code cache tuning, kernel samepage merging (KSM), swap to zRAM, and other optimizations help manage memory. New configuration options let OEMs tune out-of-memory levels for processes, set graphics cache sizes, control memory reclaim, and more.
In Android itself, changes across the system improve memory management and reduce memory footprint. Core system processes are trimmed to use less heap, and they now more aggressively protect system memory from apps consuming large amounts of RAM. When multiple services start at once — such as when network connectivity changes — Android now launches the services serially, in small groups, to avoid peak memory demands.
This thread may be old. But yes you can run KitKat on 512 MB RAM devices. I'm running KitKat on such a device. But I have to mention that it's also possible to run Android versions lower than 4.4 on low ram devices.
guys im new,just started to see how works android and stuff.
what are kernels?sort of drivers?
found here
In simple terms, the kernel is a bit of software that tells the operating system how to use the hardware. That includes the processors, RAM, buttons, speakers, the screen, etc. Root access is required to adjust kernel parameters, and an unlocked bootloader is required to flash custom kernels. A custom kernel can offer adjustments outside the stock settings, such as overclocking, undervolting, vibration intensity, screen color adjustments, touch-wake options, etc. A custom kernel has the potential (but no guarantee) to improve performance, battery life, and stability. Often custom kernels are more up-to-date than factory kernels, since the people that create and work on them base them on the latest from Linux/Android, while the manufacturers typically don't bother. But that depends on the device; for example a Nexus phone will have a plethora of custom kernels available to try, but some random Mediatek powered clone from China probably won't.
what are kernels in short.
kernels is a software domain chain which lets you interact with the os and the hardware.
donate me a thanks if it helped you.
With short words, kernel is bridge between software and hardware. An Android Kernel is essentially a modified Linux Kernel with specific modifications to support the device architecture. You can read more about it here: http://xda-university.com/as-a-developer/getting-started-building-a-kernel-from-source
As we've seen, Android's flagship phones are equipped with some of the latest and best hardware; however, I read articles that mention Apple iOS takes full advantage of Apple hardware. The iPhone 6S with their A9 dual core processor including 2gb of RAM is able to compete with a Nexus 6P that has a hexacore Snapdragon processor with 3gb of RAM.
On the 6th iteration of Android (Marshmallow), why is Google unable to optimize their OS for their phone's hardware like Apple does?
Edit: My first post was never answered, so I'll try to get to the point. Does Apple's iOS communicate with the hardware more efficiently, whereas Android takes more steps to communicate with the hardware; therefore being less efficient?
It's not Google's hardware. Google does not make the Nexus line.
MrKhozam said:
It's not Google's hardware. Google does not make the Nexus line.
Click to expand...
Click to collapse
I'm not sure why I wrote that. You are correct, every Nexus phone has been manufactured by different companies. On a side note that might change. I read from a few tech news sources that Google is possibly going to take stricter control of the Nexus line and start manufacturing phones under their brand (same way Apple does).
My first post was never answered, so I'll try to get to the point. Does Apple's iOS communicate with the hardware more efficiently, whereas Android takes more steps to communicate with the hardware; therefore being less efficient?
iOS is developed explicitly for Apple's hardware. They know exactly what they have to do to take the full advantage of the hardware. They don't have to optimize the OS for other hardware because it only runs on Apple devices. In fact, Android runs on hundreds and thousands of different devices, which all have different hardware. Android needs to be optimized for the specified hardware but it is not so easy and also Android has to run on very different hardware without loosing compatibility.
The other thing that makes Android slower, is that applications run on a virtual machine. Applications on iOS are native and run directly.
Another point is that Android's responsiveness to the touch screen is worse than iOS' responsiveness. If you tap on something in iOS, it is immediately processed. In Android it takes some little time to process the touch event. Also you can tune up your Android system to increase responsiveness by increasing the allowed events per second on the windows manager and reducing the minimum pointer duration. You can also set the surface flinger velocity higher, so stuff on the screen would build up faster and render faster.
So the conclusion is:
In general, Android's responsiveness is not so good as iOS' responsiveness.
And iOS is made specially for Apple devices, so 100% hardware support is available.
Android needs to run on many many devices, so it is difficult to maintain 100% hardware support and compatibility as well as efficiency.
Hope that is clearly enough
"Specs" are also misleading. If specs on paper told the whole tale, AMD processors would be better than Intel, Mediatek would be better than Samsung and Qualcomm, and the Tegra K1 dual core used by the Nexus 9 would be laughably underpowered. iOS also doesn't need as much RAM as Android (remember, it's Linux based) for the way it handles memory. Don't go assuming that the "slow" speeds and fewer cores you see on Apple devices means that the hardware is inferior. If it were, they wouldn't get such impressive benchmarking scores.
xdvs23 said:
Another point is that Android's responsiveness to the touch screen is worse than iOS' responsiveness.
Click to expand...
Click to collapse
Is this because there's more 'layers' in Android's OS, so it takes more steps for it to create the response?
Thanks for taking the time to write out that long response. It was very well written and explained a lot for me.
This is the same reason game consoles stay relevant years after they come out with inferior hardware. Interesting how it works - better hardware but software can't take advantage cause of the potential audience
techmatlock said:
Is this because there's more 'layers' in Android's OS, so it takes more steps for it to create the response?
Thanks for taking the time to write out that long response. It was very well written and explained a lot for me.
Click to expand...
Click to collapse
It is because of the way android is made. Android was initially made for non-touchscreen devices with hardware keyboard. Later Google added the touch feature over the existing functionality instead of changing the whole system to optimize for touch devices.
---------- Post added at 10:43 AM ---------- Previous post was at 09:48 AM ----------
Planterz said:
"Specs" are also misleading. If specs on paper told the whole tale, AMD processors would be better than Intel, Mediatek would be better than Samsung and Qualcomm, and the Tegra K1 dual core used by the Nexus 9 would be laughably underpowered. iOS also doesn't need as much RAM as Android (remember, it's Linux based) for the way it handles memory. Don't go assuming that the "slow" speeds and fewer cores you see on Apple devices means that the hardware is inferior. If it were, they wouldn't get such impressive benchmarking scores.
Click to expand...
Click to collapse
Do you mean that android is linux based or iOS? Keep in mind that Android uses a modified linux kernel, which is optimized to be used with the Dalvik VM (or ART).
iOS is not based on linux. According to Wikipedia, iOS is based on Apple OS X, which uses the Darwin kernel, which is based on NeXTStep, and the top root of that is unix (BSD).
---------- Post added at 10:52 AM ---------- Previous post was at 10:43 AM ----------
Btw, Android has a delay when handling touch input events. When you tap on the touch screen, the kernel intercepts the touch event, notifies the system about it (window manager), then it is redirected to the currently active window and then it is handled by the corresponding application. The window manager is set to handle 30-60 (depends on the ROM) events per second by default, but I have adjusted it to 1200 and you really notice a difference. By setting the pointer duration to the minimum, the responsiveness is also increased. In that way, the delay is kept as small as possible, nearly coming to iOS level.
AFAIK iOS handles the input event directly. When you tap, the kernel redirects the event directly to the corresponding application which handles the input immediately. Also the performance in native iOS apps (they are written in Objective-C or Swift) is better than in android (written in Java, optionally expanded by C/C++ shared libraries).
Another important factor is that Android applications do all the stuff in the main UI thread by default. That means, whenever you tap on the screen, everything is handled in the UI thread, what causes that the UI is freezed for the time the application is processing the touch event. (Although this is a very very small hardly noticable timespan, it results in lag). Poorly developed android applications are very laggy because they don't use separate threads to do time intensive work.
In iOS instead, everything is handled in a separate thread by default. That means that when you tap somewhere, the UI would not freeze or lag during operations in the second thread. The result is, that you don't experience any lags while navigating through an user interface.
Conclusion is: Android is fast but it does not handle touch events so fast. Also, by default, operations are done in the main thread. On iOS they are handled separate.
Bit of a story here.
So I have been long into car hacking, doing all sorts of canbus related modifications to my Merc W203 model.
The stock radio is utter garbage by today's standard, and Xtrons do a ton of android head units for my car. (Either with an A35 CPU and 2gb ram, or Px5 CPU with 4gb ram).
I am wondering, would it be possible to COMPLETELY remove android from it, and instead boot something like archlinux-arm on it. I want to create some custom applications on it whilst also having full control over the entire OS (Hence the want for Linux, not android).
I do kernel development as well so I am not worried at all about devices not working, I can likely hack together a kernel driver for nonworking hardware on the unit.
I am simply looking if it is possible to wipe android and see if it's possible to use it as a bare bones PC.
Any help would be appreciated, before I bite the bullet and spend £250 on one!:laugh:
You still need the GUI and stuff like that.
Besides, Android "is" Linux! Much better, imo, to base it off of Android, to keep the ecosystem that that comes with.
FransUrbo said:
You still need the GUI and stuff like that.
Besides, Android "is" Linux! Much better, imo, to base it off of Android, to keep the ecosystem that that comes with.
Click to expand...
Click to collapse
I am pretty sure by he said 'bare bones' does not mean an (Linux kernel based) operating system with only an command line terminal (i.e. something that looks like MS-DOS).
My point is that native Linux doesn't HAVE "mobile GUI". It have X11, which is *NOT* (!!) suited for such a project..
So either have to port whatever GUI Android have back to Android, or write his own. Which is a *MASSIVE* (!!) undertaking..
Also, Linux isn't quite suited for mobile applications. That's why Android was created. It took all the good from Linux and made it fit a mobile application.. Reverse engineering or back porting all that work to Linux is just dumb..
FransUrbo said:
My point is that native Linux doesn't HAVE "mobile GUI". It have X11, which is *NOT* (!!) suited for such a project..
So either have to port whatever GUI Android have back to Android, or write his own. Which is a *MASSIVE* (!!) undertaking..
Also, Linux isn't quite suited for mobile applications. That's why Android was created. It took all the good from Linux and made it fit a mobile application.. Reverse engineering or back porting all that work to Linux is just dumb..
Click to expand...
Click to collapse
Wait does the OP mean he need some thing like postmarketOS(some kind of Linux distribution with mobile GUI)?
Of course he does!! What do you think "Linux" is?!
Linux is *JUST* (!!) the kernel! NOTHING else.
The *distribution* is everything else. Boot procedure (scripts, commands, filesystem tools - technically that's "The Userland" - the install procedure, the packaging etc etc). Then you put your GUI on top of that.
On top of that you have X11. Or "The GUI". TECHNICALLY, X11 require some more stuff, the window manager too actually be useful. Without it (the window manager), X11 is just an API to the graphical functions - "draw window border", "draw a close button" etc etc. Which is what the window manager utilises.
So: kernel <- userland <- X11 <- Window manager <- Graphical apps
Then all of that is packaged up in a need CD/DVD/Image to make it easily installed and used. And we call that "The Distribution".
This is how UN*X works and that's how LINUX works. Simple, portable and very useful. But not for a phone, tablet or, in this case, a car!
That's why Android was created. It is ALL of that, in ONE package! With thousands and probably millions of apps compiled for it. Do it yourself, and you have to write EVERY (!) app you need yourself - radio apps, navigation etc etc ad-finitum..
Because NO ONE/THING (except in very rare occasion) "talks" to the kernel. They "talk" to libraries (libc, libX11 etc) to do what they need. Which is why you need "The Userland". THEY (the libraries) then "talk" to the kernel (networking, filesystem, input, output etc) giving the apps a nice API - "Application Programming Interface". A set of functions and tools for applications to use, so they don't have to recreate "the wheel" every time.
Now, I'm not going to go deeper, unless you want me to . I do understand that the un-initated don't know the difference between "Linux" the-kernel and "Linux" the-everything. But this *IS* important, believe it or not..
The kernel is absolutely useless on its own. It can't do squat! It was never MEANT to be used on its own. It was designed and built to be used *with* a distribution - "GNU" in the large majority of cases..
Although it's possible to use bare-bones Linux with either your own distribution (MASSIVE amounts of work, I know, I've tried it!) or an existing one (Debian GNU/Linux, RedHat, SuSE etc - they all provide binaries and packages for a multitude of processors), none of them have all the goodies that Google Play Store have.
And none of them are really targeted towards a mobile graphical environment.
Raspbian for example, was made for the Raspberry Pi, but that is in 99% of cases a non-graphical environment (robots and media stations mostly). Most distributions is like that.
The Play store on the other hand is *specifically* targeted towards a mobile, graphical environment. As this is. I would be foolish to try to reinvent the wheel when Android already IS Linux+userland+GUI+distribution.
Keep in mind though that Android apps on Google Play is compiled for an ARM (ARM64) architecture! Meaning, whatever hardware utilised, MUST run on/with an ARM processor..
All this limits the hardware choices substancially.
Everything "is possible". In theory. In practice though, I'd say the answer is "no". It is simply to much work to get it working. For absolutely no benefit.
With that being said... Bare Android on the other hand!! Now THAT is an idea.
Get your Android kernel source and compile it for the specific hardware you're using and then your Android distribution, set it up juuuuuuust so and you'll get what I (and probably everyone always wanted - a non-bloated piece of ... well, we've all seen them.