Try baksmali Mms again
Merge remote-tracking branch 'origin/master' into baksmali
Version-up
Implement check for missing baksmali'd apks

This allows ROMS without Mms.apk to go through without incident (wifi tablets,
specifically). This check already exists in the apktool handling, but when
using baksmali, the apk is treated like a jar file.

With this implementation, missing jar files still error, since they are all
necessary for operation.

closes #138
Hack to fix build query for Final builds

Not going to successfully retrain the userbase, that's for sure.
New CM10 patches (a check)
Fix new BID_OVERRIDE

It was overriding all CMs as written.
Add provisional that allows support for certain off-brand PA roms

This is a test. User response will tell us ho it goes.
Change files.txt symbol on the baksmali'd apks from "~" to "@"

Originally, all *apk files were decompiled with apktool. I added the ability
to decompile apks using baksmali binary instead, by prefacing the apk file
with a tilde (in the files.txt). However...

Cygwin was using shell expansion on the tilde and looking for the Mms file
in the home directory. So I have used a(n unfortunately unrelated) new symbol.
Now the question becomes, was this latest "disappearing" Mms.apk fix fools gold,
 since they may just have seen their original in the app drawer. Argggggh.
Merge branch 'master' of https://github.com/mateor/auto-patcher
Hide the "tpu not found" errors in Cygwin

Cygwin is not a full unix environment, and does not always have access to all
the utilities by default. Turns out tput is one of those. Put I am just
using that to output some color to the successful patching, trying to cut
down on the erroneous bug reports. This redirects to stderr.
Change leftover tilde to @ for baksmali's apks

This was removing Mms.apk from scope and not patching it.
Fix function to prioritize "pdroid"-type mods

This function was meant to take any list of requested mods, and re-order them with
any "pdroid"-type mods to be applied first. This is needed because of the "provisional"
use--where we sometimes copy over smali files we know will patch for troublesome roms.

Since copying over smali files would clobber any patches applied before the copy, it
was important to make sure pdroid went first. Provisionals can be dangerous, this is
a safety measure. Anyway, looks like there was at least two bugs. I am not sure when they
got introduced, I believe this used to work. Should also allow me to reinstate the
CONFLICTS function Caldair found was causing problems. We will see about that.
Add symlink called 20130516 linked to 20130403

This allows the Final release hack (the BID_OVERRIDE hard-set to 0516) to work for
tabletUI as well. This should allow all mods to apply to Final CM builds without any
further user specification.
Versioning to v2.9927 and uupdate changelog
Fix CONFLICTS function

When using rom probe, the CONFLICTS function did not iterate through the mod
list. So if there were multiple mods and no rom type specified, the conflicts
function would only work on the first mod in the list, generally hard-coded
to be a PDroid mod.

This updated version of the fix resets the PID variable, so each call to the "mods_info"
function sets the various mod-related variables as set to each individual mod. The
PID array (which is the list of requested mods set at the CLI) is afterwards reset to the
ordered list made previously (SPID array).

Someday all of these various variables and arrays need to be sensibly renamed.

Closes (#125)
Merge branch 'update_conflicts' and version up
Be more explicit about Final CMID

Some nightlies for devices with slightly non-standard build.props were
triggering Final build status (used to be "10.1.*", changed it to
("10.1.1" || "10.1.2") )

Devices include encore (still needs manual date selection) and i9100 (fixed),
among possible others.
Manual date specification on CLI was failing

This was caused by removing the $P variable yesterday. We need to rewrite our
variable names, as being haphazrd with them has left us with problems of scope.
Some of these problems are very hard to find because they have variable set
elsewhere and we don't even know it.

Previously, ./auto_patcher encore.zip openpdroid cm 20130516 was failing
because the script was checking for [ -d patches/$P/$ANDR/$RID/$BID ]. But
$P was no longer defined, because I changed it yesterday. But we did not know
that was where we had set $P for this function, that was an accident. This is
how the most frustrating bugs come to be, scope and variable confusion.
Rename variable in loop to finish yesterdays rename (h/t: gcydtmkq)

Affects the "helpful" output I spent so much time writing. Whoops.