[MOD] MMS Not working for you? Heres a fix! - Fascinate General

Hello!, I've personally seen people struggle on these forums having a MMS Related issues, and i can honestly say more or less its not as much the rom, but more of the Files in it in general for your APN (access point names) and i know some of you already made this method by your experience, but i have still gotten requests for "how the h**l did you fix your MMS!?!?!!!!!! (enter any CDMA carrier name here) hasn't worked for me since android ICS! (Android 4.0.* )!!" Well i can honestly say its not as much as the MMS.apk (default Android SMS/MMS messenger), as much as it is the apns-conf.xml file in the /system/etc directory! i know this post may seem stupid to some higher-up knowledgeable people, but there's too many common-day users who have this issue and i'm getting frustrated as i'm trying to make better roms/apps and being distracted with hangouts messages/emails/PM's and even somehow random Facebook messages, that i'm just going to release my flashable zip that i use for my rom, and implemented to my future rom zips as an overlay, but for those with Constant MMS Related issues the main problem is that Cyanogenmod has the apns-conf.xml in single string notations (all in one line), while on some and or most APNs needed for carriers are needed to be separate lines for data/mms/tethering and so forth, so for the basic ones that i know this device (Samsung Fascinate) is usable with: (Straight talk, Verizon, Metro PCs, even Sprint / T-Mobile / and AT+T if you have you rom spoofed as GSM using a modified Voicemail Notification GSM Spoofing Exploit from the GEEWiz Rom's Github+some of my own ides mixed into it), and integrated the right codes into the rom+build.prop, as the radio still makes it read as w/e as I've tested using ESN/MEID tricks in-rom codes to test carrier signals (unreleased as its unstable, but i used a homemade Debugging method in the build.prop entries for carrier codes, and signal modifiers so ti can be done if you build from-source) but anyways here's a MMS Fix for the common CDMA Carriers this device is known to use in one flash-able zip (No MMS.apk included so it can be used with ANY Android version, but if it is MMS.apk's issues you wont have any MMS so you can test using this zip BEFORE complaining to the rom developer) Should work on ANY CMDA device, but i more focused on this one, but has proven to work on Samsung Galaxy S3 Running Verizon ( friends device on STOCK Rom (with custom recovery tho) having MMS Issues)
***Credits to Slim-Rom Developers At Least as i used their apns-conf.xml as a base with minor modifications***
Download:
http://www.androidfilehost.com/?fid=23329332407589477
(if Error 404 file not found in the future since this posting, it is because it hasn't been downloaded within Android-File-Host's Required since-last-download time restrictions from their Terms-of-Services)

Related

[FIX]AT&T Carrier Billing for 4.3 ROMS

thought this may help more if i post it in general instead of the ARHD thread. Thanks to Garmig for his original post i found with the additions to the build.prop for 4.1 or 4.2 roms, cant quite remember
Tested this on ARHD (4.3) and Trickdroid (4.3), but i imagine it will work on all 4.3 ROMS
okay so after a little playing around i managed to figure out which build.prop lines to add to enable carrier billing on google play market for AT&T users so that it actually works without breaking mms.
originally i found a post by user Garmig which showed these additions:
ro.com.google.clientidbase=android-htc
ro.com.google.clientidbase.yt=android-htc
ro.com.google.clientidbase.am=android-att-us
ro.com.google.clientidbase.gmm=android-htc
ro.com.google.clientidbase.ms=android-att-us
after applying those additions to the arhd build.prop it enabled carrier billing for att successfully, but somehow breaks mms? not sure how but it did
so i played with the lines independently and figured out that if you add only these lines:
ro.com.google.clientidbase=android-htc
ro.com.google.clientidbase.yt=android-htc
ro.com.google.clientidbase.am=android-att-us
it will successfully enable att carrier billing without breaking mms. maybe someone more experienced can answer why one of the two last lines woud break mms, but either way, maybe some of the other att users using arhd 20.1 will find this useful, and garmigs original post that i found
Best to use Root Explorer or a similar app to make the changes, be sure to make a nandroid before messing with the build.prop or you may jack your phone up

[PLEASE HELP] MMS Issues on JFLTEVZW KK RC-3 dev

This seems to be an issue on any CM-based ROM I use, but I really like PAC and the features it has so this is especially troubling to me.
I am on a VZW Galaxy S4 (SCH-I545, I545VRUAMDK baseband) with TWRP recovery, ktoonsez kernel 3.4.104.
Every time I install a CM-based ROM I cannot ever send or receive MMS messages through Hangouts, or any other messaging app.
When I look at Mobile Network Settings and check Access Point Names from within the system settings menu, I see Verizon APN info. The one I have enabled currently is the default VZWINTERNET one.
However, when I go into Hangouts and check my APN info there, I see APN entries for Sprint and MetroPCS. I cannot change any of them, I cannot add any of my own, I cannot manually input Verizon APN info, because they don't ever save. I can delete them all and render my phone unable to send or receive anything, but recover them by restoring default.
It's because of that fact that I believe that this is due to the ROM itself.
I first noticed this a year ago when I was using CM 10 and 11 release candidates, after CM switched to unified builds instead of carrier-specific ones. Since then I've flashed other ROMs like Dirty Unicorns and the like, and the ones that are based off the CM Unified builds always carry the Sprint/MetroPCS APNs in Hangouts.
This prevents me from ever sending or receiving MMS messages from anyone regardless of carrier of origin.
I've tried apps and tweaks to resolve this, but nothing works. The only thing that ever does is switching to a non-CM core ROM, but I like the feature-rich PAC-ROM the most.
Does anyone know of a definitive way of resolving this issue? A hack? A manual change to the system files?
I tried running a search of XDA, as well as good old fashioned Google, but all I can ever find are blog posts with suggestions and "definite" fixes that never work.
At this point I am a little desperate for help. Every time I've posted a help thread, be it here, the S4 official subforum on XDA, or Reddit, or the PAC forums, I get nothing, not a single reply.
I cannot be the only one who has been experiencing this.
Please advise.
Thank you,
I am experiencing this too, and APN settings dont seem to help.

How to have official DocumentFile restrictions on Roms?

Hello all,
Starting of Android Lollipop (5.x), Google presented an official API for accessing the SD-card (among other things) called "DocumentFile" or SAF.
It's quite a restricted API compared to File, but that's the official way to use files.
Yet, up until now, because the File API was used for all apps, rom developers always chose to allow File API to be used and work even for SD-cards.
While this is nice for power users and maybe people who don't care about it, this is bad for me as a developer, because I need to have those restrictions (of forcing me to use the DocumentFile instead of File) as they exist on real stock roms.
It's not just me, but I've found a lot of apps out there that don't use the official API at all. Even "Total Commander", an app I'm still using, can't fully use it, as when I ask to send multiple files to it using DocumentFile, it fails.
Sadly, other than the real stock rom of Samsung (and not those based on them, or of course those like CM) , I can't find any rom that when using File API - it won't let me modify the sd-card files.
Now that Android 6 is coming, I think it might get even weirder, as there will be a new permission mechanism for storage.
My question:
Is there any rom or anything I can easily do (i'm not a rom developer) to have near-stock experience in terms of accessing the SD-card?
I hope I'm clear on this. English isn't my main language, so I've tried to find alternative ways to express what I want to talk about.
Maybe one of the GPE roms around here. But those are only for the GT-I9505 model.

Will there be a fully functional MM 6.0.1 Rom for the Note 3 with Verizon Sim?

So, I have tried Darkwolf and had problems with it. I couldnt change my APN settings, couldnt get ES File Explorer working, ect. I am feeling really discouraged.
We have had unlocked boot-loaders for a little while now, but is it just too late for this device?
I got darklord 3.3 working. Had to make some edits to the buld prop file and copy over the apps conf file but in the end was mostly worth it. Some small camera issues but think it's hardware.
Sent from my SM-N900V using XDA-Developers mobile app
I'm running Aryamod, with VERY few tweaks! It doesn't come with a kernel, so I nabbed the Darkera kernel from the DarkLord ROM page. It comes with Pico GApps preloaded, so it's easy to add to or strip out the Google Apps with TiBU. (I'm running MicroG, with official Play Store apk, myself.)
If you care to give it a try, choose the Sprint version in the Aroma installer and flash your kernel before rebooting. After you've got it running, use the "ROM Control" app to add your APNs (under Phone Mods>Advanced Function Menu>Phone APN Setup) and tweak your smsc number (under Phone Mods>Advanced Function Menu>Device Network Info and Settings>Device Information).
The only downside is that the stock (Samsung) Messages app doesn't send correctly, so I've substituted GoSMS (with the manual APN settings tweaked). Admittedly, it helps to have another phone handy, to test SMS/MMS sending/receiving. I haven't had any of the problems others have had with the "sent message failed", after these tweaks, so I'm certainly impressed. It's good to have some of the neat features the S7 and Note 5 do, WITHOUT sacrificing a stable ROM! ?
Edit: As previously mentioned, not all camera features work (hardware limitations) and NFC isn't working (nobody can, or is willing to, figure out the VZW NFC hardware). However, Bluetooth is working flawlessly, whereas some have had complaints with call audio, in other ROMs.
Sent from my SM-G935F using Tapatalk

Porting modern TouchWiz: Notes from me

Today I wanted to talk about porting current versions of TouchWiz from one device to another. This will be focused primarily on the Sprint network capability since that is my current carrier. But these same basic steps will apply for all porting of TouchWiz.
I know several people have ported roms but I first want to point out one important fact. There is ABSOLUTELY no "guide" that can help you port TouchWiz roms successfully. Period. Any "guide" thread that you may find is completely useless and is isn't even close to touching on the key components of today's porting methods. So don't waste your time reading guides because they are very outdated and irrelevant today.
First things first... When deciding to port a Samsung Rom you need to understand that there are going to be different chipsets for the different device models used in other parts of the world. With this in mind you need to choose software that was originally designed for the same similar cpu whether it be Exynos or Qualcomm. This makes a huge difference when it comes to cpu configs that will best support your device's cpu. If you try to port an Exynos rom to work on a Qualcomm device then expect to have to do a lot more work in framework, etc.
GSM vs CDMA is another very important part of the porting process. When possible, ALWAYS choose software that supports your specific carrier and service type/technology!!! If you are on a GSM network then choose a GSM rom and same for CDMA. However CDMA technology here in the US is a bit different from other countries in regards to how it is setup in the software. Each CDMA carrier will have it's own unique code inside system files. Simply replacing csc and other files will do NOTHING to fix this, leaving you with either no data services or improper generic data services. The only way to do this right is to either start with software for your specific carrier or manually modify these values in multiple files throughout framework and system using the correct values from software specific for your carrier. No exceptions.
The other thing. You ideally want to port the same Android version that is currently available for your specific device because the original kernel and libraries, etc need to support the version of Android in which you want to port. When porting you will be using most of your original software's bin files, kernel, etc... so these files need to be compatible with the version of Android you want to port. Very important!
I will not go into great details with smali modifications, etc because that is a whole different animal. This thread is a general breakdown of what is involved in the whole process. Porting a ROM such as the Note 7 software is no simple task, especially with so many unknown obstacles that must be discovered then remedied. You will need the right tools for the job before you even take on such a task. I'm talking about ApkTool, smali/baksmali, mad genius mentality, etc. Without the proper tools forget about it.
The main things that must be done for the rom to even boot, reside internally inside a few framework jar files. There will also be incompatible system files which must be removed and/or replaced with compatible versions that support your specific device/model. You also may need to make the rom support 32bit such is the case with the Note 4, since it is only 32 bit compatible. There can be no traces of 64bit libraries either inside the system apps or the library folder or else you will have issues. 32 bit devices cannot process 64 bit libraries, whether external or imbedded inside system apps. The one exception to this rule is when an app is multi-arch compatible which means the app can be installed on either 32 or 64 bit devices. In this case the 64 bit libs can remain although they will not be used since the 32 bit libs will be detected by the os. Thankfully 64 bit TouchWiz contains 99.9% of the necessary 32 bit libraries! So use them instead if your device is only compatible with 32 bit architecture.
There are several key Android/Samsung services that are not going to be compatible with other Samsung devices therefore one must identify these incompatible services and other methods in smali and either remove them or recode them in order for the rom to function in a way that is compatible with the device for which you will be running the software on. Sometimes you can simply replace services from your original device's software as long as it is compatible and from the same Android version, but not always.
There is NEVER going to be a set of instructions that will apply to all ROMS. Period. This stuff is always ever-changing with each update that Samsung releases. This is why there can be no accurate "guide" to porting TouchWiz. Whoever says otherwise is not knowledgeable on this stuff at all.
Once the framework files are prepared and rebuilt properly then you will need to have knowledge of the stock system apps and what role they play in the software. Most system apps are cross compatible but some are device and/or carrier specific and must either be removed or replaced in order for the rom to boot and run without a complete meltdown with continuous FC's. Then you have CSC (customer service codes). This plays a major role in how the software will be setup on initial rom setup. Each specific device model will have it's own unique CSC, however most of Samsung's current CSC is identical between the current available top tier devices such as the N4, N5, S7 and N7. BUT each device will have it's own unique "values" within multiple files in CSC. Some Samsung devices are compatible with features that other Samsung devices do not support. Therefore you must have knowledge of this and make the necessary edits in order for the software features to be setup correctly without major malfunctions. One wrong value can actually cause the rom to not boot. You will need experience with this as well.
Next you may need to slightly modify the kernel's ramdisk to support a couple of additional framework files which is the case with the N7 software and probably the N5 as well. It's just a matter of adding a few file names to a text file, save, then recompile the zimage and place the modified kernel inside your rom zip. These types of things must be discovered by trial & error by people who are knowledgeable and have experience porting roms. But it goes to show that these little things can determine a successful or failed port. You never know what can cause the rom to not boot. There's so many pieces to the puzzle when porting.
Moving on to the build.prop and updater-script. There MUST be a lot of edits done to the build.prop and the same principal applies here. You MUST edit the build.prop in order for it to support the software AND your specific device model, cpu, security features, etc, etc. This is an art folks. Again... there is no "guide" for doing this properly. You must possess the mental aptitude to tackle this stuff. It's not for normal people The updater-script is a VERY VERY important part of the rom porting process because it contains the permissions and symbolic links for all of the critical system files and folders. You must manually edit the updater-script so that it sets the proper permissions and symbolic links for the files that are used in the current software you are going to run. You cannot simply use a stock device updater-script straight out of the kitchen for your specific device. It will not work due to other versions of TouchWiz will likely have additional or different files and folders in the rom. This will take a LOT of time to go over everything and make sure you covered everything and properly setup the updater-script.
Next there is the process of replacing critical and device specific libraries and bin files as well as kernel modules. Generally for Samsung devices, system/bin folder must contain all of the original files from the original stock software for your specific device. You might need to add additional files from the software you are porting. The same applies to the system/lib/modules. These modules MUST come from your device's original software. The libraries are very tricky because not all libraries can be from either your original stock software nor from the software you are porting. Simply put, this is going to be the single most time consuming process with a ton of trial and error. You must figure out which lib files must be used from your original software and which libs must come from the new ported software. Good luck figuring this out! :laugh:
This pretty much covers the initial areas of the system software that must be manually modified in order for the rom to actually boot.
As you can see, there's a lot of trial and error with porting roms. Believe me. Other people who ported the early N7 and S7 port ROMs have done a LOT of work and surely they have a lot of trial and error. These early port dev's deserve a lot of credit for these early discoveries without a doubt. Without their original trials and errors & hard work, there would be no other port roms. They shared their knowledge and it was a group effort in the beginning. You guys know who you are! :highfive: Much Thanks to all of you who figured out framework issues etc in the early stages of current TouchWiz. I learned a lot in this process in which I have never shared with the public simply because there's no point in giving information that others can't use due to lack of experience. Hopefully some people will read this and better understand what goes into porting these ROMs. At a later dat, I may write up a more detailed "guide" on current TouchWiz IF I feel there is a need and there is enough people willing to step up and help out the community in the future. This is the way XDA works. You have to pass the torch to win the race. No one person can conquer the world. Teamwork is the key to success in everything you do. Remember this. Thanks for reading.
Wow, very nice write up. Thanks!
I would be interested in a more detailed guide if and when you get to it. I'm always looking to expand my know - how.
Many thanks! :highfive:
Thanks for the post....
but you did not go in to ROM porting much at all... I'd love to read a in depth view of the " copy and paste " dev .
tx_dbs_tx said:
This will be focused primarily on the Sprint network capability since that is my current carrier. But these same basic steps will apply for all porting of TouchWiz.
GSM vs CDMA is another very important part of the porting process. When possible, ALWAYS choose software that supports your specific carrier and service type/technology!!! If you are on a GSM network then choose a GSM rom and same for CDMA. However CDMA technology here in the US is a bit different from other countries in regards to how it is setup in the software. Each CDMA carrier will have it's own unique code inside system files. Simply replacing csc and other files will do NOTHING to fix this, leaving you with either no data services or improper generic data services. The only way to do this right is to either start with software for your specific carrier or manually modify these values in multiple files throughout framework and system using the correct values from software specific for your carrier. No exceptions.
The other thing. You ideally want to port the same Android version that is currently available for your specific device because the original kernel and libraries, etc need to support the version of Android in which you want to port. When porting you will be using most of your original software's bin files, kernel, etc... so these files need to be compatible with the version of Android you want to port. Very important!
Click to expand...
Click to collapse
This was great. It was exactly what I was looking for. Ive being working on porting a gsm rom to my device N900P. But the only thing Ive found is copy and paste. Trying to find something on cdma is even harder. Ive just download your Ultimate Hybrid N7 to see if can get a clue on where to start. Deodexing telephony-common should be enough? Where else should start looking? If you could point me a direction would be great. Thanks
triskaw said:
This was great. It was exactly what I was looking for. Ive being working on porting a gsm rom to my device N900P. But the only thing Ive found is copy and paste. Trying to find something on cdma is even harder. Ive just download your Ultimate Hybrid N7 to see if can get a clue on where to start. Deodexing telephony-common should be enough? Where else should start looking? If you could point me a direction would be great. Thanks
Click to expand...
Click to collapse
Sorry for the late reply. To be honest, porting a gsm rom to work on a U.S. cdma carrier is going to require massive work. Forget about it. Start your rom project with cdma compatible software and save yourself the trouble. You'll win the lottery before you get a gsm rom ported over to cdma. Copy and paste isn't going to scratch the surface. Why not port a factory Sprint ROM for your Sprint note 3? Such as the Sprint N7, N5, S7 edge? It is already setup to work on the sprint network. It would save you a lot of time and effort.

Categories

Resources