<mkasick> a flashable zip has to have "META-INF/com/google/android/update-binary" which is invoked by recovery
<mkasick> the usual update-binary is compiled from AOSP or CM sources, if you follow the source.android.com directions for obtaining AOSP sources, you can make it with "make out/target/product/generic/system/bin/updater; cp -a out/target/product/generic/system/bin/updater update-binary"
<mkasick> that update-binary also requires "META-INF/com/google/android/updater-script" in the zip, which in recent Android is "edify" format, there's a bunch of tutorials on writing edify updater-scripts
<mkasick> some update.zips are signed, as stock/AOSP recovery checks the signature and verifies the zip contents before installing, although CWM is modified to disable the signature check by default
<mkasick> Samsung stock recovery uses a signing key we don't know, but AOSP defaults to a well-known key "testkey"
<mkasick> the public keys is actually contained in /res/keys of a recovery initramfs, so some custom kernels use the testkey public key instead so they can flash testkey-signed zips
<mkasick> zips are signed using signapk.jar, which can also be made from AOSP sources ("make out/host/linux-x86/framework/signapk.jar")
<mkasick> http://www.club.cc.cmu.edu/~mkasick/android/tools/signapk.tar.gz is a compiled version I built
<mkasick> that archive also includes the testkey keypair and a README that demonstrates how to use it to sign an update.zip
<mkasick> particularly notable (or rather, it took me a good while to figure out) is that you have to invoke signapk.jar with "-w" to sign the "whole zip", which is required for update.zips and nothing else in Android to my knowledge
<mkasick> on packaging .apks
<mkasick> source-built apks are packaged when buiding from AOSP/CM sources, or from the Android SDK
<mkasick> it's a blackbox mechanism as far as I'm concerned
<mkasick> if you want to repackage an existing apk, apktool (https://code.google.com/p/android-apktool/) is probably the best