platform_bootable_recovery/edify
Bill Peckham 341644d657 Moving recovery resources from /system to /vendor
This change is part of a topic that moves the recovery resources from the
system partition to the vendor partition, if it exists, or the vendor directory
on the system partition otherwise. The recovery resources are moving from the
system image to the vendor partition so that a single system image may be used
with either an A/B or a non-A/B vendor image. The topic removes a delta in the
system image that prevented such reuse in the past.

The recovery resources that are moving are involved with updating the recovery
partition after an update. In a non-A/B configuration, the system boots from
the recovery partition, updates the other partitions (system, vendor, etc.)
Then, the next time the system boots normally, a script updates the recovery
partition (if necessary). This script, the executables it invokes, and the data
files that it uses were previously on the system partition. The resources that
are moving include the following.

* install-recovery.sh
* applypatch
* recovery-resource.dat (if present)
* recovery-from-boot.p (if present)

This makes the applypatch executable a vendor module.

This change supports making dependencies of the applypatch executable available
to applypatch, which is now on vendor.

Since install-recovery.sh is now a vendor service, we add the
applypatch/vendor_flash_recovery.rc file to /vendor/etc/init to start the
service.

Bug: 68319577
Test: Ensure that recovery partition is updated correctly.
Change-Id: I01c0800ee6078aa6c9d716d5f154ad2d63c7af84
2019-10-04 00:04:56 +00:00
..
include/edify Add a GetMappedPackageLength to Updater 2019-07-08 19:30:11 +02:00
Android.bp Moving recovery resources from /system to /vendor 2019-10-04 00:04:56 +00:00
expr.cpp Add UpdaterRuntime class 2019-05-20 18:03:27 -07:00
lexer.ll edify: Export the header and move to Soong. 2017-10-09 14:08:00 -07:00
parser.yy edify: Rename parse_string to ParseString and let it take std::string. 2018-07-10 06:27:50 +00:00
README.md edify: Some clean-ups to libedify. 2016-10-12 23:29:59 -07:00
yydefs.h refactor applypatch and friends 2010-02-22 15:30:33 -08:00

edify

Update scripts (from donut onwards) are written in a new little scripting language ("edify") that is superficially somewhat similar to the old one ("amend"). This is a brief overview of the new language.

  • The entire script is a single expression.

  • All expressions are string-valued.

  • String literals appear in double quotes. \n, \t, ", and \ are understood, as are hexadecimal escapes like \x4a.

  • String literals consisting of only letters, numbers, colons, underscores, slashes, and periods don't need to be in double quotes.

  • The following words are reserved:

     if    then    else   endif
    

    They have special meaning when unquoted. (In quotes, they are just string literals.)

  • When used as a boolean, the empty string is "false" and all other strings are "true".

  • All functions are actually macros (in the Lisp sense); the body of the function can control which (if any) of the arguments are evaluated. This means that functions can act as control structures.

  • Operators (like "&&" and "||") are just syntactic sugar for builtin functions, so they can act as control structures as well.

  • ";" is a binary operator; evaluating it just means to first evaluate the left side, then the right. It can also appear after any expression.

  • Comments start with "#" and run to the end of the line.

Some examples:

  • There's no distinction between quoted and unquoted strings; the quotes are only needed if you want characters like whitespace to appear in the string. The following expressions all evaluate to the same string.

    "a b" a + " " + b "a" + " " + "b" "a\x20b" a + "\x20b" concat(a, " ", "b") "concat"(a, " ", "b")

    As shown in the last example, function names are just strings, too. They must be string literals, however. This is not legal:

    ("con" + "cat")(a, " ", b) # syntax error!

  • The ifelse() builtin takes three arguments: it evaluates exactly one of the second and third, depending on whether the first one is true. There is also some syntactic sugar to make expressions that look like if/else statements:

    these are all equivalent

    ifelse(something(), "yes", "no") if something() then yes else no endif if something() then "yes" else "no" endif

    The else part is optional.

    if something() then "yes" endif # if something() is false, # evaluates to false

    ifelse(condition(), "", abort()) # abort() only called if # condition() is false

    The last example is equivalent to:

    assert(condition())

  • The && and || operators can be used similarly; they evaluate their second argument only if it's needed to determine the truth of the expression. Their value is the value of the last-evaluated argument:

    file_exists("/data/system/bad") && delete("/data/system/bad")

    file_exists("/data/system/missing") || create("/data/system/missing")

    get_it() || "xxx" # returns value of get_it() if that value is # true, otherwise returns "xxx"

  • The purpose of ";" is to simulate imperative statements, of course, but the operator can be used anywhere. Its value is the value of its right side:

    concat(a;b;c, d, e;f) # evaluates to "cdf"

    A more useful example might be something like:

    ifelse(condition(), (first_step(); second_step();), # second ; is optional alternative_procedure())