Architecting Amp: Android integration with embedded systems
summary
Lyft builds a BLE LED device called Amp that uses a 26-page device protocol of byte commands (op code + args) to start/stop animations, report battery and status, and authorize users; Android code scans, connects via GATT, enables a response characteristic, writes commands, and parses notifications. Hardware is outsourced, animations and firmware arrive as zip files on S3 and are uploaded by a pack/firmware service. Production numbers: 125,000 drivers, 4 million rides per month, millions of brand impressions; the system is deployed and actively drives animations on drivers’ front and rear LED screens.
AI-written summary · about
chapters (6)
- 0:00Introduction and speaker background
- 1:24Product requirements and AMP overview
- 3:33Hardware and device protocol
- 6:39Android integration and SDK
- 10:29Architectural breakdown in Lyft
- 13:39Impact and conclusion
related talks
45mScaling Architecture at Lyft
32mWhat Is the Best Architecture for Android Apps That Integrate Closely with External Devices?
01h 00mAndroid builds
24mCreating the Lyft Driver App: Reduce, Reuse, Recycle
39mTalking to your bike and other devices (wait, what?)
38mDeveloping Apps for Android Auto.
31mSoftware Defined Vehicle and Android Automotive OS
19mHow we brought the Uber Driver App to Android Auto