Android patchromプロセスの詳細

24633 ワード

昨年からpatchromに接触し、その後も多くの時間が投入されているため、patchromの全体的な流れも略一二である.一方patchromは,miuiやカエルなどのromのみに機種を適合させるのではなく,romの二次開発に比較的実用的なツールと見なすことができる.くだらないことはあまり言わない.1,まずubuntu環境をマウントする必要があります.このネット上にはチュートリアルがあります.2、Miuiまたはlewaのpathromのプラットフォームコードを引く必要があります.ブロガーはlewaに詳しいので、ここでlewaのpatchrom 4.4プラットフォームで紹介しました.3,まずgithupの上からlewa 4を4 patchromプラットフォームのコードを引き出します.1.githupアカウントおよびgithupアカウントの構成を作成します.参照http://blog.csdn.net/tangbin330/article/details/9128765 2.githupの構成後はmkdir patchrom cd patchrom repo init-ugit://github.com/LeWaCode/patchrom.git-b kitkatその後同期コード:repo sync 3.このプラットフォームの下には、すでに適した機種がいくつかあります.nexus 5で分析します.私たちはpatchromディレクトリの下で実行します.build/envsetup.shその後cd nexus 5 make workspace make firstpatch make fullotaはこの3つの部分を通じてoutディレクトリの下で生成されたブラシパッケージとotaパッケージを見つけることができます.
patchromはどのように働いていますか?次にpatchromプラットフォームの構造を分析します.android、build、lewa、toolsの4つの主要ディレクトリと各機種のディレクトリが含まれています.Androidディレクトリ:android.policy.jar.out framework2.jar.out framework.jar.out services.jar.out telephony-common.jar.outこれらのディレクトリはrom側が修正するframeworkのコードによって生成されたsmailがapktools dを介してコンパイルするframek*である.JArを解いてこのディレクトリの下に入れます.base-frameworkにはgoogle aospコードでコンパイルされたsmailファイルが入っています.buildディレクトリ:主なコンパイルプロセスを格納するファイル、主にmk、makeコンパイル参照http://blog.csdn.net/onlyou930/article/details/6553870toolsディレクトリ:patchromを格納するために使用するさまざまなツールについて説明します.lewaディレクトリ:aospソースコードで修正されたromパケットであるrom側が提供するベースパケットを格納します.
そして機種ディレクトリnexus 5の下に入り、make workspaceが何をしたか見てみましょう.ワークスペースがbuild/utilにあるのを見つけました.mk内
workspace: apktool-if $(JARS_OUTDIR) $(APPS_OUTDIR) fix-framework-res restore-obsolete-keyguard
@echo Prepare workspace completed!
この一言で何をしたか見てみましょう.ここでapktool-ifは、カエルのframework-res.apk、lewa-res.apk、およびベースパッケージのframework-res.apkの2番目のJARS_を含む必要なシステムリソースをマウントします.OUTDERは底のフレームワークをjar framework2.jar services.jar android.policy.jar telephony-common.JArは本を解凍してsmaliに逆コンパイルして機種ディレクトリの下に入れて後patchのために使用し、後の2つの文はapktoolのframework-resとkeyguardを前処理するいくつかの問題に対して先に放っておくことができる.要するに、最初のワークスペースが実行され、patchのターゲットディレクトリとその後の処理システムapkに必要なリソースがあります.次の第2部:make firstpatch:
# Target to add lewa hook into target framework first time
firstpatch:
    $(PATCH_LEWA_FRAMEWORK) $(PORT_ROOT)/android/base-framework $(PORT_ROOT)/android `pwd`
コードを見てみましょうPATCH_LEWA_FRAMEWORKはporting.mkには
PATCH_LEWA_FRAMEWORK  := $(TOOL_DIR)/patch_lewa_framework.sh $(INFO)
実はtoolの下のpatch_を実行しますlewa_framework.shというスクリプトの後ろの3つのパラメータは必要なパラメータです.スクリプトコードが多くないのを見てみましょう.

#!/bin/bash

# $1: the old smali code  $2: the new smali code $3: the destination smali code

if [ $# -ne 3 ];then
    echo "Usage: patchlewa.sh old_smali_dir new_smali_dir dst_smali_dir"
fi

#   $1 $2 $3       aosp framework smail  , rom    framework smali         

PWD=`pwd`
old_smali_dir=$1
new_smali_dir=$2
dst_smali_dir=$3
temp_dir=$PWD/temp
temp_old_smali_dir=$temp_dir/old_smali
temp_new_smali_dir=$temp_dir/new_smali
temp_dst_smali_orig_dir=$temp_dir/dst_smali_orig
temp_dst_smali_patched_dir=$temp_dir/dst_smali_patched
reject_dir=$temp_dir/reject

rm -rf $temp_dir

echo "<<< create temp directory to store the old, new source and destination smali code with .line removed"
echo "dst_smali_dir = " $dst_smali_dir
mkdir -p $temp_old_smali_dir
mkdir -p $temp_new_smali_dir
mkdir -p $temp_dst_smali_orig_dir
mkdir -p $temp_dst_smali_patched_dir
mkdir -p $reject_dir

cp -r $old_smali_dir/*.jar.out $temp_old_smali_dir
cp -r $new_smali_dir/*.jar.out $temp_new_smali_dir
cp -r $dst_smali_dir/*.jar.out $temp_dst_smali_orig_dir
$PORT_ROOT/tools/rmline.sh $temp_dir

function apply_lewa_patch() {
    old_code_noline=$temp_old_smali_dir/$1
    new_code_noline=$temp_new_smali_dir/$1
    dst_code_noline=$temp_dst_smali_orig_dir/$1
    dst_code=$dst_smali_dir/$1
    dst_code_orig=$dst_code.orig

    echo "<<< compute the difference between $old_code_noline and $new_code_noline"
    cd $old_code_noline
    for file in `find ./ -name "*.smali"`
    do
        if [ -f $new_code_noline/$file ]
        then
 # rom    smali aosp smali           
            diff $file $new_code_noline/$file > /dev/null || {
                    diff -B -c $file $new_code_noline/$file > $file.diff
            }
        else
            echo "$file does not exist at $new_code_noline"
        fi
    done

    cd $dst_smali_dir
    mv $dst_code $dst_code_orig
    cp -r $dst_code_noline $dst_code

    echo "<<< apply the patch into the $dst_code"
    cd $old_code_noline
#    diff patch       framework   smali       patch      rej    。 
    for file in `find ./ -name "*.smali.diff"`
    do
        mkdir -p $reject_dir/$1/`dirname $file`
        patch $dst_code/${file%.diff} -r $reject_dir/$1/${file%.diff}.rej < $file
    done

    cp -r $dst_code $temp_dst_smali_patched_dir

    cd $dst_code_noline

    for file in `find ./ -name "*.smali"`
    do
        rm -f $file.diff
        diff -B -c $file $dst_code_orig/$file > $file.diff
        patch -f $dst_code/$file -r /dev/null < $file.diff >/dev/null 2>&1
        rm -f $file.diff
    done

    find $dst_code -name "*.smali.orig" -exec rm {} \;
    find $temp_dst_smali_patched_dir -name "*.smali.orig" -exec rm {} \;
    rm -rf $dst_code_orig
}

jar_outs=`grep -rn "JAR_OUTS" $new_smali_dir/README | cut -d'=' -f2`
for out in $jar_outs
do
    apply_lewa_patch $out
done

echo
echo
echo ">>> patch lewa into target framework is done. Please look at $reject_dir to resolve any conflicts!"

以上がmake firstpatchのプロセス全体です.次は最後の作品を見てみましょう.make fullota:
fullota: BUILD_NUMBER := $(ROM_BUILD_NUMBER)
fullota: target_files
    @echo ">>> To build out target file: fullota.zip ..."
    $(BUILD_TARGET_FILES) $(INCLUDE_THIRDPART_APP) fullota.zip
    @echo "<<< build target file completed!"
そのうちBUILD_NUMBERは、現在のotaパケットが生成された時間です.次に重要なtargetを見てみましょうfiles.
#               out   
target_files: $(STOCKROM_DIR) | $(ZIP_DIR)
# lewa-res.apk   framework-res.apk overlay          out/system/framework  
# patch  framework*.jar       out/system/framework 
target_files: $(TMP_DIR)/lewa-res.apk $(ZIP_BLDJARS) $(TOZIP_APKS) add-lewa-prebuilt $(ACT_PRE_ZIP)
これでパッケージ全体のリソースも用意され、次はパッケージ化されます.パッケージ
$(BUILD_TARGET_FILES) $(INCLUDE_THIRDPART_APP) fullota.zip
この文には、主に1つのスクリプトと2つのパラメータが含まれています.
BUILD_TARGET_FILES = $(TOOL_DIR)/build_target_files.sh $(INFO)`
ビルドを見てみましょうtarget_files.shの中に何が入っていますか

# copy the whole 
# copy the whole target_files_template dir
#   patch             out    
function copy_target_files_template {
    echo "Copy target file template into current working directory"
    rm -rf $TARGET_FILES_DIR
    mkdir -p $TARGET_FILES_DIR
    cp -r $TARGET_FILES_TEMPLATE_DIR/* $TARGET_FILES_DIR
}

#      bootimage    out/target_files 
function copy_bootimage {
    echo "Copy bootimage"
    for file in boot.img zImage */boot.img */zImage
    do
        if [ -f $ZIP_DIR/$file ]
        then
            cp $ZIP_DIR/$file $TARGET_FILES_DIR/BOOTABLE_IMAGES/boot.img
            return
        fi
    done
}
#    system      target_files   
function copy_system_dir {
    echo "Copy system dir"
    cp -rf $ZIP_DIR/system/* $TARGET_FILES_DIR/SYSTEM
}
#    data      target_files   
function copy_data_dir {
    #The thirdpart apps have copyed in copy_target_files_template function,
    #here, just to decide whether delete them.
    if [ $INCLUDE_THIRDPART_APP = "true" ];then
       echo "Copy thirdpart apps"
    else
       rm -rf $TARGET_FILES_DIR/DATA/*
    fi
    echo "Copy lewa preinstall apps"
    mkdir -p $TARGET_FILES_DIR/DATA/
    cp -rf $ZIP_DIR/data/media/preinstall_apps $TARGET_FILES_DIR/DATA/
    if [ -f customize_data.sh ];then
        ./customize_data.sh $PRJ_DIR
    fi
}

#      
function recover_link {
    cp -f $METADATA_DIR/linkinfo.txt $TARGET_FILES_DIR/SYSTEM
    python $TOOL_DIR/releasetools/recoverylink.py $TARGET_FILES_DIR
    rm $TARGET_FILES_DIR/SYSTEM/linkinfo.txt
}

function process_metadata {
    echo "Process metadata"
    #copy            
    cp -f $METADATA_DIR/filesystem_config.txt $TARGET_FILES_DIR/META
    cat $TOOL_DIR/target_files_template/META/filesystem_config.txt >> $TARGET_FILES_DIR/META/filesystem_config.txt
    #copy      
    cp -f $METADATA_DIR/recovery.fstab $TARGET_FILES_DIR/RECOVERY/RAMDISK/etc
    #  apk     
    python $TOOL_DIR/uniq_first.py $METADATA_DIR/apkcerts.txt $TARGET_FILES_DIR/META/apkcerts.txt $PRJ_DIR
    cat $TARGET_FILES_DIR/META/apkcerts.txt | sort > $TARGET_FILES_DIR/temp.txt
    cat $TOOL_DIR/metadata/apkcerts_lewa.txt | sort >> $TARGET_FILES_DIR/temp.txt
    mv $TARGET_FILES_DIR/temp.txt $TARGET_FILES_DIR/META/apkcerts.txt
    recover_link
}

#             target_files.zip
# compress the target_files dir into a zip file
function zip_target_files {
    echo "Compress the target_files dir into zip file"
    echo $TARGET_FILES_DIR
    cd $TARGET_FILES_DIR
    echo "zip -q -r -y $TARGET_FILES_ZIP *"
    zip -q -r -y $TARGET_FILES_ZIP *
    cd -
}

# target_files   apk     
function sign_target_files {
    echo "Sign target files"
    $SIGN_TARGET_FILES_APKS -d $PORT_ROOT/build/security $TARGET_FILES_ZIP temp.zip
    mv temp.zip $TARGET_FILES_ZIP
    if [ "$PARTNER" != "Lewa" ];then
        cp $TARGET_FILES_ZIP $LEWA_OTA_PACKAGE
    else
        cp $TARGET_FILES_ZIP $OTA_PACKAGE
    fi
}

# target_files.zip               
# build a new full ota package
function build_ota_package {
    echo "Build full ota package: $OUT_DIR/$OUT_ZIP_FILE"
    $OTA_FROM_TARGET_FILES -n -k $PORT_ROOT/build/security/testkey -o $TARGET_OTA_ASSERT_DEVICE $TARGET_FILES_ZIP $OUT_DIR/$OUT_ZIP_FILE
    if [ "$PARTNER" != "Lewa" ];then
        cp $OUT_DIR/$OUT_ZIP_FILE $FULL_OTA_PACKAGE
    else
        cp $OUT_DIR/$OUT_ZIP_FILE $LEWA_OTA_FULL_PACKAGE
    fi
}


if [ $# -eq 3 ];then
    NO_SIGN=true
    OUT_ZIP_FILE=$3
    INCLUDE_THIRDPART_APP=$1
elif [ $# -eq 2 ];then
    OUT_ZIP_FILE=$2
    INCLUDE_THIRDPART_APP=$1
elif [ $# -eq 1 ];then
    INCLUDE_THIRDPART_APP=$1
fi

copy_target_files_template
copy_bootimage
copy_system_dir
copy_data_dir
process_metadata
if [ -f "customize_target_files.sh" ]; then
    ./customize_target_files.sh
    if [ $? -ne 0 ];then
       exit 1
    fi
fi
zip_target_files
if [ -n "$OUT_ZIP_FILE" ];then
    if [ "$NO_SIGN" == "false" ];then
        sign_target_files
    fi
    build_ota_package
fi

以上、make fullota全体のプロセスです.もちろん、update-scriptを生成する方法、target_を生成する方法も含まれています.files.zip類ではないapkにサインするなどここでも詳しくは言いません.小米のpatchromプラットフォームも同様の原理です.Patchromのパッケージング方式から分かるように、修正したframeworkにsmali注入を行ってframeworkを修正する目的を達成するだけで、低パケットのライブラリファイルを変更していないため、patchromは修復しにくいバグが発生せず、patchromのコンパイル速度が速く、プラットフォームコード全体をコンパイルする必要がなく、問題があり追跡しやすい.したがってpatchromプラットフォームはframeworkレイヤとappレイヤのみを変更するromメーカーに適しています.もし問題があれば、下に提出してください.ブロガーは喜んで答えます!ありがとう!