[mdwrigh2]

> The ritual to compile, pack and flash super.img into the device is absurd.

I typically only do a full flash for the first build after a sync. Afterwards I just build the pieces I'm changing and use `adb sync` to push them to the device, skipping both the step that packs the image files and the flash. The `sync` target will build just the pieces needed for an `adb sync` if you don't know exactly what you need to build; I typically use it so I don't have to even think about which pieces I'm changing when rebuilding.

So typical flow goes something like:

``` // Rebase is only needed if I have existing local changes > repo sync -j12 && repo rebase

// I don't actually use flashall, we have a tool internally that also handles bootloader upgrades, etc. > m -j && fastboot flashall

// Hack hack hack... then: > m -j sync && syncrestart ```

Where `syncrestart` is an alias for:

``` syncrestart () { adb remount && adb shell stop && sleep 3 && adb sync && adb shell start } ```

Incremental compiles while working on native code are ~10 seconds with this method. Working on framework Java code can be a couple minutes still because of the need to run metalava.

[scoutt]

This is really nice tip.

AFAIK, sync works on Linux only since it needs $ANDROID_PRODUCT_OUT. The problem is that I develop on a Windows machine (vscode with ssh extension) and my source code is on remote Linux machines (in premises), dedicated to building AOSP. Since I build at least for another 5 platforms, my working PC cannot cope with the current (and future) workload/space, so I asked to move all the source to dedicated hardware for building. Perhaps I can do it with ADB through Wifi...

I always thought sync worked with frameworks or packages, but since you mentioned "native" I guess it will also sync vendor stuff?