Android Play series: Modify the assembly code to support native HD call dashboard (2)

【

This article is divided into three parts. This article provides a minimal modification case. For more detailed modifications, see article 3:

Http://blog.csdn.net/aimingoo/article/details/7939132

]

(For the first three sections about the background, go to: http://blog.csdn.net/aimingoo/article/details/7939093)

4. Preparations before modification
========
This section describes the basis of reverse engineering on Android. First, we need to operate phone.apk. Actually, we also need a. ZIP file, which includes four main information:
-Resource files: res \ *. * and resources. ARSC
-Code File: classes. Dex
-Application Description: androidmanifest. xml
-Signature information: META-INF \*.*
The apktool tool can process the first three types of data, while the signature information must use a signapk. Jar (some toolkit are called autosign ).

1) Unpack (default to phone directory)
Apktool D-F phone.apk

Note that the subsequent changes do not touch resources, so in fact, you can not unbind the resource files. You can use the command line as follows:
Apktool D-F-r phone.apk

In this way, compilation is faster and some errors can be avoided. -- However, many changes need to be compared with resource files, so you can also extract a version with resource files for reference.

2) Compile. APK (specify the directory from the phone)
Apktool B-f phone phone2.apk

3) Add a signature to phone2.apk
Java-jar signapk. Jar platform. x509.pem platform. pk8 phone2.apk phone2_signed.apk

Note that the signature files used are platform. x509.pem and platform. pk8, rather than testkey *.*. This is critical: phone.apk must be signed using platform.

5. Modification: Preliminary
========
After resolving phone.apk to the phone directory. You can find the following sub-directories:
Phone \ smali \ com \ Android \ phone \

Next we will mainly modify two files:
Callcard. smali
Incallscreen. smali
Note that *. smali is the source code in another format, which is decompiled from the opcode in the Dalvik virtual machine ). Basically, you can think of this *. smali as an assembly code (register-based Virtual Machine engine ). Okay, but since we want to "native", we have to modify the assembly code. :(

1) only one modification is required for incallscreen. smali.
---------
Find:

.field private mMainFrame:Landroid/view/ViewGroup;

Changed:

.field public mMainFrame:Landroid/view/ViewGroup;

We need to access this member in callcard. smali, so it must be public ).

2) Modify callcard. smali for the updatedisplayforperson () method
---------
Find:

.method private updateDisplayForPerson(Lcom/android/internal/telephony/CallerInfo; ...

In this method, find the only showcachedimage () call:

invoke-static {v0, v1}, Lcom/android/phone/CallCard;->showCachedImage(Landroid/widget/ImageView;Lcom/android/internal/telephony/CallerInfo;)Zmove-result v4if-nez v4, :cond_2

Note two points. First, we need to modify this:

if-nez v4, :cond_2

Therefore, write down the cond_2. Second, the above v0, V1, and V4 may be different in the specific code. Note that these registers cannot be used for searching. During modification, you should also pay attention to register conflicts and usage. If you have experience in modification, you should not talk about it. If you have no experience, you should carefully review the knowledge of assembly language.

Next, let's change the above line:

## ===》》》    if-eqz v4, :cond_20    move-object/from16 v0, p0    move-object/from16 v5, p4    invoke-virtual {v0, v1, v5}, Lcom/android/phone/CallCard;->showCachedBackground(Lcom/android/internal/telephony/CallerInfo;Lcom/android/internal/telephony/Call;)Z    move-result v4    goto :cond_2    :cond_20## end fix.

Here, if-Nez is changed to if-eqz, And the label cond_20 is used to insert a piece of code. When the code execution is complete, it will still be:

goto :cond_2

This is the reason for remembering cond_2. As for: cond_20 can be obtained at will, the compiler will automatically number these labels in ascending order in hexadecimal notation, And the 0x20 label is generally relatively large, does not conflict with existing labels. Of course, it can be written as cond_30 or cond_50.

In addition, you must pay attention to the use of the four registers v0, V5, V1, and V4. You must refer to the Code context here to determine which idle registers to use. V1 inherits the previous register value. If callerinfo is not in V1, it must be adjusted according to the context. Anyway, if the register is used incorrectly ...... Haha ...... Crash ~~

[Note: There is a simple way to avoid the problem of using the error register, that is, starting with the method. locals NNN here, the NNN value should be larger, and several registers should be used to add a few. Then, in the code we inserted, only the last register numbers will be used, and there will be no conflict. For example, if it is. Locals 4 and changed to. Locals 8, then the four register numbers V4, V5, V6, and V7 are always safe .]

3) Modify callcard. smali. For the updatephotoforcallstate () method
---------
The modification here is similar to the previous example, except for the updatephotoforcallstate () method. Find:

Invoke-static {V9, V3}, lcom/Android/phone/callcard;-> showcachedimage (landroid/widget/imageview; lcom/Android/Internal/telephony/callerinfo ;) Z move-result V9 if-Nez V9,: cond_2 # modify here

Modify the last line above. To:

## ===》》》    if-eqz v9, :cond_20    move-object/from16 v5, p1    invoke-virtual {p0, v3, v5}, Lcom/android/phone/CallCard;->showCachedBackground(Lcom/android/internal/telephony/CallerInfo;Lcom/android/internal/telephony/Call;)Z    move-result v9    goto :cond_2    :cond_20## end fix.

4) Add the method required for the above Code: showcachedbackground ()
---------
The preceding two functions call a method. showcachedbackground () is the main function implementation code of "Full Screen incoming call. Other modifications are just a plug-in. The Code is as follows. You can directly insert it to a method in the callcard. smali file before/after (I usually put it behind the showcachedimage () function declaration ):

#### [Main function: Update full screen dashboard ]##. method public showcachedbackground (lcom/Android/Internal/telephony/callerinfo; lcom/Android/Internal/telephony/call;) Z. locals 6. parameter "Ci ". parameter "call ". prologue invoke-virtual {P2}, lcom/Android/Internal/telephony/call;-> getstate () lcom/Android/Internal/telephony/call $ state; move-result-object V0 invoke-virtual {v0}, lcom/Android/Internal/telephony/call $ State;-> isalive () Z move-result V0 if-Nez v0,: cond_0: goto_0 return V0: cond_0 if-Nez P1,: cond_1: goto_1 const/4 v0, 0x0 Goto: goto_0: cond_1 iget-Boolean V2, P1, lcom/Android/Internal/telephony/callerinfo;-> iscachedphotocurrent: Z if-eqz V2,: goto_1 iget-object V2, P1, lcom/Android/Internal/telephony/callerinfo; -> cachedphoto: landroid/graphics/drawable; if-eqz V2,: goto_1 iget-object V3, P0, lcom/Android/phone/callcard;-> mincallscreen: lcom/Android/phone/incallscreen; const/16 V4, 0xf0 invoke-virtual {V2}, landroid/graphics/drawable;-> getintrinsicwidth () I move-result V5 if-lt V5, V4,: goto_1 const/16 V4, 0xf0 invoke-virtual {V2}, landroid/graphics/drawable;-> getintrinsicheight () I move-result V5 if-lt V5, V4,: goto_1 iget-object V3, V3, lcom/Android/phone/incallscreen;-> mmainframe: landroid/View/viewgroup; if-eqz V3,: goto_1 invoke-virtual {V3, V2}, landroid/View/viewgroup;-> setbackgrounddrawable (landroid/graphics/drawable ;) V const/16 V2, 0x8 iget-object V3, P0, lcom/Android/phone/callcard;-> mphoto: landroid/widget/imageview; invoke-virtual {V3, v2}, landroid/widget/imageview;-> setvisibility (I) V # const/16 V2, 0x0 # invoke-virtual {P0, V2 }, lcom/Android/phone/callcard;-> setpersoninfostyle (z) V Goto: goto_0.end Method

6. Description of the preliminary Modification
========
In addition to the plug-in code in steps 2 and 3, the entire function depends on a fully handwritten showcachedbackground (). It needs to operate on the current callcard class

CallCard.InCallScreen.mMainFrame

Member. The Member is declared as private in the incallscreen class, so you need to change the Declaration in incallscreen to public in step 1.

The idea of showcachedbackground () is simple. Because callcard. smali always needs to load the profile picture from the "contacts". Previously, we used "HD contact photos" to save this profile picture as "HD, full screen dashboard (picture )", then, you just need to paste the Avatar on the background.

High-Definition full-screen call dashboard is not just to paste the dashboard on the background. ^.

When analyzing the entire phone.apk, I found that it was originally obtained as an mphoto and stored in callerinfo. cachedphoto for ease of display. In this case, when the updatephotoforcallstate () and updatedisplayforperson () Methods of the original process call showcachedimage () to display the image, we just need to "Paste" the image on the background.

The background is: callcard. incallscreen. mmainframe

It's easy.

The above showcachedbackground () assembly code is translated into Java code:

Public Boolean showcachedbackground (callerinfo paramcallerinfo, call paramcall) {// The call is in use (call, call, or call) Boolean bool = paramcall. getstate (). isalive (); // paramcallerinfo. iscachedphotocurrent valid bool = bool & (paramcallerinfo! = NULL) & paramcallerinfo. iscachedphotocurrent; If (bool) {drawable localdrawable = paramcallerinfo. cachedphoto; If (localdrawable. getintrinsicwidth () <240) | (localdrawable. getintrinsicheight () <240) {bool = false} else {// set the background of mmainframe this. mincallscreen. mmainframe. setbackgrounddrawable (localdrawable); // disable the mphoto display (the original portrait does not need to be displayed) This. mphoto. setvisibility (8); // modify the display style of Personal Information (backup, explained later) // setpersoninfostyle (false) ;}} return bool ;}