I’ve tried renaming bin to zip - doesn’t work… 7z doesn’t recognize it as archive of any sort… Tried doing it with SM 2.0 firmware and the J1, same thing.
And a small guide of how I accessed the back end - https://forum.snapmaker.com/t/guide-how-to-install-apps-on-your-snapmaker-2-0-lcd-access-android-part-of-lcd/
2 Likes
Huh, it worked for me.
Here’s the the latest firmware bin for the 2.0 (downloaded zip, renamed to apk, and then decompiled with jadx): resources.7z - Google Drive
And here I decompiled the dex classes (used fernflower) to get the java source: sources.zip - Google Drive
Looking at XYZMoveController in com/snapmaker/data, it looks like the code we’re looking for is going to be the “slaveComputer” connection. If someone was willing to make octoprint talk to “slaveComputer”, it looks like we can just send gcode directly.
Of course, that’s a bit of an undertaking, and would require extracting all of the stuff that makes “slaveComputer” work, and integrating it into the octoprint android app…
3 Likes
Wet Dreams Of Klipper…
Did you try decompile the artisan firmware. i try on my side without success
Here’s artisan: Artisan_V2.7.3_20240716.apk/resources - Decompiler.com
But you’ll need to also decompile the dex files to get java sources.
I also took a bit more of a peek at the 2.0 app, and it’s using some more modern Java that jadx doesn’t decompile well (lambdas everywhere), so I’ll need to use dex2jar, but I’m AFK for a few hours.
Ok, a bit further, here’s the source code decompiled with a better decompiler so we get more usable “source code”: snapmaker fab 2.0.zip - Google Drive
Seems that everything communicates over the serial communication (the “slaveComputer” is actually SerialController).
If there’s anyone that’s more familiar with the octoprint app, we could just pull SerialController from the app, and use the sendGcode command to send gcode over to the machine (IIUC, that’s what octoprint is doing, just over a USB connection).
2 Likes
Klipper would be neat, but that’s going to require updated firmware on the machine side. I don’t think the HMI running android will be able to successfully run as the klipper sbc, but maybe it could work (there was someone who did it for the original, but I don’t think the original is controlling everything over CAN like the 2.0 does).
So excited about all of this!
I am dreaming of running the touchscreen or a phone with a camera (over bt or something else) and obico-app (guess was the first AI spaghetti detective) observing my prints…
A few things which didn´t work with octoprint so far (not actively tested a long time…) were,
- filament runout “detection”
- power loss “detection” and recovery
Looking forward to you guys and hoping you make any progress for a better interface!
Please share anything 
I’ve been thinking about filament runout detection, IIUC, the machine probably sends a serial message to the HMI when a runout is detected, if we can run our own android app on the HMI, it could probably listen to serial events. This would require that you again make octoprint app able to receive events from the HMI. But honestly, just updating the machine firmware to send a gcode message and having octoprint listen for that would probably be easier.
I’ve been looking a bit more at the (decompiled) code, it looks like a lot of the functionality that the HMI does (e.g. running the auto leveling sequence for the dual extruder) didn’t decompile correctly so we won’t be able to see that (unless there’s another decompiler that works better, I’m thinking the original source might have been kotlin even).
However, the whole serial packet system seems to have decompiled sanely, so we won’t have to reverse engineer that part at least. I might try to throw together a small sample app in the coming weeks (kinda busy right now though).
3 Likes
it appears this android device is connected via some serial cable. im not sure if its possible to replace it from the front. but via the rear maybe with a normal otg cable it would work with their apps installed on another device.
EDIT: sorry i forgot this is the snapmaker 2.0 and not my j1s lol. maybe my idea only applies to my machine. happy hacking though
From what you have written about the J1s filament runout, the 2.0 and J1s seem similar about the touchscreen communication so please share your thoughts here as well ;-).
1 Like
I think the same thoughts as @xchrisd - the HMI interface was probably ordered from the same supplier - so it should share the same backend…
So far it looks like the FAB app is crashing because of missing components, I’m trying to transfer more APK files onto my phone to see if it works.
@nivekmai do you think there is a layer running as a service to translate communications from APK => SERIAL LAYER => controller?
There is some documentation about this - Snapmaker2-Controller/docs at main · Snapmaker/Snapmaker2-Controller · GitHub
Also, it seems that the device is rooted. We should be able to get full access adb shell to into it. I’ll try this weekend.
1 Like
Is the device actually rooted? AFAIK no one’s shown su working, so far the only thing that’s happened is escaping FAB app. I don’t expect an ADB connection to be any more likely than it was before (I think someone already tried, but I haven’t personally).
Perhaps if we can get to the developer settings, we can turn on USB debugging, which would get adb working somehow (but it might only be with the HMI plugged directly into the computer, and not when going through the USB port on the controller, but but, since the advertise device can access the USB stick, there’s hope).
As for the service you’re thinking of, that’s the SerialConnection I mentioned above, it’s just some Java code inside the fab app. There’s a few custom commands that are direct serial messages, but we also have the ability to just send gcode.
As soon as my new baby (2.5 months) goes down, I might try to play with it today and build a super simple app that tries to send a single gcode command over the uart serial connection. (But I’m also busy with my “3d mouse” that I’m trying to build, so that could steal my focus 
)
1 Like
Done 
I’ll try to get the adb running to SU it. I think it is rooted because APK extractor complained about not being able to pull the FAB apk. And offered to do it via root - I said yes and it did it no problem.
2.5 month baby! CONGRATS! I’m surprised you have any time for these shenanigans at all Unless you gave up on sleep…
I assume one thing that certainly is missing on your other phone is the serial connection. I have no idea how Snapmaker created it - if they use a serial interface of the touchscreen’s controller or an USB-to-UART bridge chip. In any case I’d think it likely that your Smartphone will need to provide a serial interface and that most likely it needs to be somehow configured into the FAB app.
I seem to remember that someone once had a photo of the innards of the touchscreen, but I cannot find it… This may help to find out how Snapmaker implemented it, but after all it might not even be of interest, since for a different device the best way forward to me seems to get a USB-to-serial adapter like this one: USB to TTL Serial Cable - Debug / Console Cable for Raspberry Pi : ID 954 : Adafruit Industries, Unique & fun DIY electronics and kits - then attach a USB hub to the smartphone’s USB port, and from this hub connect one USB port to the USB-pins of the USB-C plug, and connect a second port to the USB-to-serial bridge, and then the serial to the relevant pins of the USB-C plug. Remains the SC_DET pin (awesome-snapmaker/images/Snapmaker_Parts/SP_2.0/LCD_Connector/Pinout_Ref_Img_1_LCD_Screen.jpg at main · shurushetr/awesome-snapmaker · GitHub) - this one might need some attention. It may just be something that switches logic level as soon as the Controller is ready to receive serial commands. Depending how this is in the code, it may be a dealbreaker or not…
EDIT: Perhaps SC_DET can be mapped to RTS/CTS pins of a more complete Serial bridge like this one: FTDI Serial TTL-232 USB Type C Cable - 3V Power and Logic : ID 4331 : Adafruit Industries, Unique & fun DIY electronics and kits
2 Likes
Good point about the UART interface, we just need to look at the drivers available in the android to see what’s up. I think I bet they went with the cheapest option available that is supported by the ancient Android. This is a good thing tho, as support for it should be wide spread.
1 Like
Not sure if I mentioned this video already: https://www.youtube.com/watch?v=74xdib_-X38 Thomas Sanladerer here shows how to run OctoPrint on a Smartphone, and it seems that the USB-UART-bridges used in many printers are out-of-the-box recognized by Android. So I would guess you’d be unlucky if you would find one that does not work
2 Likes
My todo list just got another item in it
Why do we need to connect another Android phone? If we have adb we can just install an app.
Maybe I’m not sure what we’re trying to accomplish here… If it’s just running octoprint on the HMI, it seems it’s just a matter of making the octoprint Android app speak via the SerialConnection interface in the FAB app, which seems simple enough (someone just needs to write the code).
There’s no need to do any hardware hacking.