| 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 |
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!