Android Sources For The Asus Tinker Board

The Asus Tinker Board is one of the quiet achievers of the powerful single board computer market. A Raspberry Pi form factor with a significantly more powerful processor, more memory, faster networking, and Asus build quality. In hardware terms it leaves many of the other Pi competitors in the dust. If the Tinker Board has a problem though it is the same one that affects so many otherwise promising offerings, that its software support isn’t as strong as the fruity computer from Cambridge. When you buy a Pi it’s Raspbian that makes it a wise purchase, along with the huge community support that surrounds it.

An interesting development on that front comes courtesy of [Justin], who tells us that the sources have been released for the Tinkerboard flavour of Android. The community have put in the work on the board’s Linux distro, but the Android side hasn’t had the same opportunity. This step makes the Tinker Board a significantly more interesting choice for custom Android development, as unlike some of its competitors for which only precompiled builds are available it puts a bespoke Android build in the hands of its developers.

We like the Tinker Board here at Hackaday. We first reviewed it when the boards became available, but later found that they had reached the market in error before Asus had a stable operating system. We therefore returned with another review six months later, and found it to be a credible Raspberry Pi alternative saved by its band of enthusiasts who have filled in for any of its software shortcomings.

18 thoughts on “Android Sources For The Asus Tinker Board

  1. Hmm, I didn’t want one when they first came out—the software is the kicker—but now, with the full brute force of android behind it, I may have to reconsider and redistribute my project money.

    1. Android is not an improvement on OS design, but rather focused on app delivery frameworks and user meta-data collection like iTunes.

      Land fills are loaded with 12 years of Google e-waste that never even achieved maintainability — their reputation for community software detractors is also legendarily whimsical. YMMV

      1. Yup. There are tons of Android tablets and phones and SBCs and other devices that have been and still are being tossed onto the market then never ever given an update to the OS they shipped with.

          1. heh. We have our own versions of The Hipster ™ right here. Probably several different variations it being a hacker ‘community’.

            A good example is the self-entitled wanker from a while back who accused people of racism because we spotted a potential security issue with his Really Cool ™ automatic garage door opener. You may remember it, the one which left his garage door wide open until his car was out of range…

          2. Android is not Open Source. The important parts that make most Android devices work – device drivers – are still tightly closed and will remain as such. That’s the main reason behind the tons of tablets and phones trashed every year: nobody can install a working different OS natively (no chroots or franken-OSes) other than their own flavor and version of Android, which is made obsolete by choice and unsupported deeming the product to its end.

          3. Good luck finding an Android device that had 100% of source code available.

            The fact that most of Android is Apache licensed results in nearly every device on the market having all of its components closed-source.

            Even the Nexus/Pixel devices have a decent number of binary blobs under restrictive licenses (Qualcomm redistribution licensing was a major contributor to JBQ’s final burnout and departure from Google…), and once that particular device goes EOL, no more binary updates – and newer versions of Android almost always require changes to the blobs.

            The end result is that for anything other than a “currently supported Pixel”, supporting Android on any device is a very time consuming effort due to binary blobs.

            OEM devices are far worse since OEMs often mangle the interfaces between the blobs and the rest of the OS without documenting it. Samsung is especially bad in this regard. For example, in the Galaxy S2 era, rather than fix their light sensor HAL to properly report the maximum possible value, instead they shipped a broken HAL and hacked the upper Android layers to ignore the reported value and use a hardcoded one instead. Attempt to use the HAL with “normal” AOSP sources and the light sensor would become almost useless.

      2. Well, except we’re talking about the Tinkerboard version, not the “MyCellphone” version. A rather important difference. There’s also nothing wrong with leveraging an app store since part of the reason for these boards is work needs to be done.

        1. Sure, but I think it’s still the case for most people that we use Linux when we want to understand, create or improve something novel, and we choose when we want to make some bux selling apps, or we want to control our Linux thingy from our phone.

    2. WoW! I didn’t know I started such a flame war!
      I agree with most of you wholeheartedly, I was just speaking for the guy who wants to fit a tiny netflix streamer inside of an altoids tin, or build a useable smartphone.
      In my ideal world, everything would be open source (or at least become so after the economic life of the code has expired) and would have indefinate support from the people who made it.

  2. I run the armbian system on it. I didn’t have as much luck with the Asus distribution. I’ve not looked to see if they have gotten better. I think a merge of the armbian work with an android on here could be interesting.

    I wonder if the system runs on the Tinker board model S which has 16gb of emmc added, and a few other bits.

  3. I got one a week ago to see what it’s like. Support is poor and if you’re not comfortable with Linux much then will be a steep learning curve. Their TinkerOS is older than the community build armbian. I build that myself to create a headless server distro. Very easy just followed the instructions on armbian. Forget the Asus resources, waste of time. As far as performance, yes it’s twice as fast. And yes the SDCARD is far better than the RPi. On my RPi3 a USB drive is 2x faster for building code than running from SDCARD. On the tinkerboard makes no difference. This makes the SDCARD a real option for projects that will be accessing the disk a lot.

    I would say hardware wise it’s where people want the RPi4 to be. 2x speed and 2x ram and working SDCARD. But I do believe the RPi foundation should not go down the route of creating new versions of the RPi every year. That just adds fragmentation which is not a good thing.

    In sort, as we all know, it’s good but could be so much better.

      1. SD cards aren’t as durable as SSDs but they are good enough for SBC-based projects. The earliest Raspberry Pi boards earned a reputation for corrupting SD cards due to power stability issues. I had a launch day Pi, and it constantly corrupted cards for its entire life. Every Pi I’ve had since then (six total) have not corrupted a card unless I purposely removed power before shutting down, and even then I had to do that over and over to see any corruption.

  4. I have the Mali driver sources and the rockchip sources. Allow me to introduce myself. I’m the creator of Slash TV Android OS for the tinkerboard, and the head software developer/project owner of ROTT(retro pie on the tinkerboard). I’d like to point out I’m whipping RPIs butt in terms of emulation and media, then I went in and ported slash TV to rpi, and nano pi fire 3, working on Jetson nano. Tinker is very much alive, I’ve been bugging Asus for a follow up model with 64 bit this time.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.