[Galaxy Note II, Galaxy S III Developer Discussion ] TrevE:
Lets talk a bit about Carrier support and roms. As far as I know, this is one of the first times multicarrier has been done on such a scale. This is probably due to Samsung really stepping up and having the same hardware on different networks :good: But it has created a few problems/hackjob solutions that I cringe every time I come upon them. Most devs are in the know now, not to single anyone out at all but many VZW roms have been fixed or are being fixed, The Peoples Rom has full Sprint -> VZW support, Hero seems to have fixed some port issues last release, scrosler has been pointing users in the right direction, and of course Synergy is patched also. There are probably more patched as well and I do not want to leave anyone out, I just am not in the know about the whole suite of Roms. This rant is more so when we see silly things posted we can squash them before they keep spreading.

I am posted this in the dev only section because I do not want to get 1000 questions "what about this on this rom" and am just looking for this to be an open discussion & knowledgebase about not pissing off the powers that be. This also applies to both note2 and gs3 as both are going multicarrier so it seemed perfect. I will also be posting no links here to where any incorrect information started from. This is not a finger pointing contest its just meant to not hoard information and hopefully help the community grow as a whole.

If you are not a dev, just sit back and take it in. If you are a user looking for a way to test out roms, please check out the tool I posted in development - http://xdaforums.com/showthread.php?t=2234003

If you are a dev, feel free to chime in and throw other ideas in as well. There are some ports we are still struggling on, and some carriers that are still neglected from this list. More info that is out there the better :good:

Here are some details on the back end of how things work, and what we need to be careful of when moving a rom between networks

1- CSCs - Consumer Software Customization - Sets Sales Code & Other Values

This article has some more information about cscs - http://droidviews.com/2012/how-to-change-csc-in-samsung-galaxy-phones/

In a nutshell, when a device comes from the factory it is totally blank with just a stock image flashed. At the point device is first turned on SetupWizard kicks to life and the software goes through activation and CSC Verify steps. What CSC Verify does is checks System files to make sure they are not modified and applies Carrier specific settings. This is where your bookmarks, preset dialer numbers, phone default MCCs, programming info like phone information, APNs, and PRLs get set in the rom. Unless you heavily modify the ROM you will be failing a CSC verify check. This appears to be reported in the form of a RIL request if the carrier wants it with a list of files in system different than what the stock image should have.

To check CSCs (only run after a factory reset)

am start com.sec.android.app.servicemodeapp/.Sec_Ril_Dump

and check CSC compare.

Regardless of a pass or fail there, CSCs have other functions to apply different properties to the rom. Sales Code and Country Code are two big parts of CSCs. These are how networks features are applied (Sprint gets its Connection Optimizer, PRL menus, etc), how APNs get matched to MCCs to validate use(ATT matches its APNs this way), among other things such as Data Roaming. Sales code is actually written down to the EFS under certain conditions and I believe where the IMEI loss is coming from. It seems to be a case where if the Sales Code changes and verify detects some change to run a nvrecovery. I still have not been able to reproduce it 100%, but the condition should able to be found with alittle bit of work close to those lines.

With this being said, the important things to make sure of for CSCs and network compatibility are below. Seriously dont just go deleting these XMLs to get something like lockscreen bubbles. Do the mod the right way or dont do it at all. Do you really want LOL's or some bogus values written to EFS or reported in a RIL query? (sorry for overly dramatic rant, this one just pisses me off. Look down to point2 for even more on why)

-/system/csc/customer.xml

-/system/csc/sales_code.dat

-/Build.prop values. If these do not exist they will fall back to sales_code.dat/customer.xml. Below is a sprint example

ro.csc.sales_code=SPR
ril.sales_code=SPR
ro.csc.countryiso_code=US

1a - Other Important build.prop values

This is half CSC related, half Network Specific app related, so well make it 1a. Things like model number, ro.build.PDA, chipset and build.product determine what features are enabled on the device and other aspects of registration. Below are important prop values us at Synergy have determined to have set right, the below is a sprint example but regardless of what network you go to, you should have always have these same props just change with values from the build.prop of your device/network combo.

ro.build.version.incremental=L710VPBLJ7
ro.product.model=SPH-L710
ro.product.brand=samsung
ro.product.name=d2spr
ro.product.device=d2spr
ro.product.board=MSM8960
ro.chipname=MSM8960
ro.board.platform=msm8960

# ro.build.product is obsolete; use ro.product.device
ro.build.product=d2spr

# Do not try to parse ro.build.description or .fingerprint
ro.build.description=d2spr-user 4.1.1 JRO03L L710VPBLJ7 release-keys
ro.build.fingerprint=samsung/d2spr/d2spr:4.1.1/JRO03L/L710VPBLJ7:user/release-keys
ro.build.characteristics=sprint
ro.com.google.clientidbase.yt=android-sprint-us
ro.com.google.clientidbase.ms=android-sprint-us
ro.com.google.clientidbase.am=android-sprint-us

# Samsung Specific Properties
ro.build.PDA=L710VPBLJ7
ro.build.hidden_ver=L710VPBLJ7
ro.build.changelist=329968
# end build properties

# 8960 RIL Basic
ro.vendor.extension_library=/system/lib/libqc-opt.so
rild.libpath=/system/lib/libril-qc-qmi-1.so
rild.libargs=-d /dev/smd0
persist.rild.nitz_plmn=
persist.rild.nitz_long_ons_0=
persist.rild.nitz_long_ons_1=
persist.rild.nitz_long_ons_2=
persist.rild.nitz_long_ons_3=
persist.rild.nitz_short_ons_0=
persist.rild.nitz_short_ons_1=
persist.rild.nitz_short_ons_2=
persist.rild.nitz_short_ons_3=
ril.subscription.types=NV,RUIM
DEVICE_PROVISIONED=1

# Snapshot Setting
persist.radio.snapshot_enabled=1
persist.radio.snapshot_timer=22

# Default ECCList (Except USCC)
ro.ril.ecclist=112,911,#911,*911

# Default Operator (SPR)
ro.cdma.home.operator.numeric=310120
ro.cdma.home.operator.alpha=Sprint

# Do not show no sim notification
ro.config.donot_nosim=true

1b- What Apps Use these Values - AKA Why you should care

This section gives a brief idea of what the impact is of say deleting customer.xml or changing sales code props to the wrong network. Some may be a simple display of the value, others may totally changing the way network functions work, but theres ~50 apks in the list, alot to be messing with and not a good idea.

*NOTE* APKS like CSC/keystring/preloadinstaller/secsettings.apk control other system and network functionality outside of the APK.

*NOTE2* There are probably other places these are checked as well, this is just a quick and dirty list to get the point across these are important

Customer.xml: (means it uses file directly. Salescode list might overlap with this, but they are slightly different checks)

/system/app/CSC.apk

/system/app/ClockPackage.apk

/system/app/SamsungCamera.apk

/system/app/SamsungIME.apk

/system/app/SecBrowser_VZW.apk

/system/app/SecContacts.apk

/system/app/SecEmail.apk

/system/app/SecMms.apk

/system/app/SecPhone.apk

/system/app/SecWallpaperChooser.apk

/system/app/VoiceRecorder.apk

/system/framework/services.jar

Sales Code - (from customer.xml, props, or sales_code.dat, depends on what takes priority)

Framework:

/system/framework/android.policy.jar

/system/framework/framework2.jar

/system/framework/services.jar

ATT:

/system/app/OmaCP.apk

Sprint:

/system/app/Chameleon.apk

/system/app/PCWClientS.apk

Common:

/system/app/AccuweatherDaemon.apk

/system/app/AccuweatherWidget_Main.apk

/system/app/AllSharePlay.apk

/system/app/CSC.apk

/system/app/ClockPackage.apk

/system/app/CloudAgent.apk

/system/app/FactoryTest.apk

/system/app/HiddenMenu.apk

/system/app/Keystring_factory.apk

/system/app/Keystring_misc.apk

/system/app/KiesAir.apk

/system/app/MediaHub_D2.apk

/system/app/MusicPlayer.apk

/system/app/MyFiles.apk

/system/app/PCWClientS.apk

/system/app/PhoneErrService.apk

/system/app/PolarisOffice4.apk

/system/app/Preconfig.apk

/system/app/PreloadInstaller.apk

/system/app/SMemo.apk

/system/app/SMemoProvider.apk

/system/app/SSuggest.apk

/system/app/SamsungCamera.apk

/system/app/Samsungservice.apk

/system/app/SecCalendar_NAmerica.apk

/system/app/SecContacts.apk

/system/app/SecContactsProvider.apk

/system/app/SecEmail.apk

/system/app/SecExchange.apk

/system/app/SecGallery2.apk

/system/app/SecMms.apk

/system/app/SecPhone.apk

/system/app/SecSettings.apk

/system/app/SecSettingsProvider.apk

/system/app/SecSetupWizard.apk

/system/app/systemUI.apk

/system/app/Tag.apk

/system/app/VideoPlayer.apk

/system/app/YahoonewsDaemon.apk

/system/app/YahoonewsWidget.apk

/system/app/serviceModeApp.apk

/system/app/voicetalk.apk

Props

build.PDA:

VZW:

/system/app/SyncMLSvc.apk

SPR:

/system/app/SprintSyncMLSvc.apk

ATT:

/system/app/wssyncmlds.apk

/system/app/wssyncmldm.apk

COMMON:

/system/app/serviceModeApp.apk

/system/app/SecMms.apk

/system/app/BCService.apk

/system/app/SecBrowser_VZW.apk

/system/app/Samsungservice.apk

/system/app/CSC.apk

/system/app/Keystring_factory.apk

ro.product.device -

/system/app/FactoryTest.apk

/system/app/Keystring_factory.apk

/system/app/Keystring_misc.apk

/system/app/Lcdtest.apk

/system/app/SecEmail.apk

/system/app/SecExchange.apk

/system/framework/com.google.android.maps.jar

/system/framework/framework.jar

/system/framework/services.jar

2- Network Specific Apps

This builds a bit more to point 1/1a, making sure CSCs & props are set correctly. Some, not all apps switch functionality based off salescode as seen above. Then there is another category of apps that should switch but are somewhat broken. These are any that contain checks containing compile time inserts of network name into the code itself instead of reading from a prop value. Many of these are for base functionality, and stuff you really shouldn't be living without.

How can devs tell what switches and what doesn't? Below is a badly hardcoded "cross network" check. This example will always be false even where it is suppose to run because obviously the string SPR will never equal VZW. This is likely sprint specific code, as on Sprint the hardcoded value would come out if SPR==SPR resulting in a hardcoded true making this code always run on networks its not suppose to.

if(mUiccController.getUiccCardApplication(1) != null)
{
if("SPR".equals("VZW"))

This is an example of a proper salescode check looks like that will work on any network, notice it checks from string s for salescode prop instead of a hardcoded value:

s = SystemProperties.get("ro.csc.sales_code");
if(!"SPR".equals(s) && !"BST".equals(s))

Below is the list of apps us at Synergy have compiled of important apks. Most apps like SecSettings will switch around properly so do not need to be "carrier specific" so are not contained in this list. The ones actually contained in the list all have some use for proper network functionality/back end functions to work right. This list also contains some apks that should be considered "dangerous" and need to be removed from ports to other network such as using Sprints OMADM activation client elsewhere.

ATT:

[b]Apps:[/b]
LTESetting.apk
LTETest.apk
MoreServices.apk
OmaCP.apk
SecContacts.apk
SecPhone.apk
WISPr_Android22_postpaid_ATT.apk
wssyncmldm.apk
wssyncmlds.apk

[b]libs:[/b]
libAMSWiFiLibsR2.so
libChatOnAMSImageFilterLibs.so
libdprw.so
libjni_emailencryption.so
libomacp.so
libreference-ril.so
libril-qc-qmi-1.so
libril-qcril-hook-oem.so
libril.so
libsecril-client.so
libSpeexEncoderJNI_1.0.0.8.so

Sprint:

[b]Apps:[/b]
Activation.apk
ConnectionManager.apk
LTETest.apk
MIPErrService.apk
OmaCP.apk
PCWClientS.apk
PhoneInfo.apk
SecContacts.apk
SecPhone.apk
SlateTest.apk
SprintAndroidExtension.apk
SprintDM.apk
SprintSyncMLSvc.apk
SprintZone.apk
Sprint_Installer.apk
vtt-sprint.apk

[b]Libs:[/b]
libAMSWiFiLibsR2.so
libChatOnAMSImageFilterLibs.so
libomacp.so
libreference-ril.so
libril-qc-qmi-1.so
libril-qcril-hook-oem.so
libril.so
libsecril-client.so
libsyncml_core_sprint.so
libsyncml_sprint.so

Verizon

[b]Apps:[/b]
appdirectedsmspermission.apk
ba-syncservice-app-signed.apk
LTESetting.apk
LTETest.apk
NewBayService.apk
qospermission.apk
securesettingspermission.apk
SPG.apk
SyncMLSvc.apk
vmmhux.apk
VZWAPNLib.apk
vzwapnpermission.apk
VZWAPNService.apk
VzwSilentSSOEngine.apk

[b]Libs[/b]
libreference-ril.so
libril-qc-qmi-1.so
libril-qcril-hook-oem.so
libril.so
libsecril-client.so

3- Network Specific Framework

While there are minor exceptions, ATT/TMO/VZW generally register handsets on the network the same way. Sprint is way off in left field on how telephony registration works. They have their own APIs in framework2.jar, and framework.jar handles most of the telephony part for registration. If you want to port to or from Sprint, you need to make sure the device can register properly. Hardcoding your phone number inside of a APN is not proper registration and is giving the illusion of things working when other major things are failing on the backend. Hence this "fix" should not be used unless you really know what you are doing.

Signs of Improper network registration:

-Unknown Phone number in About Phone

-MMS fails

-Issues with Data Roaming

Proper Way to port:

Merge in framework.jar/com/android/internal/telephony and framework2.jar/com/android/internal/telephony.

Going TO sprint, framework/framework2.jar needs the added Sprint apis

I explained more on what each of the files do over in heros thread here: http://xdaforums.com/showpost.php?p=39896841&postcount=6877

So that ends my 2cent rant. Networks always have a way to know your rooted between CSCs+Sysscope and whatever else they have hidden in the radios. Its a fact of life now, get use to it. Right now no carriers really seems to be caring though so lets keep it that way. If we start to abuse that privilege and cause networks issues there might come the day where enough is enough and thousands of root users cry out in terror and are suddenly silenced. On the flip-side though, If we show carriers were trying to respect their networks and just want to do cool stuff with our devices hopefully they will let us just continue on with what were doing. Who knows, maybe they will read this and make all the apks switch proper based on salescode so we dont have the issues at all in future, but for now lets be careful.

So let 'er rip devs. Fire away questions, lets all get stuff working right and try to put to rest all these silly hacks that are causing more problems than they are worth.