Senior AOSP / Embedded Android / BSP Engineer for Industrial IoT Device

We are looking for an experienced AOSP / Embedded Android Engineer to work on a commercial embedded Android panel used in an industrial tyre inflator and digital advertising system. This is not a standard Android mobile application development role. We need someone with hands-on experience in AOSP source builds, BSP integration, Linux kernel and device-level hardware interfaces, embedded Android firmware, serial communication, GPIO, watchdog mechanisms, kiosk systems, and production device deployment. The selected engineer will initially help us evaluate the target hardware platform, BSP quality, technical feasibility, architecture, dependencies, and implementation plan. Subject to successful evaluation, the role may continue into full development and production integration. Project Overview The system uses an embedded Android display panel that acts as a local controller, digital signage player, hardware communication device, telemetry source, and analytics platform. The Android panel is expected to integrate with: Automatic tyre inflator hardware through RS485 Manual/mechanical pump signals through GPIO Integrated camera hardware Hardware watchdog where supported Display and touchscreen hardware Network connectivity Backend/cloud services through MQTT and APIs Local media storage and playback Device health and telemetry monitoring The device is expected to operate for long periods in unattended commercial environments and must recover automatically from application crashes, abnormal states, system freezes, network interruptions, and power loss. Key Responsibilities The engineer will be expected to work on some or all of the following areas: Build and customize AOSP for the selected embedded Android panel Review and integrate the panel manufacturer’s BSP Review kernel source, device tree configuration, vendor drivers, HAL components, proprietary binaries, SDKs, and flashing tools Configure and maintain reproducible AOSP build environments Produce flashable production firmware images Customize boot behavior and startup flow Configure automatic launch of the main application after boot Implement or support kiosk/lockdown operation Restrict access to Android settings and consumer-facing system features Disable unwanted system dialogs, notifications, update prompts, sleep behavior, and interruptions Support privileged/system application deployment where required Support secure technician or maintenance access Investigate and resolve boot, driver, framework, permission, SELinux, and hardware-access issues Linux Kernel / BSP Responsibilities Depending on the selected hardware and existing BSP support, responsibilities may include: Review existing Linux kernel configuration Review and modify device tree configuration where necessary Integrate or adapt vendor drivers where required Diagnose hardware interface issues Work with kernel logs, boot logs, dmesg, logcat, sysfs, procfs, and device nodes Support hardware watchdog integration Support GPIO access Support serial/UART/RS485 interfaces Support hardware monitoring interfaces Investigate camera integration issues where required Work with vendor-specific kernel branches and BSP patches Optimize build/flash/debug cycles Document all kernel, BSP, and device-specific modifications We do not assume that every hardware interface requires a new custom kernel driver. The engineer must first assess what is already supported by the BSP, kernel, vendor SDK, HAL, or existing Linux device interfaces and recommend the lowest-risk implementation. RS485 Integration The system must communicate directly with automatic tyre inflator hardware through RS485. Expected responsibilities include: Identify and validate the available RS485 hardware interface Determine whether the interface is native RS485, UART-based, USB-based, or vendor-specific Expose reliable serial read/write access to Android applications or system services Support configurable baud rate, parity, data bits, and stop bits Identify and document Linux device paths such as /dev/ttyS* or equivalent Handle Android permissions and SELinux requirements Support stable long-running communication Support disconnect/reconnect recovery Support protocol framing and checksum/CRC integration where required Provide an application-facing API, native service, JNI layer, SDK wrapper, or other appropriate architecture Provide sample code and technical documentation GPIO Integration The system must support GPIO-based signal detection for manual/mechanical pump configurations. Expected responsibilities include: Review GPIO pin mapping Validate electrical and software interface assumptions with the hardware team Expose stable GPIO high/low state access Support periodic polling or event-driven access where appropriate Avoid false triggering Handle permissions and production access Provide application-facing API or service Document GPIO mappings and behavior Provide sample integration code Watchdog and Automatic Recovery The device must operate unattended and recover from failures. Expected responsibilities include: Evaluate available hardware watchdog support Integrate watchdog functionality where supported Provide safe watchdog feed mechanisms Support application crash recovery Support automatic application restart Support reboot on unrecoverable system state where technically appropriate Support automatic recovery after power loss Ensure the system returns to the main application rather than launcher/settings Document watchdog timeout and recovery behavior Provide test procedures for failure simulation Camera Integration The panel includes an integrated camera. Expected responsibilities may include: Validate camera operation on the target BSP Review Camera HAL and driver support Ensure reliable camera access from Android application or system service Diagnose camera stability issues Support long-duration operation Coordinate with the analytics/computer-vision engineer Document hardware and software limitations Advanced computer vision analytics may be handled by another engineer, but strong camera integration experience is valuable. Device Monitoring and Telemetry Support The Android system should expose available device health information, potentially including: CPU usage RAM usage Storage usage Application storage Network status Wi-Fi signal strength CPU temperature Board temperature eMMC health where available Device uptime Boot count Last reboot reason where available Android version Firmware version Application version Serial number or stable device identity The engineer should determine which metrics are actually available from the BSP/hardware and expose them through documented APIs, system services, commands, or file paths. MQTT / Backend Connectivity Support The panel application will communicate with backend services through MQTT and APIs. The AOSP engineer may be expected to support: Stable network behavior Device identity access Certificate and credential storage MQTT over TLS requirements Background connectivity behavior Automatic reconnection support Correct system time synchronization Network recovery after interruption Required privileged APIs or system services Coordination with Android application and backend engineers The engineer is not expected to build the complete backend platform. Media Playback Support The panel will continuously display advertisement videos and still images. Expected OS-level responsibilities include: Validate hardware video decoding Validate stable long-duration playback Ensure Android does not interrupt playback Support local storage of downloaded media Support required storage permissions Configure display resolution and orientation Configure brightness and sleep behavior Investigate codec or hardware-decoding issues where required The final advertisement player application may be developed by a separate Android application team. Security Responsibilities Expected areas include: Production ADB strategy Secure enable/disable mechanism for debugging Restrict unnecessary system services Restrict unnecessary ports Protect system settings Secure privileged application permissions SELinux policy changes where genuinely required Secure credential/certificate storage Prevent unauthorized application installation where required Support production device lockdown Required Experience Applicants should have strong hands-on experience with several of the following: AOSP source code Custom Android firmware Embedded Android Android BSP integration Linux kernel Device tree Android HAL Vendor SDK integration Android framework customization System applications Privileged applications JNI / NDK Native C/C++ Java/Kotlin Linux device nodes Serial/UART communication RS485 GPIO Watchdog SELinux Android boot process init.rc system services Binder/AIDL Camera HAL Android permissions Firmware flashing OTA/update architecture Embedded device debugging Strongly Preferred Experience Experience with one or more embedded SoC platforms is highly desirable, for example: Rockchip NXP i.MX Qualcomm MediaTek Amlogic Allwinner Other commercial ARM-based Android platforms Experience with industrial panels, kiosks, POS terminals, automotive systems, digital signage, IoT gateways, or unattended commercial Android devices is highly valuable. Initial Phase / First Deliverable We do not want development to begin blindly. The first phase will be a paid technical feasibility and architecture assessment. The engineer will review: Exact panel model SoC/chipset Android version BSP availability AOSP source availability Kernel source availability Device tree Vendor drivers Proprietary dependencies GPIO mapping RS485 architecture Camera support Watchdog support Flashing method Build environment Hardware documentation Pump communication protocol Known technical risks Expected first-phase output: Feasibility report BSP quality assessment Hardware dependency list Technical risk register Recommended architecture AOSP customization plan Kernel/BSP modification assessment RS485 integration plan GPIO integration plan Watchdog plan Camera integration assessment Development environment recommendation Estimated engineering timeline Identification of blocking dependencies Important Application Questions Please answer all of the following when applying: How many years of hands-on AOSP development experience do you have? Have you built AOSP from source for real commercial hardware? Please describe the device and SoC. Which SoC platforms have you worked with? Have you modified Android BSPs? Have you worked directly with Linux kernel source and device trees? Have you integrated GPIO into an Android application or system service? Have you implemented RS485 or UART communication on embedded Android? Have you worked with /dev/ttyS* or similar Linux serial device nodes from Android? Have you created system apps or privileged Android apps? Have you modified SELinux policies for legitimate hardware access? Have you implemented watchdog or automatic recovery mechanisms? Have you worked with Camera HAL or embedded camera integration? Have you implemented kiosk/lockdown behavior at firmware or framework level? Can you provide examples of production firmware you have worked on? Are you comfortable working with physical hardware and repeated build/flash/debug cycles? What workstation or build-server configuration do you normally use for AOSP development? Are you available for a long-term project of approximately 9–12 months? What would you require from the panel manufacturer before starting? Please Do Not Apply If Please do not apply if your experience is primarily limited to: Standard Android mobile apps Flutter React Native Basic Kotlin/Java applications Android Studio application development without AOSP experience Rooting consumer phones Installing custom ROMs without source-level BSP work We specifically need engineers with real source-level AOSP, BSP, embedded Android, Linux kernel, and hardware integration experience. Engagement Long-term project Estimated duration: suggest Initial engagement: paid feasibility/architecture phase Potential continuation into implementation and production integration Remote collaboration Regular technical communication required Source code and technical documentation required NDA may be required