Pocketnow Power User
Pocketnow Power User

On the Pocketnow Power User so far this season we’ve talked mainly about hardware. What is the hardware abstraction layer, and why should you care?

The Hardware Abstraction Layer (HAL) bridges the gap between hardware and software. Be warned, this topic is very, very geeky!

To begin with, the HAL isn’t a concept that’s unique only to smartphones and tablets. It’s been around for a quite a while, but it’s implemented differently depending on the environment that you’re talking about.

Hardware abstraction on an MS-DOS system is very different from that on a Mac, and from a technical standpoint it’s just as different on iOS, Android, and Windows Phone. It’s the concept that’s essentially the same, and that’s what we’re talking about today.


Hardware is physical. It’s tangible. It’s something you can see with your eyes and touch with your fingers.

Hardware is the screen that displays information on your device. It’s the touch-input digitizer that you interact with. It’s your microphone and your speakers, and the buttons that you press to turn it on and off or adjust the volume.

Hardware is your camera and your radios for cellular, Bluetooth, WiFi, and NFC. It’s the batteries that power all that, and the connector that lets you charge the device and transfer data.

By itself, hardware doesn’t do much.


Software is the code that developers (or “programmers”) write and compile that tells the hardware what to do. Some software can be described as “apps”, but those are mainly what I’d consider “front-end”. They exist to get information from some source, present it to you, the user, and let you act on it.

Other kinds of software could be the Operating System itself, or…


HAL 9000
Open the pod bay doors, HAL. “I’m sorry, I can’t do that, Dave.”
… the Hardware Abstraction Layer. This concept of the HAL used to be much more strict and rigid than it is today (and I’m sure plenty of comments will argue the old-school definition versus what we have today).

Back in the days of DOS-based computers, if you wanted to write a letter to your Mom (by the way, when was the last time you did that?) you’d fire up your word processor, type your letter, then print it out. To convert the information that you had just input onto a printed page is actually somewhat complex. The word processor had to have a print driver for your particular printer installed and configured, which would convert the letter into movements of the print head across the page, ultimately resulting in a letter you’d put in an envelope, address, stamp, and send to your Mom.

Although print manufacturers would often assist software developers to make this happen, the driver itself was encapsulated inside the app. Another program, your spreadsheet app, for example, would have to duplicate much of what was in the print driver in your word processor to enable printing from that program. One driver might be better than another resulting in great print-outs from one program, but sub-par print-outs from another.

In addition to taking up extra space on your disc, developing these drivers took time away from the writing the app itself, just to make printing work.

Once more “modern” operating systems like Windows (and others) came along, the operating system provided a common printing interface. The printer manufacturer would make a driver for Windows, and any program running in Windows could then print to it without having to reinvent the wheel.

Carry this same concept forward to all those other pieces of hardware, and you can start to see the true utility of abstracting the hardware away from direct communication with the individual devices.

Often time the HAL is a “thing” in and of itself. Other times those functions are carried out by the kernel. They could also be accomplished by device drivers. In many cases, all of these work together to accomplish the objective.

Today we’re taking that a step further through APIs — Application Programming Interfaces. These APIs still talk to the devices (either directly or through the HAL), but they are less specific. For example, if you want to know the device’s position, an app can now talk to a location API. That API can gather information from the barometer, digital compass, aGPS, WiFi, cellular radios, GLONASS, etc. The app doesn’t need to know how it’s getting the location data, nor does it have to make separate calls to each piece of hardware,  the API takes care of it. What’s more, the API might let you, the user, control the level of specificity that it reports back (exact location, or just in general, or not at all).

In short, the HAL and these APIs let developers focus on writing awesome apps, rather than worrying about communicating directly with hardware.

Joe graduated from Weber State University with two degrees in Information Systems and Technologies. He has carried mobile devices with him for more than a decade, including Apple’s Newton, Microsoft’s Handheld and Palm Sized PCs, and is Pocketnow’s “Android Guy”.

By day you’ll find Joe coding web pages, tweaking for SEO, and leveraging social media to spread the word. By night you’ll probably find him writing technology and “prepping” articles, as well as shooting video. Read more about Joe Levi here.

You May Also Like
microsoft edge
Microsoft is making PDF annotation truly effortless in Edge browser
Microsoft’s new PDF annotation trick for Edge browser works both with mouse and cursor input as well as touch gestures.
Telegram adds invite links with custom expiry span and message auto-delete tool
The latest Telegram beta also adds the ability to auto-delete messages in a group chat, and turning a public group into a broadcast group.
blood glucose monitoring
Samsung might soon launch a smartwatch running Wear OS
Samsung is bringing back Google’s Wear OS – previously known as Android Wear – to its smartwatch portfolio after using the in-house Tizen OS.