[HD2 Android NAND Development] aread22:
Fixing the Share Menu

Here is how I went about fixing the share menu.

I first have to start off thanking pyrorob for starting this thread and all the help he gave posting the tools necessary to decompile/recompile .apk packages. (Post #3)

After setting everything up, I combed through the logs and noticed that after clicking the share or setas button, the following would should up in alogcat:

W/CameraThread( 2674): Store image - directory name=/mnt/sdcard/DCIM/100MEDIA, file name = IMAG0012.jpg
W/CameraThread( 2674): Store image: content://media/external/images/media/276
W/ActionScreen( 2674): setSaveDone() - mSaveDone = true
W/TIME ( 2674): StoreJpegImage, Cost Time = 740 ms
W/ActionScreen( 2674): Block Action Screen - press button: 1
D/AndroidRuntime( 2674): Shutting down VM
W/dalvikvm( 2674): threadid=1: thread exiting with uncaught exception (group=0x40025a90)

This is the line

that stuck out to me since it is the last line before everything dies, so starting there I jumped into the ActionScreen.smali file and looked for the the string "Block Action Screen".

I found that string on line 1684 in the method selectActionScreen(I)V. Below is a snippet from that method

1678: sget-object v0, Lcom/android/camera/ActionScreen;->TAG:Ljava/lang/String;

1680: new-instance v1, Ljava/lang/StringBuilder;

1682: invoke-direct {v1}, Ljava/lang/StringBuilder;-><init>()V

1684: const-string v2, "Block Action Screen - press button: "

1686: invoke-virtual {v1, v2}, Ljava/lang/StringBuilder;->append(Ljava/lang/String;)Ljava/lang/StringBuilder;

1688: move-result-object v1

1690: invoke-virtual {v1, p1}, Ljava/lang/StringBuilder;->append(I)Ljava/lang/StringBuilder;

1692: move-result-object v1

1694: invoke-virtual {v1}, Ljava/lang/StringBuilder;->toString()Ljava/lang/String;

1696: move-result-object v1

1698: invoke-static {v0, v1}, Lcom/android/camera/LOG;->W(Ljava/lang/String;Ljava/lang/String;)V

Now, if you have done any java programming you would know what is going on here; instead of concatenating strings together - which is inefficient in java because Strings are immutable - HTC is declaring a StringBuilder Object (basically an array) and appending the necessary Strings to the StringBuilder Object and just calling the toString() method on it. They then pass 2 Strings to the Static log class to be printed out to the log file 1) The name of the class they are in and 2) The string they want to print out.

So in alogcat that would produce something like this:

The reason I mention all this is because knowing how to print out to the log file in smali was the key to me being able to debug the code. After I learned how to use that method, I just setup the following lines of code:

const-string v2, "TESTING"

invoke-static {v2, v2}, Lcom/android/camera/LOG;->W(Ljava/lang/String;Ljava/lang/String;)V

And pasted that after each line of code in the method - changing the necessary registers of course (v1, v2, v3, etc). Then recompiling the apk, running the camera, checking alogcat if force close. If I saw "TESTING" in alogcat then that meant the method that died was below my print code. After doing that for 2 days, I finally came to the following line in IntentManager.smali

Then like I said in my previous post (#42), I just compared the files in the /rotate folder, noticed the difference, changed the necessary files and tried out the apk - and lo and behold everything worked!

In brief, this is what happens when you click the share button: HTC assigns a number to the button on the ActionScreen ( 0 - SetAs Button, 1 - Share Button, 2 - Delete Button, 3 - Go To Camera Button ) and depending on the number, a method is called: (0 - doActionFourth()V, 1 - doActionSend()V, 2 - doActionDelete()V, 3 - doActionCamera()V). In doActionSend it uses the following line of code to get the share items:

In HTCCamera.smali the shareIntentChooser method there is basically a wrapper for the real shareIntentChooser in IntentManager.smali

The shareIntentChooser method in IntentManager.smali is the one that does all the dirty work in getting all the share items. So like I said above, it was bombing out on this piece of code:

and I think the reason why is because by the shareIntentChooser method signature, when you call the shareIntentChooser method you should expect to get a Dialog object in return. It wasn't doing that since the const in AlertParams were messed up, hence why it was force closing.