तू ज्ञान का सागर है तेरी इक बूँद के प्यासे हम...

तू ज्ञान का सागर है

तेरी इक बूँद के प्यासे हम

लौटा जो दिया तुमने

चले जायेंगे जहां से हम

तू ज्ञान का सागर...

घायल मन का पागल पंछी उड़ने को बेक़रार

पंख हैं कोमल, आँख है धुँधली, जाना है सागर पार

अब तू ही इसे समझा, राह भूले थे कहाँ से हम

तू ज्ञान का सागर...

इधर झूम के गाये ज़िंदगी, उधर है मौत खड़ी

कोई क्या जाने कहाँ है सीमा, उलझन आन पड़ी

कानों में ज़रा कह दे, कि आएँ कौन दिशा से हम

तू ज्ञान का सागर...

Enterprise mobility management

Lets talk about the buzz word EMM :-)

Enterprise mobility management (EMM) is the the concept about managing the mobile devices, wireless networks, and related services to enable broad use of mobile computing in a business context. 

This is an emerging discipline within the enterprise that has become increasingly important over the past few years as more workers have bought smartphone and tablet computing devices and have sought support for using these devices in the workplace.

The Needs of EMM: 

In today's business context enterprises are facing challenges with following things:  

1. To manage enterprise, use of employee's personal devices i.e (BYOD): -

·         To manage use of device

·         To manage the installation of applications on those devices

·         To protect access on device 

·         Remotely Lock, wipe enterprise devices, manage enterprise work-space on BYOD 

·         Remotely forceful installation, uninstallation of apps on devices

·         BYOD manageability

2. To secure and manage Enterprise application

·         To manage and control mobile device environment and device functionality within Enterprise apps

·         To manage and control application features, and behaviors

3. To ensure data security: -

·         Data on Rest – Encryption

·         Data on move – Always on VPN, App tunneling

How EMM Needs are addressed:

Lets see how following three key components are addressed in EMM:

    1.   Device management:

               ·         Devices registers on server console with the help of Mobile device
           Management (MDM) agent, approved on console

           ·         Devices management is provided like lock, wipe, password policies
           enforcement etc.

    2.   App Management:

               ·         App wrapping

           ·         SDK integration

               ·         Native OS support

    3.   Data security: 

               ·         Encryption, App tunneling, data containerization 

"Sabse bada rog, Kya kahenge logg"

This is the very first time I am writing something "nontechnical stuff'(I must say).., So I would like to wish myself luck. ;) ;) 
The above mentioned subject is quite familiar to most of the people in this world, especially in our country so I think there would be hardly anything which would be new to you, but it's just that I thought to scribble down everything at one place. 

So here we go, the title “Sabse bada rog, kya kahenge log” says it all, which means the biggest fear we human beings (especially Indians) have that what he/she would think about me, what he/she would say about me, what if they make fun of me, what if it ends up being embarrassing & blah blah blah...
And with this we end up giving up so many precious things which we think or long to do. 

Say for example, if you are standing at a red light in your car having fun with your friends & a beggar comes begging & your friends start mocking at him & suddenly there is a strike in your heart of generosity, thinking to give something to that poor guy but you decide against it just because of the fear, what your friends would think & may make fun of you, etc. etc. What I am trying to state here is just don’t let the fear of being mocked or anything let you suppress what you want to do. At times there is a sudden strong feeling which arises in our heart & we really wish to fulfil that but still suppress the same due to some or the other reason which again is not right since this small decision of suppressing our desire, no matter how small it may be, may not cost you much at that time but the same is obviously costing you in a way that you will gradually develop a habit to suppress your thoughts and eventually losing out the real human being in you who wishes to have freedom, do what he wants to do. A bitter truth is that we all say, I don’t care what he/she says or thinks about me but somewhere inside we do care, we do become conscious of the people surrounding us which may be our relatives or strangers. We live in a fear, what if I decide to do this or do that, but again everything ends up with a one liner, “I want to do this but you know I am afraid of what that uncle or aunty may think, that neighbor will say, that friend’s mom will say & the biggest & the most common one, “what if I fail” etc. etc. 

Now I can bet many of us including me are always conscious of some or the other thing.., otherwise why would a thing like "facebook" be such a hit, if we din't care about what other people thought about us?Maybe it's just that we love the people around us, so we care about what they want, and try to do that to makethem happy, maybe we just wanna fit in, maybe we want to feel special, or maybe we are lonely and just want to please somebody so that we wouldn't have to be.  

& so even strongly I can bet that, as when we look at the foreigners in our country, we always wonder about their carefree attitude, even if they would be wearing a shortest of half pants with a vest and a slipper, they would be looking cooler than us & that’s because we carry the burden of consciousness with us whereas they don’t even bother about anyone around but themselves. 

To say the least, I would say, “Just be yourself” & lighten the burden of consciousness. & offcource if there are any suggestions or something which is an honest feedback or a constructive criticism we should take that.

Now most of you who might know me well may think, “better learn this yourself first & then try & teach others” & I am dead sure about this thought of yours.. but by writing this article, the urge in me to improve this aspect of mine will increase as every-time when I read this in future, it will remind me that I also need to work on this. 

Someone also said very beautifully:
      Sirf dil ko saaf rakhte hain hum....
      Gairo se hume certificate nahi chahiye...
      Kyoki laakh bhala karo... phir bhi...
      Kuch to log kahenge... logo ka kaam hai kahna...
      Chodo bekaar ki baaton ko... kahin ...beet na jaye raina!!!

I think its enough for the first time & would like to close it off here. Finally would like to say to everyone reading & to myself too that shed those beliefs & do what your inner voice is screaming at you to do & feel the trueness of life. 
And last but in no way the least, thank you for your time & patience. 

CHEERS!!!!! 
~Shridutt 

Android Build FAQ

= FAQ =

In general, the key thing to note is that android build system is non-recursive. For more on recursive vs non-recursive, please see:

GNU Make Recursion -> "http://www.gnu.org/s/hello/manual/make/Recursion.html"
Why recursion is harmful -> "http://miller.emu.id.au/pmiller/books/rmch/?ref=DDiyet.Com"

All the commands mentioned here are from top of the tree and assume, you've already setup your environment with:
        $ source build/envsetup.sh
        $ choosecombo

== What java version is my build using? ==

In Gingerbread, your JAVA_HOME is set to '''/usr/lib/jvm/java-6-sun''' by build/envsetup.sh. You may see errors if you do not have JAVA 1.6 installed.
$ echo $JAVA_HOME # should return empty
$ source build/envsetup.sh # will set your JAVA_HOME if it's empty, will honor the existing value otherwise
$ which java
$ java -version
$ javac -version

== Related Build Error: method does not override a method from its superclass. @Override ==

This "error" is due to a difference in the meaning of @Override between Java 1.5 and Java 1.6: Java 1.6 added the ability to use @Override to indicate that a method implements an interface method
[which this code does].
You should be able to compile this code without error if you use a Java 1.6 compiler (the 'java -version' command only shows the JRE version. Use 'javac -version' to get the compiler version and adjust your path accordingly).

== What are the various build variants and their usage ==

Android build system supports the following build variants
*user
*userdebug
*eng
*tests

You can build these variants as follows
$ cd WORKSPACE
$ source build/envsetup.sh
$ choosecombo 1 1 <product-name> user
$ choosecombo 1 1 <product-name> userdebug
$ choosecombo 1 1 <product-name> eng
Alternatively, you can run
$ make PRODUCT-<product-name>-user
$ make PRODUCT-<product-name>-eng
$ make PRODUCT-<product-name>-tests
Note that '''choosecombo''' doesn't support tests variant.

== Where is the build log? ==

You can save one for yourself with
$ make 2>&1 | tee log

== How do I clean the build? ==

You can use '''dataclean''' to clean the staging area for your data partition
$ make dataclean # will rm -rf $(PRODUCT_OUT)/data/*, data-qemu/*, userdata-qemu.img

You can use '''installclean''' while switching between build variants
$ choosecombo 1 1 <product-name> user
$ make installclean # deletes all of the files that change between
different build types
$ choosecombo 1 1 <product-name> eng
Clean and clobber, both will remove the entire build dir
$ make clean # Remove all builds for current and past targets, does
rm -rf
$(OUT_DIR)
$ make clobber # Remove all builds for current and past targets

== What is a module? ==

In android build system, an Android.mk file defines how you build. An
android module is the entity you are building and is specified by
variable LOCAL_MODULE in the Android.mk
A single Android.mk can build multiple modules.

== How do I rebuild my module? ==

If you have a 'LOCAL_MODULE := foobar' in your Android.mk, you should be able to do
$ make foobar

== What are m, mm, mmm? ==

These are build utilities provided by build/envsetup.sh. Here's a
description of all the available utilities
- croot: Changes directory to the top of the tree.
- m: Makes from the top of the tree.
- mm: Builds all of the modules in the current directory.
- mmm: Builds all of the modules in the supplied directories.
- cgrep: Greps on all local C/C++ files.
- jgrep: Greps on all local Java files.
- mgrep: Greps on all makefiles
- resgrep: Greps on all local res/*.xml files.
- godir: Go to the directory containing a file
- printconfig: tells you what configuration you are currently building
Note that 'm' and 'mm' need a toplevel Android.mk in the directory you use them on.
Example usage
$ cd dalvik/tests
$ mm
$ mmm ../tools
$ godir Atomic.h
$ m
$ croot

== How do I turn off prelinking for my module? ==

Add
LOCAL_PRELINK_MODULE := false
For the module in your Android.mk LOCAL_PRELINK_MODULE is set to false
by default for executables (built using BUILD_EXECUTABLE)

== How do I see what commands make is running? ==

You can use the '''showcommands''' modifier target.
What is does (build/core/config.mk)
# The 'showcommands' goal says to show the full command
# lines being executed, instead of a short message about
# the kind of operation being done.
SHOW_COMMANDS:= $(filter showcommands,$(MAKECMDGOALS))
Usage
$ make showcommands
$ cd $some_dir_with_an_Android.mk
$ mm showcommands

== How do I find out what are the available modules? ==

$ cd $some_dir_with_an_Android.mk
$ mm modules
You can also run 'make' to see the list of all the modules available
in your tree
$ croot
$ make modules

== How do I clean a single module/package? ==

$ croot
$ make clean-$(LOCAL_MODULE)

== How do I rebuild system image for an existing build? ==

$ make snod

=== What is snod? ===

'snod' is a pseduo-target provided by build/core/Makefile. You can use
it to rebuild your system image without following it's dependencies
and rebuilding everything else, apart from what you provide to make.
Example use cases
$ make framework snod  # rebuilds framework module, and system image

== How do I build multiple variants and targets? ==

Note: this script is broken in gingerbread.
$ source build/tools/check_builds.sh
$ golden_builds <product1>-eng <product2>-user <product3>-eng
Additionally you can run
$ check_builds <product1>-eng <product2>-user <product2>-eng
What this will do for you, according to check_build.sh comments:
# Go get dinner, and when you get back, there will be a file
# test-builds/sizes.html that has a pretty chart of which files are
# in which tree, and how big they are.

== How do I find what build properties are available for my build and how they were derived? ==

Post a full build, build properties can be examined in
out/target/product/$(TARGET_PRODUCT)/build.prop
This file is created/updated by build/core/Makefile (invoked by build/core/main.mk). The file is a concatentation of build/tools/buildinfo.sh output + your system.prop + $ADDITIONAL_BUILD_PROPERTIES

== App development ==

$ cd your_app_folder
$ mmm
$ adb sync
If you don't use the same machine for compilation and loading it is
possible to forward the port used by adb (5037) to the PC connected to the device.
If it's a linux machine, it is a lot easier, but it is possible to
forward ports from windows.
Fastboot still has to be run on the connected machine, but since it
only needs a few image files it is easier to coordinate.

== How do I build my binary/library/applicaton? ==

In general, refer to the build cookbook "http://source.android.com/
porting/build_cookbook.html" You can also look at existing Android.mk
files in your source tree. If you are tagging your module with
"optional".
In summary, 'user' tags cannot be used, they are used only for legacy
modules (Grandfathered).
'optional' tags makes sure that the module gets installed into user
and eng builds as long as you add that module name to the list of
packages (PRODUCT_PACKAGES).
PRODUCT_PACKAGES for proprietary modules is defined in the device-
vendor.mk
file, e.g. vendor/<vendor-name>/prop/common/config/device-vendor.mk
Opensource modules are defined in device/<vendor-name>/common/
common.mk
The 'eng' tag implies that the module will be picked up only by 'eng'
variant of the build.
The tests tag implies that the module will be picked up by tests variant of the
build. The tests variant is not available from choosecombo.
Do not use development (or any other tags not sanctioned by the android build system)

== My binary/library isn't available on target, whats wrong? ==

Check if you've updated the appropriate .mk configuration file to include
a PRODUCT_PACKAGES entry for the module.
Check the build log to see if your module got built. You can also use
'mm' with 'showcommands' to see if the module is being built & installed.

== I don't want to build everything, takes too long. What do I do? ==

You can build "tiny android," an Android build with a limited
userspace that
is useful for kernel development and verification. The tiny android
build will
not boot into the full UI. It will stay at one of the loading screens
(ANDROID_ - not the boot animation). ADB will be active, allowing you to run unit tests, etc. The build time for tiny android is significantly less than a full Android build. Tiny Android builds complete in less than 2 minutes,
whereas a full Android build takes over 20 minutes.
$ BUILD_TINY_ANDROID=true make -j4

=== How do I use a prebuilt kernel? ===

The kernel objects, vmlinux and zImage will be at <platform>/out/
target/product/<TARGET>/obj/KERNEL_OBJ and its subdirectories, where
<TARGET> is the target device you selected in choosecombo above. You
can override the TARGET_PREBUILT_KERNEL flag with your own kernel
image to build android with your kernel, as follows:
$ make -j4 TARGET_PREBUILT_KERNEL="<your_kernel_tree>/arch/arm/boot/zImage"

=== error: do_inode_allocate_extents: Failed to allocate blocks ===

One way to workaround this is to increase the system image size.
Please see
BOARD_*_PARTITION_SIZE variables in device/<vendor>/$(TARGET_PRODUCT)/
BoardConfig.mk in your workspace.


== Misc ==

=== If you want to see all warnings in a pretty format, do ===

$ build/tool/warn.py my_build_log > warn.html
See the html page for a nice classification for all the warnings on your product.

=== What is the 'simulator' in lunch for? ===

"the simulator is somewhat maintained, but it's a very specialized and very fragile tool which is only used by a handful of people at Google. It is likely to require the very precise environment that those people" use, which is specific to Google and isn't publicly available."
See this thread for more detail
"http://groups.google.com/group/android-building/browse_thread/thread/55521a7849bbac1a/e4e020a8213cf7c7?lnk=gst&q=generic+product#e4e020a8213cf7c7"

=== How do I rebuild the sdk? ===

$ make PRODUCT-sdk-sdk

== What is the difference between board, target, product and device?==

Android build system supports hierarchical layering of product,
device, board, and arch in a one to many relationship as described at
"/development/pdk/"

=== TARGET ===

In Android Build System, 'target' or 'TARGET' refers to your build
target. There are a bunch of variables associated with a target.
From a Build perspective, these are

TARGET_PRODUCT: identifies the product that you are building
TARGET_BUILD_TYPE: identifies the build type from one of
'release,
debug'
TARGET_BUILD_VARIANT: identifies the build variant from one of
'user,
userdebug,
 eng,
tests'
From a PRODUCT perspective, these are
TARGET_PRODUCT: identifies the product, for example, full_crespo,passion_us, passion_eu
TARGET_DEVICE: identifies the device, for example, full_crespo,passion
TARGET_BOARD_PLATFORM: can be used for a family of boards, for example, qsd8k, msm7k
TARGET_BOOTLOADER_BOARD_NAME: used by OEMs for their boards, and by chipset_variants. for example, mahimahi of htc, full_crespo
TARGET_ARCH: arm/x86
TARGET_ARCH_VARIANT: armv5/armv7

=== BOARD ===

In Android Build System, BOARD refers to the schematics of a product

=== DEVICE ===

For OEMs, DEVICE refers to the physical layer of plastic on the device
Each of these devices may result
into multiple products. Examples
* crespo # Samsung
* passion # HTC

=== PRODUCT ===

The product layer represents a complete specification of a shipping
product
"/development/pdk/docs/guide/build_system.jd"

== How do I add a new target? ==

Adding a new target means adding a new product. You can name your product as chipset_variant. Note that if one product may suffice for all your chipset variants.

== How do I add a new product? ==

Android products use inheritance, you can generate a nice product graph using
$ sudo apt-get install graphviz
$ make product-graph # pdf goes in out/product.pdf

== PRODUCT CONFIGURATION ==

In general, android build system builds products, and allows you to configure what goes into a product. It doesn't explicitly support configuration at a build level, in allowing you to choose what to
build. A typical android build is supposed to build all possible code
that is available see build/core/main.mk.
You can choose what goes into a product, by adding to the
PRODUCT_PACKAGES list which is used to specify what additional
packages go into a product, as follows.

=== How do I generate a product graph ===
$ sudo apt-get install graphviz
$ make product-graph # pdf goes in out/product.pdf

=== What is device-vendor.mk, when do I modify it? ===

device-vendor.mk allows you to configure proprietary modules to be installed on the target images.
Starting with Gingerbread the Android build system enforces an explicit
LOCAL_MODULES_TAGS for all modules which aren't in the GRANDFATHERED MODULES
and recommends using "optional" tag for modules which are expected to be in all builds of a product.
When LOCAL_MODULE_TAGS of a module is defined with an "optional" tag,
the module will not be available in the generated final image/s (which will be flashed on Target).
To get the module available in final image/s, module has to be part of PRODUCT_PACKAGES list.

=== What is device/<vendor>/common/common.mk, when do I modify it? ===

The opensource counter part of device-vendor.mk [prev question] is
device/<vendor>/common/common.mk and should be used for adding
opensource modules to PRODUCT_PACKAGES.

=== How do I configure (enable/disable) a module? ===

Configuration has two aspects with respect to Android Build System
* What gets installed
* What gets built
What gets installed can be configured at a product level using the
device-vendor.mk and common.mk configuration files, described above
[prev questions].
Controlling what get's built, is a more complicated story. Presently,
for a typical build android build system builds all modules it can
find using findleaves.py [See modules_to_install and modules_to_check in build/core/main.mk].
The two ways to enable/disable a module then are
* Add/Remove Android.mk
* Wrap the Android.mk in TARGET_PRODUCT if you don't want to build your
* modules for products like generic, emulator etc.
If you want your module to not be built for variants not supported by
your LOCAL_MODULE_TAGS, you can define LOCAL_DONT_CHECK_MODULE, though
it is not recommended by android build system as of now. Example,
$(CLEAR_VARS)
LOCAL_DONT_CHECK_MODULE := true
LOCAL_MODULE := foo
LOCAL_MODULE_TAGS := eng
What this will do for you is
* For all non-eng builds, your module will only be built if it's a dependency
* of another module
* Else, it will be ignored


== Emulator ==

=== What is the emulator? ===

From the AOSP WIKI documentation: "The Android SDK includes a mobile
device emulator -- a virtual mobile device that runs on your computer.
The emulator lets you develop and test Android applications without using a physical device."

=== How is it used? ===

The emulator is provided by
external/qemu
sdk/emulator
prebuilt/linux-x86/emulator
The one in external/qemu produces an executable called "emulator"
which can be used from the commandline. It get's built and installed
in out/host/linux-x86/bin/emulator and can be used with the images
generated by building the 'generic' products provided in the AOSP tree.
The AOSP tree provides "non-hardware-specific targets" which can be used "to build entire user-level system and work with emulator".
There are two such target products available
target/product/generic
target/product/generic_x86
They use the following boards from target/board, respectively
target/board/generic
target/board/generic_x86
(There's also an 'emulator' board available under target/board for
which there's no emulator.mk under target/product, device/ or vendor/ which is where envsetup.sh looks for product makefiles, and so it doesn't show up in choosecombo)
target/board/*/README.txt explains the existence and usage of all three, generic, generic_x86, emulator.
Emulator usage example
"http://groups.google.com/group/android-platform/browse_thread/thread/b115c4cadbfdb333/488ca1b48bc546d8?lnk=gst&q=generic+product#488ca1b48bc546d8"

== How do I rebuild the emulator? ==

"http://groups.google.com/group/android-building/browse_thread/thread/f8f0c3bacd6efae/05ec2449d4e5dc6f?lnk=gst&q=emulator#05ec2449d4e5dc6f"

FOTA procedure in Android

FOTA procedure in Android

FOTA in Android (Mechanism, Implementation & Behind the scene) -Firmware updation in Android over the air

What is FOTA?

Firmware Over-the-Air (FOTA) is a method used for update software on mobile phones and tablet computers etc.

FOTA in Android?

In android, FOTA can update current firmware, kernel, boot/system/recovery images, single/multiple application etc.

Major components involved in Android FOTA mechanism are:

•        FOTA Server with push notification support
•        OTA Updater application in Android device
•        Recovery console in Android device

FOTA procedure in Android?

In Android smartphones/tablets FOTA is performed in following way:

•         Device register to server for push notification of firmware/software updates.
•         Server sends the update notification to the device.
•         Device perform polling requests to server for new update.
•         User performs manual update check.
•         If update is available, get the update file URL from server.
•         Fetch update file and save in cache partition.
•         Verify the update file signature and checksum.
•         Reboot in recovery mode with update installation command.
•         Recovery console verifies the signature of update file.
•         Recovery console executed the updater script from update file.
•         Device Reboots after installation.

How to implement FOTA in Android (excluding push notification)

1. Create the Cryptographic signature for the OTA signing (required for releasing, not needed for demo)

There are four keys that can be used during development for authentication purposes:

Ø  testkey — a generic key for packages that do not otherwise specify a key.

Ø  platform — a key for packages that are part of the core platform.

Ø  shared — a  key for things that are shared in the home/contacts process.

Ø  media — a  key for packages that are part of the media/download system.

The default AOSP keys are found in the build/target/product/security directory.

(*.pk8 are the private keys, *.x509.pem are the corresponding certificate/public keys)

We can generate our keys with the shell script located at /development/tools/make_key

Procedure to create Keys is as follows:

• First remove the existing AOSP keys :
• Create New keys :
• Verify the created keys :
• Re-sign the OTA file content after creation :
• Re-sign the OTA file manually with SignApk.jar :

      2.  If the new update package can have older “build date time” than only we should comment the following line from following file :
(otherwise skip this step):
/build/tools/releasetools/ota_from_target_files

      "script.AssertOlderBuild(ts);"

As the mentioned line creates the assert in the updater script for older build and aborts the installation if the update file is having older “build date time”.

 3. Create an FOTA update file with the command

      It will generate the full Android OS OTA update file in the out/target/product/product_name/someotafile.zip

 4. If we need to create any partial/incremental update then we can do with following command:

  It will only include the specified packages in OTA update file, its build logic is in build/core/Makefile.

 5. Now upload the zip on OTA server and whenever the update check for your device comes at server
After verifying device, rom values from the request provide the Rom info in the form of Jason String.

 6. Create an Android application with following permissions:

So that application can do following tasks:

• Perform polling request to server using internet on each time device boots/ manual update check by user.
• Update can be downloaded to /cache partition.
• For installation in recovery mode device can rebooted by the application.

  7. Create a Activity with intent filter "android.settings.SYSTEM_UPDATE_SETTINGS"
   This intent is fired from /packages/apps/Settings/res/xml/device_info_settings.xml

So that when user navigates to System settings -> About device-> System Updates, our activity can be launched.

         8. Create an AsyncTask, which can be called whenever polling is required to be performed to check the update on server, the doInBackground() method will have pseudo code as follows: 

        9. Create a broadcast receiver with intent filter "android.intent.action.BOOT_COMPLETED"

        So that when device boots up we can start our UpdateCheckReceiver class, which can Schedule a repeating alarm to send the pending intent to this same broadcastReceiver class to instantiate a new AsyncTask, to perform polling on server, to check the update.

  10. On a valid RomInfo Object received, Start the Downloader AsyncTask to download the update zip file from server, the doInBackground() method will have pseudo code as follows:

  11. On successful download of the update zip file from server we must verify the cryptographic signature of the downloaded update file, and then we can install it as follows:

It will reboot the device in recovery mode, where recovery console will first verify the signature of the file then execute the updater script of that update zip file, which will install the updates i.e. (FOTA).
If any problem occurs it will show an android error symbol and wait for user reboot, otherwise It will reboot in to updated android after successful installation.

   Behind the scene

·        Releasetools (which creates OTA update file)

– It Create digitally signed software updates from a target-files-package (TFP)

-  TFP generated by Android* build system

–   We need to substitute testing for production keys inside a TFP

·        SW Update UI intent from AOSP Settings application

-  android.settings.SYSTEM_UPDATE_SETTINGS

-   Intent launched when user navigates to Settings->About device->System updates

·        android.os.RecoverySystem APIs

– Framework APIs to verify & install SW updates

–   Handles verification of OTA update digital signature

-   Also used to engage Factory Data Reset

-   RecoverySystem doesn’t write to BCB due to permissions on doing raw block device I/O

– Writes RC command files into /cache/recovery/command, and reboots into Recovery Console
– Typical RC commands which may be supplied in the /cache/recovery/command file:

       --send_intent=anystring - write the text out to recovery.intent
    --update_package=path - verify install an OTA package file
    --wipe_data - erase user data (and cache), then reboot
    --wipe_cache - wipe cache (but not user data), then reboot
    --set_encrypted_filesystem=on|off - enables / diasables encrypted fs
    --just_exit - do nothing; exit

·        /misc partition

–   Very small size, does not contain a filesystem

–   Tiny partition used for communication between Recovery Console (RC) and bootloader, and for RC to save state information

–   Contains Bootloader Control Block (BCB)

Ø  command[32]: Commands for the bootloader

• “boot-recovery” boot into RC instead of Android

• Other platform-specific commands may be implemented for update tasks that must be done by the bootloader

• If empty, garbage, or no known commands matched, normal Android boot

Ø  status[32]: Return status field written by bootloader after performing platform-specific commands

• No specification, platform-dependent

Ø  recovery[1024]: Command line for Recovery Console

• Arguments tokenized by ‘\n’

• Invalid if first argument not ‘recovery’

·        Recovery Console (RC) (Alternate boot environment)

– Comments at the beginning of bootable/recovery/recovery.c are out of date

-   A few ways to enter –

Ø  reboot recovery from a shell

Ø  RecoverySystem APIs in Android Framework

Ø  OEMs often implement a bootloader ‘magic key’

– Verify & Apply SW updates

– Perform Factory Data Reset

– Typically controlled by “/cache/recovery/command” file left by Android RecoverySystem APIs

-   Pictorial interface, no localization

-   Hidden non-localized menu for manual tasks

-   Other platform-specific tasks as implemented in Recovery Console UI plug-in

-   Log files saved in /cache/recovery

Ø  All stdout/stderr from RC and Updater

Ø  Edify ui_print() commands

-   Upon startup, looks for command line arguments in decreasing precedence:

Ø  Actual command line to ‘recovery’, debug-only scenario

Ø  BCB.recovery

-   Android framework RecoverySystem doesn’t write to BCB due to permissions on doing raw block device I/O, So Recovery console (RC) Always copies arguments into BCB.recovery and sets BCB.command to “boot-recovery”

Ø  Makes sure we keep booting into RC with the same arguments in event of unexpected power loss

Ø  Don’t rely solely on /cache/recovery/command for this

-   finish_recovery()

Ø  Called when requested operations (SW update, factory data reset, etc) are complete, whether successful or failed

Ø  BCB is cleared so that subsequent reboot goes back into Android

Ø  Copies all logs to /cache/recovery/

–   If no arguments were given to RC, displays error image and waits for menu input

·        Bootloader Integration

-   Linux kernel should write “boot-recovery” into BCB.command and zero out BCB.recovery if “recovery” is supplied as a reboot() argument from android framework

–   Implement in a driver via register_reboot_notifier()

-   Bootloader selects boot image (or other task) based on BCB.command

–   BCB.command is persistent; keep booting into RC until RC clears it

–   Garbage or zeroed out contents should simply boot into Android

·        Updater

–   SW update logic, binary inside SW update package

–   AOSP implementation runs script in Edify language

–   Platform-specific tasks implemented in plug-ins

·        updater script

-   Updater script written in Edify language

-   Created by python script in AOSP /build/tools/releasetools/edify_generator.py & /build/tools/releasetools/ota_from_target_files

-   Placed inside update zip file in /META-INF/…/updater-script