This allows us to change permissions and ownerships of directories
in init scripts without adding additional commands.
Change-Id: I1815d6015953035251b98f28c0f3efd3c7f25f80
The write command will write a property value if the value starts with a "$'
For example:
write /sys/class/android_usb/iSerial $ro.serialno
Use double leading '$' if you need to write a string that starts with '$':
write /data/foo $$hello
to write "$hello" to /data/foo
Change-Id: I55431ac7715a5347bb95c3a15aee97c575444dde
Fix for bug 3415286. The persistent properties are normally read early
in the boot process after /data is mounted. However, for an encrypted
system, at that point /data is a tmpfs ramdisk. This change adds a new
command to init (load_persist_props) to read the persistent properties,
and adds an action to init.rc to load the persistent properties. This
action is triggered by setting a property in vold, but that's in a
different CL.
Change-Id: I74b3057974ee6029c29d956b76fef5566700d471
rm only removes a single non-directory directory entry (no -r support)
rmdir removes a single empty directory
Change-Id: I49702b02ba98a177027b126268c2c2846f968195
The UI needs to know if the device is running with an encrypted
filesystem or now. So set a read-only property at boot to let it know.
Change-Id: I753de2d606c975bcbe9946d10fd47558cf357dac
These are the changes to init and init.rc necessary to
support booting with and encrypted /data filesystem.
A corresponding change to init.<device>.rc goes along
with this change.
Change-Id: I0c7e2cc39568358014a82e317735c0eae14dd683
add O_TRUNC flag in open(), which will truncate the target file,
otherwise, copy will keep the old content of the target file.
Signed-off-by: Tom Zhu <ling.zhu@motorola.com>
Signed-off-by: San Mehat <san@google.com>
To add arguments dynamically to a service, start the service like so:
setprop ctl.start service_to_run:arg1 arg2 arg3...
To start a service with *no* dynamic arguments, start the service normally:
setprop ctl.start service_to_run
Dynamic arguments are only supported on 'oneshot' services
Signed-off-by: San Mehat <san@google.com>
In keeping with the pattern of mtd@partition, I have added loop@path as a way to specify a loopback device. This way you can do things like mount directories in /system using cramfs from a file otherwise on /system (just one example oof how I'm using it). I specifically went with loop@ rather than adding this feature as a flag as the flags system is designed to set bits in the flags argument to mount: using loop@ fit the model in a much simpler manner and actually feels "correct".
This is a better version of the previously submitted 4045 that also refactors the mtd@ case. The reason for this is that I received comments that I should check for errors and return errors rather that do work in the case of success and fall through, but the mtd@ case wasn't doing that either and it became awkward to design the function so that it was half in one style of error handling and half in another. I also made certain to use inequality comparisons for Unix's -1 error returns rather than checking for -1, refactored my large if statement so as not to have danling parentheses, and disassocited the loop device on mount failure.
