Ask HN: Where to Start with Android Custom ROM or AOSP Development?
24 comments
Personally, I'd stick for experimenting with something well supported by LineageOS - to get started, Pixel 3 or later series. These are as close to AOSP as you can get. The Pixel 6 is the most current model to be supported by Lineage, and at least stock firmware will get you security updates until at least 2026.
Stay away from Samsung (their Knox security stuff and custom bootloader is nasty, Samsung deviates quite a lot from Android standards under the hood and their ODIN firmware flash tool isn't available publicly and cracked versions only for Windows), Xiaomi and Huawei devices (different partition layout, custom bootloader) and obscure Chinese no-name devices as for them you will have to do a lot of leg work regarding drivers or even basic tooling setup on your own.
For development, stay the hell away from Windows if you can, if possible also from macOS. You're best served with a Linux machine.
Stay away from Samsung (their Knox security stuff and custom bootloader is nasty, Samsung deviates quite a lot from Android standards under the hood and their ODIN firmware flash tool isn't available publicly and cracked versions only for Windows), Xiaomi and Huawei devices (different partition layout, custom bootloader) and obscure Chinese no-name devices as for them you will have to do a lot of leg work regarding drivers or even basic tooling setup on your own.
For development, stay the hell away from Windows if you can, if possible also from macOS. You're best served with a Linux machine.
All good advice.
If the OP owns a Pixel, and he is compiling LineageOS (or AOSP), a first target to consider is - an emulator (AVD). Emulators are easy to create on the fly, you don't have to worry about what its particular quirks are, or if it uses an A/B partitioned system for OTA, or worry about accidentally bricking it. And if you have emulator A but accidentally compiled for emulator B, you can just create emulator B.
These are the devices LineageOS supports - https://wiki.lineageos.org/devices . You may note that some of these devices are older, and probably not in sale in local stores. So make a note of which phones on this list you can go to a local store and buy today. Last year, I looked around for cheaper Motorola phones, but they were the previous year's model and harder to find at a local store, so I got a Motorola Edge 5G and successfully compiled LineageOS and sideloaded it. You can get the devices however you want, but check this list for what is supported by LineageOS, then check how easy they are to get (as I said, some of these devices are years old and are harder to find).
If the OP owns a Pixel, and he is compiling LineageOS (or AOSP), a first target to consider is - an emulator (AVD). Emulators are easy to create on the fly, you don't have to worry about what its particular quirks are, or if it uses an A/B partitioned system for OTA, or worry about accidentally bricking it. And if you have emulator A but accidentally compiled for emulator B, you can just create emulator B.
These are the devices LineageOS supports - https://wiki.lineageos.org/devices . You may note that some of these devices are older, and probably not in sale in local stores. So make a note of which phones on this list you can go to a local store and buy today. Last year, I looked around for cheaper Motorola phones, but they were the previous year's model and harder to find at a local store, so I got a Motorola Edge 5G and successfully compiled LineageOS and sideloaded it. You can get the devices however you want, but check this list for what is supported by LineageOS, then check how easy they are to get (as I said, some of these devices are years old and are harder to find).
Pixel 6a, 6 and 6 Pro don't have LOS yet -- at least stable.
I don't remember why.
Pixel 6a are at a "good" price by western measures -- €350
Pixel 6a are at a "good" price by western measures -- €350
For Samsung devices there's Heimdall, an open source tool to flash firmware like Odin does.
https://glassechidna.com.au/heimdall/
https://glassechidna.com.au/heimdall/
Doesn't work on any recent macOS version, which is part of the problem.
> Samsung
Samsung also sells "Euro spec" (can install new bootloader) and "America spec" (locked in hardware) phones under the same SKU. You can't tell the difference until you try to flash it. I got bit by that one.
Samsung also sells "Euro spec" (can install new bootloader) and "America spec" (locked in hardware) phones under the same SKU. You can't tell the difference until you try to flash it. I got bit by that one.
That's ridiculous. I wonder two things... why is this even legal, and why does Samsung do this in the first place?
Anyway, for a lot of US models, there are ways to get them unlocked [1].
[1] https://www.thecustomdroid.com/samsung-galaxy-bootloader-unl...
Anyway, for a lot of US models, there are ways to get them unlocked [1].
[1] https://www.thecustomdroid.com/samsung-galaxy-bootloader-unl...
I have a Samsung Tab S8 Ultra that's US spec and the bootloader is unlocked and it's rooted.
The same goes for phone you buy DIRECT FROM SAMSUNG.
The locked ones are the ones you get from Verizon / AT&T / etc.
The same goes for phone you buy DIRECT FROM SAMSUNG.
The locked ones are the ones you get from Verizon / AT&T / etc.
Depends on your cellular coverage too!:
Pixel 3 - 4G
Pixel 4 - LTE Advanced
Pixel 5 - 5G (avoid Verizon's non-unlockable Pixel5), possible battery drain due to stuck G5 firmware
Pixel 6 - better choice (again, avoid Verizon-brand)
Pixel 3 - 4G
Pixel 4 - LTE Advanced
Pixel 5 - 5G (avoid Verizon's non-unlockable Pixel5), possible battery drain due to stuck G5 firmware
Pixel 6 - better choice (again, avoid Verizon-brand)
AKLU's channel is great for this.
https://youtube.com/c/AlaskaLinuxUserAKLU
https://youtube.com/c/AlaskaLinuxUserAKLU
Holy moly, that guy's videos are thorough!
AKLU, if you see this (even if you don't), this is some very informative content!
AKLU, if you see this (even if you don't), this is some very informative content!
I second that, and wholeheartedly recommend the official documentation. It might not be the best entry point, but it is a good reference throughout.
In particular, understanding the repo tool, manifests, etc. is also quite necessary to get started.
Obviously, there is a lot more to working on custom ROMs than that. I've seen a few resources mentioned in other threads that seem great for that.
In particular, understanding the repo tool, manifests, etc. is also quite necessary to get started.
Obviously, there is a lot more to working on custom ROMs than that. I've seen a few resources mentioned in other threads that seem great for that.
Why not contribute or extend existing projects like GrapheneOS or LineageOS? These both have excellent time-tested documentation.
If you stay out of the weeds in the community and focus on the technical aspects, you can easily get a supported device up and running with your own signing key, update server, and everything else needed.
I did for years, before switching to GrapheneOS.
If you stay out of the weeds in the community and focus on the technical aspects, you can easily get a supported device up and running with your own signing key, update server, and everything else needed.
I did for years, before switching to GrapheneOS.
Iskren has written up a lot of good guides on how to customise a AOSP ROM, use it to extract firmware blobs, and ultimately mainline the device to get it to run modern Linux OS's like PostmarketOS.
Its a really comprehensive hand-holding guide, written in a very engaging way:
https://mainlining.dev/
There is also the mainlining guides at postmarketOS wiki, though these are harder to understand in my opinion:
https://wiki.postmarketos.org/wiki/Mainlining_Guide
Its a really comprehensive hand-holding guide, written in a very engaging way:
https://mainlining.dev/
There is also the mainlining guides at postmarketOS wiki, though these are harder to understand in my opinion:
https://wiki.postmarketos.org/wiki/Mainlining_Guide
The best long term case for AOSP ROM development is probably Droidian. Run the vendor-provided downstream kernel and binary drivers, but keep everything else (i.e. the actual system image) as close as possible to a generic Linux distribution. (Apparently, recent version of AOSP have made this kind-of feasible by reducing the delta between normal Linux and AOSP-specific kernels.)
Take a look at postmarketOS (https://postmarketos.org/), it is sort of "custom ROM", but it builds not Android OS, but Linux for your phone. Depending on your goals it might be easier to start than AOSP.
I'm happy to see some interest in custom ROM. I personally think that nowadays this is the best way for a software engineer to have a meaningful impact on their own daily life.
If your goal is just to peak behind the curtain and see how those things gets built other comments will probably be more relevant than mine.
You'll need a pretty beefy Linux machine 200GB SSD storage, 32GB RAM, >8 CPU cores is recommended. You can go lower, but it becomes painful for development. ROM developers with less resources than that build on VPS.
If you want to start developing things Android-side (which means not the hardware/driver parts), I recommend:
- Use GSIs (Generic System Image) -- often on custom rom, it's a pain to build device-specific ROMs because you're always missing parts, and dependent on just the one developer maintaining that device. GSIs are more likely to be less painful to work with
- You can launch Android Studio inside AOSP using aidegen (I don't remember the exact syntax). For development on app-side (like if you want to change the UI) this will help a lot (but eat even more RAM)
- Android build system is very robust when it comes to incremental build, you should never have to clean anything. Maybe in some cases you might need `make installclean`, but except in horrible cases, that's all.
- You can build and replace specific components. For instance, if you just want to do quick cycle development on SystemUI, you can do `make SystemUI` to just build SystemUI, and replace it on your device with `adb root; adb remount; adb push out/target/product/xxxx/system/priv-app/SystemUI/SystemUI.apk /system/priv-app/SystemUI/SystemUI.apk` and soft-reboot android with `adb shell 'stop;start'`. Some components are APKs that can simply be installed, in which case you don't even need to soft-reboot android, and adb install -r out/target/product/xxxx/system/priv-app/Settings/Settings.apk` will do the trick
If you start developing "long term", consider that AOSP changes A LOT from one version to another, and Google has really no remorse to break stuff inside AOSP (not blaming, just stating), so always consider making apps rather than changing things inside Android framework. (Android has a notion of "system" and "privileged" apps, that can do a lot more than standard apps. The API you need to use in that case is not guaranteed, but it's less likely to move). If you can't make things into apps, then implement your feature with the lowest possible entry points coming from AOSP.
Once you got your first builds up and running, started trying to develop changes and know what change you want to do, feel free to ping me for pointers: phh on libera or @phhusson on telegram
FWIW, if it's of any use, a "oneliner" to build my AOSP GSI (so a "pure" AOSP, that will work on 95%+ of Android devices that are less than 4 years old): mkdir build; cd build; repo init -u https://android.googlesource.com/platform/manifest -b android-12.1.0_r14 ; git clone https://github.com/phhusson/treble_manifest -b android-12.0 .repo/local_manifests; repo sync -j12; (cd device/phh/treble;bash generate.sh);. build/envsetup.sh ; lunch treble_arm64_bvS-userdebug; make -j128
And image appears in out/target/product/phhgsi_arm64_ab/system.img
If your goal is just to peak behind the curtain and see how those things gets built other comments will probably be more relevant than mine.
You'll need a pretty beefy Linux machine 200GB SSD storage, 32GB RAM, >8 CPU cores is recommended. You can go lower, but it becomes painful for development. ROM developers with less resources than that build on VPS.
If you want to start developing things Android-side (which means not the hardware/driver parts), I recommend:
- Use GSIs (Generic System Image) -- often on custom rom, it's a pain to build device-specific ROMs because you're always missing parts, and dependent on just the one developer maintaining that device. GSIs are more likely to be less painful to work with
- You can launch Android Studio inside AOSP using aidegen (I don't remember the exact syntax). For development on app-side (like if you want to change the UI) this will help a lot (but eat even more RAM)
- Android build system is very robust when it comes to incremental build, you should never have to clean anything. Maybe in some cases you might need `make installclean`, but except in horrible cases, that's all.
- You can build and replace specific components. For instance, if you just want to do quick cycle development on SystemUI, you can do `make SystemUI` to just build SystemUI, and replace it on your device with `adb root; adb remount; adb push out/target/product/xxxx/system/priv-app/SystemUI/SystemUI.apk /system/priv-app/SystemUI/SystemUI.apk` and soft-reboot android with `adb shell 'stop;start'`. Some components are APKs that can simply be installed, in which case you don't even need to soft-reboot android, and adb install -r out/target/product/xxxx/system/priv-app/Settings/Settings.apk` will do the trick
If you start developing "long term", consider that AOSP changes A LOT from one version to another, and Google has really no remorse to break stuff inside AOSP (not blaming, just stating), so always consider making apps rather than changing things inside Android framework. (Android has a notion of "system" and "privileged" apps, that can do a lot more than standard apps. The API you need to use in that case is not guaranteed, but it's less likely to move). If you can't make things into apps, then implement your feature with the lowest possible entry points coming from AOSP.
Once you got your first builds up and running, started trying to develop changes and know what change you want to do, feel free to ping me for pointers: phh on libera or @phhusson on telegram
FWIW, if it's of any use, a "oneliner" to build my AOSP GSI (so a "pure" AOSP, that will work on 95%+ of Android devices that are less than 4 years old): mkdir build; cd build; repo init -u https://android.googlesource.com/platform/manifest -b android-12.1.0_r14 ; git clone https://github.com/phhusson/treble_manifest -b android-12.0 .repo/local_manifests; repo sync -j12; (cd device/phh/treble;bash generate.sh);. build/envsetup.sh ; lunch treble_arm64_bvS-userdebug; make -j128
And image appears in out/target/product/phhgsi_arm64_ab/system.img
Oh hi! Thanks for your GSI!
Currently on Pixel 6a but before was on Xiaomi Mi A3 -- laurel_sprout. I largely ignored GSI because I assumed most important things were broken and tried to focus on a non-GSI ROM (and later gave up). (Just rechecked now and it requires some random files stored on random Google Drives so I ignore them).
Anyway I explored your work for some time and it seemed very cool, so thanks for it!
Currently on Pixel 6a but before was on Xiaomi Mi A3 -- laurel_sprout. I largely ignored GSI because I assumed most important things were broken and tried to focus on a non-GSI ROM (and later gave up). (Just rechecked now and it requires some random files stored on random Google Drives so I ignore them).
Anyway I explored your work for some time and it seemed very cool, so thanks for it!
How do I give you money or make you happier otherwise?
Your comment is already pretty great :-) I used to ask donations, thinking every donation no matter the size would warm my heart, but it doesn't really work (unless it's big enough for me to buy new smartphones for debugging). I do take donations at https://github.com/sponsors/phhusson
What makes me happier is seeing people using my work, either users' feedback telling me why my work is useful for them, or developers creating new things based on my work (the weirder the usage the better)
What makes me happier is seeing people using my work, either users' feedback telling me why my work is useful for them, or developers creating new things based on my work (the weirder the usage the better)
https://wiki.lineageos.org/build_guides
You'll need to figure out which model you have though
You'll need to figure out which model you have though
Thanks!