Okay, well today, I picked up a new HTC One X. First impressions were pretty good, and I have to say that as of yet, it's looking like it's a pretty good handset.
However; there's one thing about it that really bugs me. SMS messages apparently force you to use these utterly horrific smileys. I was never a fan of the old android icons that occasionally popped up, but these icons are just plain god-awful. Is there any way of disabling them?
(To be honest, I'd much prefer just to have your standard ASCII faces... Not to mention, if you happen to need to send a message that just happens to have the characters in that order, I'd rather not have badly made face icons appearing in the middle of it..)
bump. I can't believe htc require you to install a 3rd-party sms app in order to be able to get rid of emoticons. I'm a 40-yr old man, I don't want to see a crappy cartoon face in my text messages...
thanks for this nice q
3lliot said:
bump. I can't believe htc require you to install a 3rd-party sms app in order to be able to get rid of emoticons. I'm a 40-yr old man, I don't want to see a crappy cartoon face in my text messages...
Click to expand...
Click to collapse
My thoughts exactly... Not to mention, they're so badly designed that I spend more time working out what emotion they're actually supposed to convey, rather than reading the actual message...
Seems slightly out of place, too. The rest of the UI is nice and clean, fairly sleek looking - then you have these ridiculous cartoon faces slapped accross all of your texts..
I'm going to go ahead and bring this thread back from the dead.
Last time I tired to fix this by modifying my framework files and ended up soft-bricking my phone.
There's got to be a better way.
bump?
Untested Solution
EDIT: I looked more into it, and it gets pretty complicated. According to a StackExchange post I found (link in the attached .txt file), you can go through a process to retrieve the source code from the original .apk file BUT it requires the classes.dex file to be intact. That means you have to de-odex the Message+Nonprime.odex file, "re-dex" it into classes.dex, and add it to the Message+Nonprime.apk archive (can simply change the extension to .zip and add the file before continuing the linked steps).
After following all of those steps, I ended up with the source code and readable XML files. Unfortunately, trying to open them in Eclipse does not work, as I'm apparently missing key HTC resources (or I just don't know where the resources files should be pointing). I was hoping for the ability to just change the name across any necessary files, then repackage, but it doesn't seem to work like this.
I've also tried taking the original APK, adding the .dex file (created from the .odex -> files/folders -> dex process) inside, and signing the package (after deleting the META-INF folder containing HTC's signed information). I was hoping that signing the package after renaming it to Message2.0.apk would allow me to install it as a user application (I don't have root or the ability to change the bootloader to overwrite system applications, due to the 4.2.2 update) but the install always fails since "the application is already installed." If I knew how to modify the files within classes.dex properly, I'm sure I could rename the entire package and create a "New" application, but for now I've hit a brick wall. Hopefully if anyone reads this they can build on my failed attempts.
======================================================
======================================================
I stumbled on this (admittedly old) thread, and I don't know if anyone cares, but I've figured out what seems to be key in disabling smiley images from appearing. Below is the information of the phone I'm working with:
Phone Model Number: HTC One X
Android Version: 4.2.2
HTC Sense Version: 5.0
Software number: 5.18.502.1
HTC SDK API level: 5.41
Android uses "SmileyParser" to watch for certain key combinations and replace them with preset images. The theory is that by changing the strings SmilelyParser checks, it won't ever find a match, and they won't be replaced.
I found the Message application under /system/app/Message+Nonprime.apk. HTC's Message application utilizes Android's android.com.mms but has custom functionality/themes (I'm assuming)
Using ADB (Android SDK tool to browse filestructure), I used "adb pull [source] [local]" to copy the .apk and .odex files
I used "smali-#-#-#.jar" and "baksmali-#-#-#.jar" to convert the .odex file
The output of the tool gives a file structure with editable files. I navigated to com/android/mms/util/
In this folder, there are two key files: SmileyParser.smali, and SmileyParserOne.smali. I believe the "One" version may be modified to work with HTC One phones, but I'm not 100% sure (content looks similar)
I opened each file with Notepad++ and found "const string" references with the text version of an emoticon. The code seems to match those with "aput objects" but I don't know 100%
I modified each string (within the quotes) by just adding an 'x' to hopefully thwart the string match. Basically, the phone should wait until x or x is fully matched before replacing the smiley
I'll note again, I did the EXACT same process in both .smali files I mentioned, and I touched ABSOLUTELY NOTHING ELSE. There's no telling what you'll break if those don't compile correctly (which is why I also avoided adding a longer string, in case memory allocation issues cropped up)
I then repackaged the entire output I created into a new .odex file
Now, here's where things get tricky. I don't have a rooted phone, so I can't actually replace the .odex inside of the /system/app folder. I may work on testing on my phone (but I don't get a lot of time and really would not like to brick it), but I'm worried since I'm running a very recently updated Sense version (and there may not be reliable root processes, I have no idea).
If anyone has a rooted HTC One X (check above for the exact software version I have) that would like to try out the modified .odex file (apk is mostly UI/theme, .odex contains the actual programming logic) I am providing the .zip containing the apk and odex files. I've also tried installing the apk+odex with "adb install X/X.apk" but the application has a name buried in the structure (probably everywhere) and I have no idea how to rename it everywhere that's required.
If someone knows how to take a package and re-compile it with a new name, I could potentially re-install "Message 2.0" as a user app without any root privileges required. That's another option I'm looking into (since I'd really rather not root and potentially lose my stored data).
The same problem is still occurring in 2018. I would try your solution, but it's outdated. I'll have to dive in and edit the files myself if a solution isn't found. Although, in that case, I would probably match something further from the x, preferably with 2 bytes because as you said, memory issues might pop up and I'm not sure just how far they went with this.
The purpose of this thread is not to pirate swiftkey 3, but to edit the keyboard to allow custom smilies and hotkeys. Using APKtool 1.5 HERE I can decompile, but cannot recompile. Ideally it would be nice to be able to just replace the applicative xml file that is customized into the app that will then be installed. However, recompiling fails, and replacing the xml does not allow the apk to be installed (even after resigned).
When swiftkey is decompliled, /values/strings.xml has a list of all the keys and their outputs; if the app can be successfully recompiled, we can make completely custom layouts.
I have a feeling that swiftkey uses an encrỳpted apk; how can we get around that to edit the apk at will?
The underlying purpose here is to be able to convert xml from an apk to readable xml then reconvert into binary xml so that simple xml replacement can be achieved.
If it makes a difference, I downloaded swiftkey 3 from the amazon appstore. (I have a feeling that the amazon appstore has some sort of custom encrỳption)
shameless bump because I've been looking for an answer for months now
Same thing
Hey man, I've been trying to do this for the past few days. I could not get around it at all! Tried few different things, but no luck!
Developers are making their apps now so they can't be edited this way. I know of a few that are doing it so that the min they are decompiled they corrupt the code so it it can't be recompiled and ran. This is most likely what is happening
Wayne Tech Nexus
Hi,
The radio app that came with my Xtrons (Oreo) GS PX5 head unit, is OK but I think I could make a lot of improvements
So I've got ADB root to my device via Wifi and looking in the system/apps folder I can see MTCRadio4HCT which I presume is the radio app.
Inside that folder is ..
MTCRadio4HCT.apk
and the oat folder which contains an arm64 folder, which contains MTCRadio4HCT.odex and MTCRadio4HCT.vdex
I've decompiled APK's before to extract assets, but not odex or vdex
Before I go to the trouble of trying to decompile and recompile the radio app.. Does anyone know if its already been done by someone else ?
As I've never decompiled and recompiled an Android Apk before, I don't know whether this is practical or not.
I've decompiled and recompiled a lot of C# applications on Windows, and they always need a lot of work to clean up the decompiled code before they will compile and run, so I presume the APK / Java decompilers are similar (or possibly worse)
radio app...
this apk from Malaysk ROM Oreo v2.0, and has classes.dex.
good luck!!
rabbity417 said:
this apk from Malaysk ROM Oreo v2.0, and has classes.dex.
good luck!!
Click to expand...
Click to collapse
Thanks
I'll try decompiling that one, as well as the one I pulled from my HU.
BTW. List of things I'd like to fix
1. Current station preset / memory is not very obvious. There is a slight change to the text colour on the button for that preset / memory, but its hard to see at a glance when driving
2. Names can't be assigned to AM stations. Ideally, It would be nice if once a station / preset / memory had been assigned, that a name could be given to that preset / button, rather than just the frequency.
Additionally, on FM some stations cycle their name e.g. ABC Classical radio, seems to broadcast its name as "ABC" then "Classical" then "Radio". So on my radio it just shows this as ABC, but there are multiple ABC stations in Australia as its government funded, with Pop, Classical and News and General stations.
3. No way to change from AM to FM via the steering wheel controls.
4. FM station preset / memory buttons, all go back to displaying their frequencies when the App is scanning. I think the same may apply when changing memory / preset.
I can't see why this should happen. The name associated with the preset / memory , must be stored by the App as soon as it gets the name from the FM transmission its self.
And it can only get the name of the station its currently tuned to.
Hence it doesn't make any sense for it to only show the names on the FM preset, when its got the name of the current station via the FM signal.
5. It would be better if unassigned preset / memory channels were blank, and skipped by the steering wheel controls.
I'm sure there other annoyances that people have
RogerClark said:
Thanks
I'll try decompiling that one, as well as the one I pulled from my HU.
BTW. List of things I'd like to fix
1. Current station preset / memory is not very obvious. There is a slight change to the text colour on the button for that preset / memory, but its hard to see at a glance when driving
2. Names can't be assigned to AM stations. Ideally, It would be nice if once a station / preset / memory had been assigned, that a name could be given to that preset / button, rather than just the frequency.
Additionally, on FM some stations cycle their name e.g. ABC Classical radio, seems to broadcast its name as "ABC" then "Classical" then "Radio". So on my radio it just shows this as ABC, but there are multiple ABC stations in Australia as its government funded, with Pop, Classical and News and General stations.
3. No way to change from AM to FM via the steering wheel controls.
4. FM station preset / memory buttons, all go back to displaying their frequencies when the App is scanning. I think the same may apply when changing memory / preset.
I can't see why this should happen. The name associated with the preset / memory , must be stored by the App as soon as it gets the name from the FM transmission its self.
And it can only get the name of the station its currently tuned to.
Hence it doesn't make any sense for it to only show the names on the FM preset, when its got the name of the current station via the FM signal.
5. It would be better if unassigned preset / memory channels were blank, and skipped by the steering wheel controls.
I'm sure there other annoyances that people have
Click to expand...
Click to collapse
wow!!! it would be great!! :good:
if you have done, plz share it..:laugh:
rabbity417 said:
wow!!! it would be great!! :good:
if you have done, plz share it..:laugh:
Click to expand...
Click to collapse
Thats the list of things I'd like to change. I've not started to try to do it yet.
It all depends on how well the App decompiles, and how difficult it is to recompile it.
Its been a while since I did any Android dev using the SDK, as I generally use Cordova for the simple Apps I need - and don't get my hands dirty with the Android SDK / API.
But I am a professional developer, (mainly C# at the moment) but also Javascript, C , PHP etc. And I've done several decompiles / recompiles of obfuscated C# apps.
I don't know if you are new to APK modifications but Decompile/recompile is not hard, even understanding Java code is easy.
The pain come when you start modifying the smali code.
I suggest you to use "jadx"or similar tool to obtain Java code of the APK, then modify the smali and recompile.
Good luck
rabbity417 said:
this apk from Malaysk ROM Oreo v2.0, and has classes.dex.
good luck!!
Click to expand...
Click to collapse
I tried one of the online decompilers, and the APK from my HD just decompiled to the XML layout files and no Java code.
The APK from the Malaysk APK looks more promising as it does contain Java code, when decompiled, but looking at the graphical assets, it looks a lot different from the app in my (stock) ROM.
I'm doing to install the APK from Malaysk and see if it actually works on my HU. I'll update this thread when I find out.
I'll also see if I can decompile the vdex and odex that go with my APK file.
Edit.
Decided not to install the Malaysk as the Apkinstaller said it would overwrite the existing radio app.
as they both have package="com.microntek.radio"
Looking at the decompiled manifests, it looks like the APK from the Malaysk ROM requests more permissions to the APK in my "stock" ROM
ission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.WRITE_MEDIA_STORAGE"/>
<uses-permission android:name="android.permission.ACCESS_ALL_EXTERNAL_STORAGE"/>
<uses-permission android:name="com.cyanogenmod.lockclock.permission.READ_WEATHER"/>
I'll see if I can find any screengrabs of the Malaysk version to see if it looks different, as its strange that its requesting storage, when its just a radio app and not a music player
To view the Java code you need JADX or similar tool, follow this guide:
https://ourcodeworld.com/articles/read/387/how-to-decompile-an-apk-or-dex-file-using-jadx-in-windows
The obtained Java code cannot be used to recompile the APK.
To be able to recompile you have to use apktool to Decompile into smali code.
The smali code can be recompiled into the apk with apktool.
There are many custom apktool versions with GUI or batch commands that make easyer the process:
Batchapktool, Easyapktool etc...
KoTiX2 said:
To view the Java code you need JADX or similar tool, follow this guide:
https://ourcodeworld.com/articles/read/387/how-to-decompile-an-apk-or-dex-file-using-jadx-in-windows
The obtained Java code cannot be used to recompile the APK.
To be able to recompile you have to use apktool to Decompile into smali code.
The smali code can be recompiled into the apk with apktool.
There are many custom apktool versions with GUI or batch commands that make easyer the process:
Batchapktool, Easyapktool etc...
Click to expand...
Click to collapse
Thanks
I'll checkout the various apktools. BTW. I presume they handle odex and vdex files (as this app has both)
BatchApktool have a function for deodexing the apk.
I don't know if it deodex function work for Oreo too.
KoTiX2 said:
BatchApktool have a function for deodexing the apk.
I don't know if it deodex function work for Oreo too.
Click to expand...
Click to collapse
Probably a really stupid question, but I've tried apkeasytool on the Malaysk radio apk, and the source it generated is smali, which is really hard to read
But I also tried this online tool http://www.decompileandroid.com/ and it seemed to generate both smali and Java.
As far as I can tell the Java files the online tool created are the Java equivalents of the smali code.
I have some knowledge of programming in Java, but smali is a totally new language to me.
I guess I'll need to try creating an android studio project using the manifest and resources and Java code (and omit the smali) and see if it compiles ?
Smali is intended for small code modifications without the need of creating your own Studio project.
Is not so hard to modify but of course is just for small things.
Once you are used to it become a little more friendly but still not as much as Java or more normal languages
KoTiX2 said:
Smali is intended for small code modifications without the need of creating your own Studio project.
Is not so hard to modify but of course is just for small things.
Once you are used to it become a little more friendly but still not as much as Java or more normal languages
Click to expand...
Click to collapse
Thanks.
I'll need to work out the best way to do this...
I can decompile the Malaysk , to smali and could probably make small changes e.g. change the text colour on buttons etc. However to implement the more complex changes, would probably be impractical in smali.
I'm also not keen on overwriting my existing radio app by installing the version from the Malaysk ROM, as I don't know for sure if it would work (because there are potentially difference in MCU version).
I may have a go at renaming the Malaysk radio app, so it would install as a separate app, but I'd need to change a lot of files and it could be a pain to get it to recompile.
The Malaysk radio app apk seems to decompile to java via one of the online decompilers, so I may try creating a very basic / almost empty project in Android studio, with the same package name as the radio app, and then copy the decompiled xml, java and graphic asset files into that project, and see if it will compile
But I guess its probably not going to compile or probably not run.
I've also used the APK Easy tool to decompile the app thats in my ROM (system/apps), and used its separate odex decompiler to extract the smali for my stock app.
My concern is that if I try to change the app, and break it, then it could be hard to get back to a working version (and in the mean time I don't have a radio in the car)
I do have the system/app folder backed up to my PC, so in theory, if I break things, I could simply copy the backup of the odex file to the head unit, but I'm not sure if that would be sufficient to restore the operation of the radio
Another option is to just work out how the existing app (or the Malaysk version of the app), interfaces with hardware (MCU etc), and write a radio app from scratch.
As far as I can by looking at the current functionality, the radio only has a few functions, i.e control the "tuner" hardware to select the frequency, turn on an off various settings to do with TA etc.
But again, this would probably be big job.
Anyway, plenty for me to think about
It doesnt look like making changes to the radio app are possible because the smali files have decompilation warnings in them using the APK Easy tool
e.g.
#disallowed odex opcode
#iput-object-quick v0, p0, [email protected]
I've had a look at the decompiled java files from the Malaysk ROM version of the radio app (apk), and I don't think the radio app is controlling the hardware directly
It looks like the hardware handling is in android.microntek.CarManager;
But I'm not sure where that code is.
I presume its in the framework somewhere. e.g. possibly in
framework\arm\boot-framework.vdex
I've looked in my entire backup of the system folder, there is nothing named *.CarManager.*
Is it possible to listen to all events that are being broadcast, e.g. perhaps from the terminal, or via a debugging app ?
I've looked for an app to do this, but the best one I found is https://play.google.com/store/apps/details?id=lt.andro.broadcastlogger and it still only shows specific broadcasts
Perhaps I need to write my own debugging app to show broadcasts with com.microntek.* , and see whats flying around
(BTW. This is the limit of my Android knowlegde, so I'm not even sure if I can write an app to listen for any com.microntek.* message, or if it needs to be more specific ????)
Edit
I think I found the CarManager
Its probably priv-apps/MTCManager.
Just decompiled the odex, and I'm taking a look inside
Try logcat
you can specifiy what it shall display from the log it reads.
type in com.microntek. and it should only list the log entries with that.
The radio apps are almost the same for all MTC devices, you can even run the APK from Android 6 firmware on Oreo (if signature is not a problem) or even more the radio apk from px3 7.1 firmware.
The one in Malaysk is probably slightly modified by him.
I would look also in the Booroondook rom too:
https://4pda.ru/forum/index.php?showtopic=891403&st=0#entry70937201
Anyway if you need to change something in all the files all in ones, you can use the function "replace in all files" in notepad++
I'm on vacation until next week otherwise I could help you with smali and tests on my desk unit.
no need for smali, using APKRepatcher you can decompile, edit java code, build and compile APKs... unfortunately there are complie errors for the HCTRadio apk (CarManager related + other stuff)
k0sTi said:
.... unfortunately there are complie errors for the HCTRadio apk (CarManager related + other stuff)
Click to expand...
Click to collapse
Yep. That's the problem
None of the apps seems to cleanly decompile to valid smali code, which I presume means they can't be recompiled back to a usable app.
Unless perhaps the compiler is able to reconstruct the error opcodes in the smali back to the same odex / dex as before.
I have not tried decompiling then recompiling the odex to see if it would recompile. Or perhaps decompile , recompile and then decompile again - and see what the result it.
As my HU is now in the car, and I use the radio, I don't want to break the existing radio app.
KoTiX2 said:
Anyway if you need to change something in all the files all in ones, you can use the function "replace in all files" in notepad++
Click to expand...
Click to collapse
Yes. I used Notepad and its find in files and replace in files is great.
I may be able to replace MTCRadio by MTCRadioNew and change the app name, so I can run my own copy.
However, its dependant on being able to decompile and recompile the code... And I'm not sure if thats possible.
I guess I should give it a try when I get some free time.
PS. Thanks for the link to the other ROM. I've downloaded it, but I've not had time to look in the image files.
But it seems to have the same date as another ROM someone else posted in a different tread on XDA, called "PE 系列 gs5_PX5_8.0_升级包(20180118" ( Translates to PE series gs5_PX5_8.0_ upgrade package (20180118) )
BTW. I wonder how Malaysk managed to modify the radio app. He must have deodexed the APK, as the APK from his ROM does not have a separate odex file, and he also must have decompiled and recompiled it (either to smali or to Java)
Hope it helps... here seems that someone correctly decompiled the Java inside the CanBus App...
RogerClark said:
BTW. I wonder how Malaysk managed to modify the radio app. He must have deodexed the APK, as the APK from his ROM does not have a separate odex file, and he also must have decompiled and recompiled it (either to smali or to Java)
Click to expand...
Click to collapse
Of course he firstly deodexed the APK than he Decompiled, modified the smali and recompiled.
I did the same to add the numkeyboard to the radio apk in Android 6
Smali is always created correctly and recompile is always possible unless you make mistakes on the code.
the Java decompilers sometimes cannot generate part of the code.
You can give a try to Procyon too:
https://bitbucket.org/mstrobel/procyon/downloads/