Reverse Engineering DUO

[Ethanol10]

Hi there, I was attempting to follow ponces guide on how to build a GSI to get a start on modifying this one, however I'm hitting an issue where it can't find default.xml in the main root of the project, is that usual?

[Ethanol10]

To be clear, i'm at step 6 on this page: https://github.com/phhusson/treble_experimentations/wiki/How-to-build-a-GSI%3F

where it's trying to clone the repo from lineageOS, I replaced the URL with the git link here, but to no avail.

[Archfx]

Just use the steps in the treble_experiementation to familiarize yourself with building AOSP since it is a bit outdated now. Once you do that, you will see the similarities in the build.sh and the above steps.

• build.sh automates the entire process, but you have to fix any patch-related issues if exist (using git patch).
• You can create your own public-private key pair to sign the release versions. Steps are here
• Finally, you will need a Linux machine with at least 24GB RAM with 24GB Swap and about 400GB of Disk space with a bit of patience.

Good luck, I hope to see some contributions in the future.

[Ethanol10]

In the meantime, I was wondering how to interface with the pen charger on SD2, I can't seem to follow any SDKs that contain information on this. Do you have an idea on where to look @Archfx ?

[Archfx]

Unfortunately, publicly available content is not that helpful. You have to rely on reverse engineering based on the contents from here.

• Surface duo SDK
• Duo kernel

Thai-ng was very helpful in most of the cases since he worked on the device at Microsoft. However, there were several cases where things were not working as expected with the TD patches (which make the AOSP backward compatible with old kernel devices).

[Ethanol10]

I got the build script running but I've hit a wall with gradle:

--> Building treble_app

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

is this just a matter of downgrading gradle?

[Archfx]

You can ignore the gradle version warnings.

[Ethanol10]

Is there a way to build this into an app to deploy? I would like to test changes but unsure on the build process for this system service:
https://github.com/Archfx/duoPosture

[Archfx]

Yes, you can build using the build.sh, but you can't test the display and other changes without persistent setting in the build file. Since all the production images are signed, you can't replace a persistent app.

One option would be to remove the persistent settings, change the package name to another, and use log files to debug the functionality. Compile, install, and observe the logs working as described. Once done we can move the changes back to the original repo.

If you want to test the app as it is, we have to use eng mode builds instead of userdebug. Then you can replace the persistent mode apps with new ones using adb.

[Ethanol10]

@Archfx Has there been efforts on testing the touchpen1.3 HAL? currently the touchpen only goes up to 1.2, but looking at the vendor partition we can see there's a touchpen 1.3 implementation.

[Ethanol10]

I have a good feeling about this, there is enough evidence to suggest an NXP chip is inside the SD2, (as there is a lib file with NXP hardware) which has support for charging a device up to 1W, which matches the output for the standalone pen charger.

[Archfx]

There are a few places that caught my interest, but unsure if they lead to anything useful.

• in vendor.qti.hardware.factory@1.1/1.0 it contains a function that is called chargerEnable which takes a boolean. Whether or not this is a function used for USB charging or Pen charging, is entirely a mystery unless we try to control it in code.
• Another place is the vendor.qti.esepowermanager@1.0, which contains methods for powerOn and powerOff as well as getState which might indicate some power control, but upon further research the ESE stands for Embedded Secure Element, which may just control the NFC power.
• Last one seems to be in the module vendor.qti.power.pasrmanager,which seems to have a few functions that look like they may control power, but it could also just be something for wireless communication.

My best bet is the first one to be honest, I think if we could look at the SD1 vendor partition, and see its symbols we might be able to figure out something from it, if it also contains a hardware.factory lib but without the chargerEnable function, we might be onto something.

furthermore, looking at the other functions in hardware.factory I see some to enable/disable wifi, so maybe this class contains functions to control system peripherals?

On further inspection, the vendor interfaces we get from treble_aosp seems to already contain this function, which probably means this does not touch the NFC power.

Looks like we have to do empirical testing to figure out what does what.

If you want to test this with a simple app, I can build an engineering version of the image, so that you can boot to it using DSU and install and test these functions. With the production version, you can't do the testing that easily.

[Archfx]

I have a good feeling about this, there is enough evidence to suggest an NXP chip is inside the SD2, (as there is a lib file with NXP hardware) which has support for charging a device up to 1W, which matches the output for the standalone pen charger.

This makes sense. Did the WoA project have this functionality?

[Archfx]

Let me know if you want an engineering build.

[Ethanol10]

I have a good feeling about this, there is enough evidence to suggest an NXP chip is inside the SD2, (as there is a lib file with NXP hardware) which has support for charging a device up to 1W, which matches the output for the standalone pen charger.

This makes sense. Did the WoA project have this functionality?

Unsure, but I was looking around and found some articles on Qualcomm and NXP working together at some point, and I cant find anything regarding wireless charging of the same power (1w~) on Qualcomm's docs, but NXP has a few docs on this sort of device regarding NFC charging on that wattage.

WoA seems to only have pushed for SD1 development right now, so I'm unsure if SD2 has any support for that feature yet.

Seems like they haven't made any development regarding the pen cover charging.