Recently I made a longwinded rant over in dev only about the importance of rom props being set to carriers correctly. This thread is to split off the actual tool itself to check from the dev only questions.
Attached to this post is an Aroma Flashable to check basic network compatibility. It also will list out hardware information such as CPU Models and if NVBackups have been ran. Not everything for network compatibility can be checked such as framework, but if you follow these steps users should have a pretty good way to check network friendliness. Devs please make sure we start paying attention to this. I will explain the basics of each check here, but if you want more geeky information on why these are important read my rant in the devs only forum here - http://forum.xda-developers.com/showthread.php?t=2231256 .Devs only - feel free to hit me up there with any porting questions, or expand on this script to make it more robust.
To test a ROM
Flash a rom you want to check
Before booting into rom, flash attached network check
Verify Settings, reboot when done
When first boot in rom, go to settings -> about phone and verify phone number, verify MMS works.
If you do all these steps, you have a fairly good way to see compatibility. Use common sense as well.
Currently Working Network Checks
ATT/SPR/VZW
*note* this is the first version with "intelligence", so some checks may not be as smart as I think they are. I believe we have coded it correctly for every scenario and have tested many stock roms, but this should just be used as a *basic* check. It is not all encompassing because we cannot check things like framework, and as such should be used as a general reference.
Explanation of Checks
**All of these screenshots are using a Verizon Device as a base. Obviously if you are using Sprint or ATT checks will look slightly different**
Page 1 - Hardware Versions
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Hardware Versions-
androidboot.nvdata_backup - 1 if "reboot nvbackup" has been ran, 0 otherwise
androidboot.bootloader - Bootloader version flashed
samsung.hardware - Hardware version ID
CPU Revision - CPU model revision
Hardware - Vendor specific Hardware type of device
Unique CPU Serial - CPU serial #. Unique to device, would not be posting around
Recovery Info-
Checks what carrier recovery props have set
Page 2 - Software Prop Checks
CSC Version Info-
build.PDA - read from build.prop. PDA/CSCs/Baseband should all be matching
CSC Software Ver - read from /system/CSCVersion.txt
These are manual checks because querying baseband isnt possible in recovery
Sales Code Props-
Ril Sales Code - checks build.prop for ril.sales_code and matches to hardware
CSC Sales Prop - checks build.prop for ro.csc.sales_code and matches to hardware
This will display a --CHECK in bold if a value is incorrect. Blank values here are OK if below Sales Code CSCs are set correctly. If a value is set here it will overwrite Sales Code CSC.
Sales Code CSCs-
Device Sales Code - reads from /system/csc/sales_code.dat. Checks to hardware
Customer XML Sales Code - reads from /system/csc/customer.xml. Checks to hardware
This will display an error message in bold at the bottom of the check if one or more is off
Rom Prop Info-
product name - checks build.prop for ro.product.name and matches to hardware
product model - checks build.prop for ro.product.model
version - checks build.prop for ro.build.version.incremental. Usually matches build.PDA
characteristics - checks build.prop for ro.build.characteristics.
Google Keys-
build.description - checks build.prop for ro.build.description
build.fingerprint - checks build.prop for ro.build.fingerprint
clientid.yt - checks build.prop for ro.com.google.clientidbase.yt
clientid.ms - checks build.prop for ro.com.google.clientidbase.ms
clientid.am - checks build.prop for ro.com.google.clientidbase.am
Page 3 - Apps Check
This screen checks for the existence of ATT / Sprint / Verizon apps in a rom. A success should be only say Verizon apps on a Verizon device. Anything else is considered a failure.
Changelog
V1.4 -
Beefed up a few checks
Added help/about screen to beginning of aroma
Added dev only option - Lets devs fake a hardware ID to test how different ports will check out
Added more hardware type info. Totally useless to porting but cool stuff to know
Added logging option to end of aroma, ability to save all output to /sdcard/romcheck.txt. File has unix linebreaks so use notepad++ if on windows.
V1.3 -
Initial release in development section.
Remember this is the first version of this test script, so every case may not have been thought of. It is also only a basic scanner tool and should not be the only test you do, use common sense as well. Devs feel free to work off of this, give codechanges, report in on bugs, whatever.
TL;DNR version for non-devs: Go back and this time don’t TL;DNR the post above
Run this tool AFTER you’ve flashed any US S3 ROM and read through each result carefully. For example, if you are, say, an AT&T user, EVERYTHING should come back with the appropriate d2att info (i.e. build.prop stuff should all say only att, CSCs should all say att, there should ONLY be att apps on the last page, etc). If everything did not come back 100% att, you failed the test and the ROM you just flashed is installing incorrect files to your phone.
We need everyone – devs and users alike – to be diligent in the use of this tool. As we explained in this thread, if multicarrier isn’t being done properly and users are running ATT or SPR code on the VZW network (or any other combination) then the carriers may start getting really upset with the XDA community – which is something we really need to avoid.
Tool has been updated to v1.4 with some requested features (dumping to text file, ability to test different hw, more hardware related stats, etc). Also have updated the dev only section thread with more info on why these checks matter and some cleanup.
Enjoy
TrevE said:
Recently I made a longwinded rant over in dev only about the importance of rom props being set to carriers correctly. This thread is to split off the actual tool itself to check from the dev only questions.
Attached to this post is an Aroma Flashable to check basic network compatibility. It also will list out hardware information such as CPU Models and if NVBackups have been ran. Not everything for network compatibility can be checked such as framework, but if you follow these steps users should have a pretty good way to check network friendliness. Devs please make sure we start paying attention to this. I will explain the basics of each check here, but if you want more geeky information on why these are important read my rant in the devs only forum here - http://forum.xda-developers.com/showthread.php?t=2231256 .Devs only - feel free to hit me up there with any porting questions, or expand on this script to make it more robust.
To test a ROM
Flash a rom you want to check
Before booting into rom, flash attached network check
Verify Settings, reboot when done
When first boot in rom, go to settings -> about phone and verify phone number, verify MMS works.
If you do all these steps, you have a fairly good way to see compatibility. Use common sense as well.
Currently Working Network Checks
ATT/SPR/VZW
*note* this is the first version with "intelligence", so some checks may not be as smart as I think they are. I believe we have coded it correctly for every scenario and have tested many stock roms, but this should just be used as a *basic* check. It is not all encompassing because we cannot check things like framework, and as such should be used as a general reference.
Explanation of Checks
**All of these screenshots are using a Verizon Device as a base. Obviously if you are using Sprint or ATT checks will look slightly different**
Page 1 - Hardware Versions
Hardware Versions-
androidboot.nvdata_backup - 1 if "reboot nvbackup" has been ran, 0 otherwise
androidboot.bootloader - Bootloader version flashed
samsung.hardware - Hardware version ID
CPU Revision - CPU model revision
Hardware - Vendor specific Hardware type of device
Unique CPU Serial - CPU serial #. Unique to device, would not be posting around
Recovery Info-
Checks what carrier recovery props have set
Page 2 - Software Prop Checks
CSC Version Info-
build.PDA - read from build.prop. PDA/CSCs/Baseband should all be matching
CSC Software Ver - read from /system/CSCVersion.txt
These are manual checks because querying baseband isnt possible in recovery
Sales Code Props-
Ril Sales Code - checks build.prop for ril.sales_code and matches to hardware
CSC Sales Prop - checks build.prop for ro.csc.sales_code and matches to hardware
This will display a --CHECK in bold if a value is incorrect. Blank values here are OK if below Sales Code CSCs are set correctly. If a value is set here it will overwrite Sales Code CSC.
Sales Code CSCs-
Device Sales Code - reads from /system/csc/sales_code.dat. Checks to hardware
Customer XML Sales Code - reads from /system/csc/customer.xml. Checks to hardware
This will display an error message in bold at the bottom of the check if one or more is off
Rom Prop Info-
product name - checks build.prop for ro.product.name and matches to hardware
product model - checks build.prop for ro.product.model
version - checks build.prop for ro.build.version.incremental. Usually matches build.PDA
characteristics - checks build.prop for ro.build.characteristics.
Google Keys-
build.description - checks build.prop for ro.build.description
build.fingerprint - checks build.prop for ro.build.fingerprint
clientid.yt - checks build.prop for ro.com.google.clientidbase.yt
clientid.ms - checks build.prop for ro.com.google.clientidbase.ms
clientid.am - checks build.prop for ro.com.google.clientidbase.am
Page 3 - Apps Check
This screen checks for the existence of ATT / Sprint / Verizon apps in a rom. A success should be only say Verizon apps on a Verizon device. Anything else is considered a failure.
Changelog
V1.4 -
Beefed up a few checks
Added help/about screen to beginning of aroma
Added dev only option - Lets devs fake a hardware ID to test how different ports will check out
Added more hardware type info. Totally useless to porting but cool stuff to know
Added logging option to end of aroma, ability to save all output to /sdcard/romcheck.txt. File has unix linebreaks so use notepad++ if on windows.
V1.3 -
Initial release in development section.
Remember this is the first version of this test script, so every case may not have been thought of. It is also only a basic scanner tool and should not be the only test you do, use common sense as well. Devs feel free to work off of this, give codechanges, report in on bugs, whatever.
Click to expand...
Click to collapse
TrevE,
I see you still doing what you do best analyzing bro. I am glad people like you are still around deving with the dream team of developers on board with you. thanks will be note 2 AT&T chomping this up across the platform...
So I have a question then. I know this is the Verizon forum, but I'm going to talk about att, because it's in the description. I've also thought about going to att when/if Verizon decides to nix unlimited data. I talked to someone at att and they said I can get ANY CARRIER UNLOCKED GSM phone, international included, and use it on att. So how does that work with this tool, since it's only on att by sim?
riassan said:
TrevE,
I see you still doing what you do best analyzing bro. I am glad people like you are still around deving with the dream team of developers on board with you. thanks will be note 2 AT&T chomping this up across the platform...
Click to expand...
Click to collapse
Good to see ya around here bud been awhile note2 should be cool with some minor changes, hell I can run it on my e3d and even though it cuts screens off the basics work wherever.
countryfolk07 said:
So I have a question then. I know this is the Verizon forum, but I'm going to talk about att, because it's in the description. I've also thought about going to att when/if Verizon decides to nix unlimited data. I talked to someone at att and they said I can get ANY CARRIER UNLOCKED GSM phone, international included, and use it on att. So how does that work with this tool, since it's only on att by sim?
Click to expand...
Click to collapse
Good question - As of now were still creating a database of all the hardware versions of the device. Till now it was a bit hard for the average user to get this data.
During our trials though Esc had some testers dump info- from what weve seen so far Tmobile devices are reporting in with ATT Hardware. This is why I only have these 3 carriers supported as of now. I'm not 100% positive if /proc/cpuinfo is controlled by kernel in some way, but the only strings I've seen so far are
SAMSUNG M2_ATT
SAMSUNG M2_SPR
SAMSUNG M2_VZW
These may actually be the only 3 main board versions of the US hardware, meaning any device that reports as a M2_ATT would be able to be unlocked for use between ATT/TMO or any other network that runs a device with that hardware ID. Not 100% sure, but if we get some users posting what their CPU Hardware reads out as from other networks you can get a good idea of what type of devices there are out there working on what network.
*Edit* i guess what im trying to say, even if these are the only 3 revisions and you got a Tmobile device, it would detect it as ATT still and show you the right files to change to get a compatible rom with ATT. If its true, adding support to the apps autodetection for other carriers like tmobile is going to be a bit harder.
International GS3 is totally different hardware, exynos vs msm. The international roms usually have many carrier support built into them and do proper switching on sales code. Aslong as the ROM has ATT support in the CSC folders it means the software was written to have support and switch properly to the ATT network if your sales code is set correctly, but im not positive they do.
*Edit2* Just looked at XXELLA international gs3 firmware, it has support for these carriers. It very well may still work with another carriers sales code, but it wouldnt be recommended
Code:
ABS
AFG
AFR
ALB
ARB
ATL
BGL
BRI
BTC
BTU
CEL
CHU
CMF
CNX
COA
CPW
CYO
CYV
DBT
ECT
EGY
EIR
ERO
ETL
ETR
EUR
FWD
GLB
H3G
ILO
INS
INU
ITV
JED
KEN
KOR
KSA
LUX
LYS
MAT
MED
MET
MID
MIR
MM1
MMC
MOB
MRT
MSR
MTL
MWD
NEE
NPL
OMN
OPS
ORL
ORS
ORX
PAK
PCL
PHE
PRO
PTR
QAT
SEB
SEE
SFR
SIM
SIN
SLK
SMA
STH
SWC
TCL
TDR
TGY
THL
THR
TMC
TML
TMT
TOP
TRA
TSR
TTT
TUN
TUR
TWO
VD2
VDC
VDF
VDH
VDI
VDP
VDR
VDS
VGR
VIM
VIP
VNO
VOD
VOP
VVT
WAN
XEF
XEH
XEO
XEV
XEZ
XFA
XFC
XFE
XFM
XFV
XME
XSE
XSG
XSK
XSP
XTC
XTE
XXV
ZTO
Hi guys,
After some answers for the following.
In Xperifirm, What does the CDA Numbers represent? I.E Australian firmware 1308-6997 vs Ireland 1309-2380.
Also what does the last numbers represent on the firmware. ie. 47.1.A.16.20 R3C vs R4B etc
tried googling it and didn't get any definitive answers.
If its been answered already, i apologize in advance!!
Cheers
Anyone? No one knows?
The CDA numbers are batch specific builds that are made up for different service providers. Each service provider will want certain applications included, some of them made system, that are not stock. Even the 'customised' builds are differtrent, some include fingerprint sensor, some allow voice recording, some allow 2g only depending on the region they are to be deployed.
Picking a higher number won't get you more bells and whistles.
The suffix on the end of the firmware relates to Release Candidate (RC) or Release Batch, this is effectively the build number and the higher the number the later and possibly more complete the build.
Ahh mate thanks for that!
trying to see what firmware is similar to AU firmware in the G8142 category, so i can have VoLTE and VoWIFI. Looks like I'll just have to flash a G8142 with OEM.SIN file from the AU firmware.
Hi all!
I have decided to buy the ZenFone 6 and found out that it is completely out of stock here in Moscow, Russia, and nobody knows the delivery date. Hopefully the eBay and other platforms come to the rescue.
I also found out that there exist at least 3 hardware versions of the phone: "A", "B" and "C". Each version supports different LTE bands.
Are all firmwares interchangeable between these three hardware versions or not? Will I be able to flash the version I pick from the asus.com website and root any hardware version of the phone?
I have doubts because some firmware versions (go to https://www.asus.com/Phone/ZenFone-6-ZS630KL/HelpDesk_BIOS and press "Show all") have comments like : "for WW/IN/EU/RU/JP only*"; "WW/EU/RU/JP only* exclude IN" or "IN/WW/TW only* exclude RU/EU" and the asterisk points nowhere.
I don't want to get the phone and find out that it does not support VoLTE just because I cannot flash the proper firmware or even worse - I can't root my device.
Thank you!
Hello everyone,
I tried to activate my GW5 (LTE US Version) on Canadian Bell network by scanning the Bell's "generic" QR Code, and it was successful (getting the QR Code option by tapping 5 times on "Galaxy Wearable" in its "About" section of the app).
However, I just got a new number which I wanted to transfer the service and I had to re-do the activation, but this time it keeps saying "the code is not valid anymore, or it's been used" which is technically true because I already used that generic QR code once to activate before. The problem is that Canadian Bell Mobility doesn't generate unique QR Code vouchers (i.e. getting a new QR Code is not possible as they only have one general code which should be used for every scenario). Is there any way to bypass this and reuse the code via the Wearable app?! Anyone encountered a similar issue?
Any help is greatly appreciated!
To see Bell's generic code:
https://support.bell.ca/mobility/sm...internet/what_is_dual_sim_and_how_do_i_use_it
How to Enable All Bands Through Service Menu on US/CA S22 series (including Sub-6 and mmWave)
What is this? This is a guide on how to enable all LTE and 5G bands on the US or Canadian S22 series phones by going through the service menu. This guide is mostly based on this S20U guide by mellojosh, but has been adapted for the S22U phone...
forum.xda-developers.com
Only as info...
NO idea if on GW4 and/or GW5 something similar exists... because Android 11 and kastriert...
Best Regards
Hello I'm from Brazil. I recently acquired a Galaxy note 20 Ultra (SM-N986U1), American version CSC “XAA/XAA, TMB/VZW” because it has the “snapdragon” processor because here in Brazil they were only available with “exynos” and csc “ZTO” processors. It is fully updated (Android 13, May 1, 2023) that is, it does not have many means of exploiting exploits to be able to edit the cscfeature.xml. I don't want to root because besides being dangerous I just want to enable the call recorder and the native SPAM identifier. It's sad to have to use gambiarras to record that don't even work and to see much inferior devices in Brazil with the native function.
Does anyone have a way to insert the call recorder and Spam identifier lines into “optics/configs/carriers/wwd/conf/cscfeature.xml” which by the way is read-only?
I already copied and decrypted all the 'cscfeature.xml' from the folders in "optics/configs/carriers/" on my computer looking for some CSC that has these functions but unfortunately none of them do.
As I explained, I don't want to root and run the risk of bricking the device, just release these functions, the ideal would be a rom with the ZTO folder for this version.