Building Android for UDOO-NEO

Ronaldo Nunez — Wed, 02 Dec 2020 00:59:44 +0000

Embedded Android is a hot topic in embedded systems circles. Not due to the easiness of building it. In this article, I'll guide you on the building saga of Android Marshmallow, or simply Android M, for UDOO-NEO boards.

UDOO-NEO is a low-cost development board with some nice support for Android. If you already tried to build Android from the scratch then you know that building it can be very tricky, that's especially true for old versions. For that reason, I decided to share with you a technique to build Android on modern Linux distributions.

First of all, you gonna need a Linux distribution. Android's team suggests Ubuntu 14.04 to build Marshmallow version, mainly for the OpenJDK version available on its repositories, which is v7. It's not possible to use any newer version.

You can use any Linux distribution you like or feel comfortable with, but keep in mind that you gonna need to install OpenJDK-7 anyway. Personally, I don't like to keep many versions of JDK in my machine, even update-alternatives being a good tool to maintain many JVM/JDK versions in the host system.

You doubtless don't want to install Ubuntu 14.04 on your machine, since it lacks support since 2019. You may say "ok, I can go with a VM", but, believe me, there is a faster and less disk/memory-hungry alternative: Docker. Docker containers can work over host's filesystem and can consume up to 90% less RAM, once the host shares most of its resources with containers.

Instead of learning how to use Docker, which may be a bit difficult, we'll use a tool called rebuild, or rbld. Rebuild has a simple command interface to create containers for cross-compiling.

Installing rbld

Before installing rbld, you need to install Docker, gem and Ruby. In OpenSUSE, type the command below on the terminal:

# zypper install -y docker ruby ruby-devel

Add your user to docker group (remember to logoff after running the command below):

$ usermod -aG docker <username>

Finally, you're good to install rbld:

# gem install rbld

Building environment setup

Using rbld is very straight forward:

Usage:
  rbld help                Show this help screen
  rbld help COMMAND        Show help for COMMAND
  rbld COMMAND [PARAMS]    Run COMMAND with PARAMS

rebuild: Zero-dependency, reproducible build environments

Commands:

  checkout
  commit
  create
  deploy
  list
  load
  modify
  publish
  rm
  run
  save
  search
  status
  version

We need to create an environment, for that use command create:

$ rbld create --base ubuntu:14.04 android-m

Now, we need to provision the environment:

$ rbld modify android-m -- "sudo apt-get update && sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig python lzop bc u-boot-tools liblz4-dev vim uuid uuid-dev zip lzop gperf zlib1g-dev liblz-dev liblzo2-2 liblzo2-dev u-boot-tools lib32z1 flex git-core curl mtd-utils android-tools-fsutils"

Finally, is time to commit changes (yes, environments in rbld are versioned):

$ rbld commit --tag v1 android-m

Cloning source-code

Let's leave the environment setup aside for a moment and focus on collecting the code to build Android.

In order to clone Android repos, you need to install repo tool:

$ cd ~
$ mkdir ~/bin
$ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
$ chmod a+x ~/bin/repo

Now, we can clone Android M repositories (be aware that may take several minutes):

$ mkdir ~/bin ~/android-m
$ cd ~/android-m
$ ~/bin/repo init -u https://github.com/UDOOboard/android_udoo_platform_manifest -b android-6.0.1
$ ~/bin/repo sync -jN #N is the number of parallel jobs

Building Android

We have an environment and the code, then we're ready to build an Android image.
Launch the environment we've created some sections before:

$ rbld run android-m:v1

You'll notice that you're now inside our build environment. This environment is isolated from your host system but the host and the environment share the filesystem. You may be now at the root of Android's source code.
Set ARCH environment variable, then source the envsetup.sh:

$ export ARCH=arm
$ source build/envsetup.sh

In the Android build system, you can choose configurations among a list of options, to show up that list, simply type lunch on the terminal.
For UDOO-NEO we have two options:

udooneo_6sx-eng
udooneo_6sx-user Eng version integrates some debug tools that are not available in user images. Let's build an eng version for now:

$ lunch udooneo_6sx-eng

OK, to build it type m:

$ m

You can check Android's build system commands with the command hmm:

$ hmm

The build artifacts reside in out/ directory. You can use make_sd.sh script to create an sd-card and boot up your new Android image on the board.

$ cp make_sd.sh out/target/product/udooneo_6sx
$ cd out/target/product/udooneo_6sx
$ sudo -E ./make_sd.sh /dev/sdx

Troubleshooting

arm-eabi-gcc: error: backports/drivers/net/wireless

arm-eabi-gcc: error: backports/drivers/net/wireless
/ti/wlcore/main.c: No such file or directory
arm-eabi-gcc: fatal error: no input files
compilation terminated.

Solution:

cd kernel_imx/
make mrproper
cd ..
Make

make: *** No rule to make target ... liblz4-static_intermediates

make: *** No rule to make target `out/target/product/udooneo_6sx/obj/STATIC_LIBRARIES/liblz4-static_intermediates/export_includes', needed by `out/target/product/udooneo_6sx/obj/EXECUTABLES/updater_intermediates/import_includes'.  Stop.

Solution:
Include the lines below to extenal/lz4/lib/android.mk and build again:

include $(CLEAR_VARS)
LOCAL_MODULE := liblz4-static
LOCAL_SRC_FILES := $(liblz4_src_files)
LOCAL_MODULE_TAGS := optional
include $(BUILD_STATIC_LIBRARY)

References

Let's talk about documentation...

Ronaldo Nunez — Thu, 22 Oct 2020 21:48:09 +0000

Documentation is so important that no project should be considered as done without it. Well, at least it would be better if that affirmation was true all the time. Those who work on legacy projects understand what I said at the top of this paragraph.

No rarely you'll find yourself working in complete darkness, looking for information and data from old projects, and finding absolutely nothing.

That's the main reason I decided to share below some aspects that I consider important regarding project documentation as well as some tips and tricks making it easier to get started. Then you can make life easier for those that'll maintain the project that you're currently working on.

Documentation is all about future and collaboration

When you write down things you're working on, you're collaborating with you, in the future. Believe me, some point in the future you or one of your teammates will need to know how the different modules of a project interact, or why you'd chosen a library/technology instead of another one. I understand that code should be clear enough to drop comments out, but code doesn't show the big picture for those reading it.

For instance, imagine a scenario where you receive the task to implement a simple feature in an old system. So to get it started, you'll need to find its repository, the instructions to build it, a brief explanation of how it works, and about its architecture. You won't find that in code!
That kind of information is also valuable for the newcomers in your company and for your mates too.
It's a good idea to have a place (I mean a virtual one) where you and your colleagues can write down about you're working on - put everything there: repository URLs, build instructions, architecture diagrams, etc.

Documentation must be broadly accescible

Word and PDF are not good documentation containers. Of course, that doesn't apply for delivery documentation or any other kind of static doc, as a release note, for instance. Even with all recent efforts of Microsoft and Adobe on improving them editor/reader apps, it's hard to find what you are looking for on them, and also they weren't originally designed with collaboration in mind. Moreover, those kinds of files are shared through e-mails or instant messengers, so only peers involved in the conversation can easily access them.
Instead of docs and PDFs, prefer wiki or blog like tools. They usually provide versioning systems as well as embedded search engines, then it won't be hard to find old project docs and collaborate on them. Even bug/project tracking systems, as Jira or Bugzilla can help you and your team to keep track of project history and show you how you solved issues you'd faced during development.

README is your friend

I know: code maintenance is hard, and documentation maintenance is even harder! For that reason, a readme file is a good idea. Since it's near to the source code, you'll find it easy to maintain it. Modern versioning system frontends can interpret markdown readmes, so it's easy to enrich them with pictures, diagrams, bullets, etc.
Readme files can be a good start point, especially for coders. A good readme may contain a building howto, a description of the project, usage examples, and so on.
A diagram says more than a thousand words
Need to show how modules talks to each other? Prefer a diagram to explain it. You'll save time for those that'll read it.
Lazy about drawing them on an app? Do it on a whiteboard and take a picture. Mobile scanner apps may save some time drawing and can make them easy to read on collaboration tools.

...

I know that writing docs is boring and time-consuming, but it worth it. Keep in mind that people will work someday on what you're working on today, so they'll depend on what you left for consulting. Maybe code can describe itself, but projects no.
All that I said may seem to be obvious for you but you can't imagine how many times I faced a lack of documentation in my career, which reinforces the importance to talk about it.

DEV Community: Ronaldo Nunez