AOSP · BSP · Platform engineering

We make Android boot on your hardware.

Ftechiz is an Android platform engineering team. We take custom boards from schematic to shipping image — BSP development, kernel and driver work, HAL implementation, and the certification path that gets you approved.

Start a project Explore services

AOSP: 10 → 16
Linux kernel: 4.19 → 6.x
Silicon vendors: 12+
Suites: CTS · VTS · GTS

build@ftechiz — aosp

$ repo init -u $AOSP_URL -b android-16.0.0_r1
$ repo sync -c -j16 --no-tags
  Fetching: 100% (1108/1108), done.
$ source build/envsetup.sh
$ lunch ftechiz_evk-userdebug
  TARGET_PRODUCT=ftechiz_evk
  TARGET_ARCH=arm64  PLATFORM_VERSION=16
$ m -j32 dist
  [100%] boot.img · vendor.img · super.img
  #### build completed successfully ####
$ fastboot flashall -w
  device booted · vintf ok · selinux enforcing
$

Where we work

The layers between your silicon and your product

A board support package is everything that has to exist before your application team can write a single line of code. That is the part we build.

We work from the bootloader up to the framework — the layers your silicon vendor ships as a rough reference and your app team should never have to think about.

How a bring-up runs

Applications

Your product apps, launcher, system UI

Android Framework

System server, Car API, custom system services, platform SDK

Native libraries & ART

Bionic, media stack, graphics libraries

HAL — AIDL / HIDL

Camera, audio, sensors, power, VHAL, graphics, connectivity

Linux kernel

GKI + vendor modules, device drivers, device tree, power & thermal

Bootloader & secure boot

U-Boot / LK / ABL, AVB, TEE, partition layout

Silicon

Qualcomm · MediaTek · NXP · Rockchip · TI · Renesas · NVIDIA

We build and ownYou or your silicon vendor

Services

Platform engineering, end to end

Take one workstream or the whole programme. Most engagements start with a bring-up and grow into long-term platform maintenance.

BSP Development & Board Bring-Up

From a bare board and a vendor SDK to a booting, stable Android image with your peripherals working.

Linux Kernel & Device Drivers

Driver development, kernel porting and GKI compliance — plus the debugging work nobody else wants.

Android HAL Development

AIDL and HIDL HALs that connect your silicon to the Android framework and pass VTS.

Android Automotive OS

Vehicle HAL, CarService integration and cluster/IVI bring-up for automotive programmes.

CTS, VTS & GMS Certification

Test suite automation and failure triage that takes a device from first run to GMS approval.

OTA Updates & Platform Security

A/B update infrastructure, verified boot and SELinux policy so the fleet stays updatable and locked down.

Custom Android Platform & Framework

Framework modification, custom system services and locked-down device experiences built on AOSP.

Embedded Linux & Yocto

Yocto and Buildroot distributions for devices that need Linux without the Android stack.

Silicon

Platforms we bring up

We work with the vendor BSP you already have — and with the parts of it that do not match your board.

All platforms

Qualcomm

Snapdragon mobile, QCS / QCM IoT, SA automotive

MediaTek

Genio IoT, Dimensity, MT8xxx

NXP

i.MX 8, i.MX 8M Plus, i.MX 93 / 95

Rockchip

RK3588 / RK3576 / RK3568

Texas Instruments

AM62, AM62A, Sitara, Jacinto

Amlogic

S9xx series

Renesas

R-Car series

NVIDIA

Jetson Orin, Tegra

Samsung

Exynos

Allwinner

A-series, T-series

Intel

x86 Android, Celadon

Broadcom

Connectivity and STB SoCs

How we work

A bring-up, run properly

Four phases. You get working hardware early and a platform you can maintain at the end.

01
Scoping
We read your schematic, your SoC's BSP and your certification target, then come back with a scope that names the real risks — not a generic proposal.
02
Bring-up
Bootloader, kernel and device tree first, then peripherals in dependency order. You get a booting board early and weekly builds you can put on hardware.
03
Hardening
HALs, SELinux policy, verified boot and the OTA path. Test suites go into CI here, so the certification failure list shrinks while development continues.
04
Certification & handover
Suites down to zero, submission evidence prepared, and a documented build your team can take over — or that we maintain through the security bulletin cycle.

Engagement models and team structure

Why Ftechiz

Deep in the stack, and documented

We work below the framework

Most Android shops stop at the app layer. Our work starts where theirs ends — in the bootloader, the kernel, the device tree and the vendor interface.

Reproducible by default

Pinned manifests, documented builds and CI from the first week. If only one engineer can build your image, you do not have a platform — you have a liability.

Certification is planned, not discovered

CTS and VTS run in CI from early in the programme, so approval is a milestone with a date rather than an open-ended risk at the end.

Built to be handed over

Readable device trees, real commit messages and written bring-up reports. You should be able to take the platform in-house whenever you choose.

Tell us about your board.

Send us the SoC, the form factor and your certification target. We will come back with a scope, a timeline and the risks worth worrying about.

Start a project See our work