Hi,
Looking for a ROM patch to have better carrier capability with carrier Telstra Australia telco so advanced 4G capabilities can be used on this network.
Goals are...
- VoLTE Compatibility
- VoWifi Enablement
- High Speed 4GX services
Let me know what you need. I can test on a 5T. Friends can test on a 6.
Unlikely unless Telstra supports it directly (which they don't)… So don't get your hopes up!
Found this thread created recently on another website. I thought you guys might be interested in reading the content.
Github page: https://github.com/julKali/nokia8-evenwell
Here are some of the most interesting comments:
mattlondon 2 days ago [-]
So I have spent some initial time looking at this.
com.evenwell.autoregistration.Caivs has some worrying looking stuff.
There is a website here with the username and password in cleartext in the jars: https://www.c2dms.com Nothing visible/doable once logged in from what I could see.
It also appears to be collecting fine-grained location data, e.g. this is the output from logcat (I have obfuscated my own GPS coords here, but they are 6 digits of accuracy)
Code:
2019-03-30 19:38:21.406 15139-15159/? D/[CAIVS] LocationFinder: LocationUpdated: 3.location:Location[gps 51.xxxxxx,-0.xxxxxx hAcc=39 et=+1d19h59m28s923ms alt=102.50201416015625 vel=3.09 bear=14.3 vAcc=24 sAcc=3 bAcc=10 {Bundle[mParcelledData.dataSize=96]}]
2019-03-30 19:38:21.406 15139-15159/? D/[CAIVS] LocationFinder: updateLocation: gps accuracy:38.592003
2019-03-30 19:38:21.406 15139-15159/? D/[CAIVS] LocationFinder: updateLocation: is in accuracy :1000
com.evenwell.autoregistration.Utils.RegisterManager seems to be doing some scheduled checks and doing something with this collected data in the first 24 hours, then phased at 15 and 90 days. It is not clear what is happening having only done an initial scan over this.
It does look like they are doing some checking to see if the device is a Nokia device and selectively doing or not doing location-based stuff based on that, e.g. from com.evenwell.autoregistration.Utils.GetInfo
Code:
2019-03-30 20:09:25.108 16558-16577/? D/[CAIVS] GetInfo: getCellLocation: in black list
Further investigation probably warranted. This looks a bit suspect and might only send data on specific days (and would explain why I did not notice anything outbound over my 4 day period of checking before).
Click to expand...
Click to collapse
I found this in English: https://web.archive.org/web/20081027134825/http://www.cseed....
Quote: "CAIVS notifies our system when the handset is purchased. Data includes the date, time, and location that a SIM card is first inserted into the handset, the inserted SIM card's telecom operator, the handset's operating system, the handset model and phone number, and even the time when it is first turned on. "
WTF.
It is not clear at the moment if there is a blacklist on the MCC code going on in com.evenwell.autoregistration.Util.XMLHelper that reads from /product/etc/AutoRegConfig.xml is this line:
Code:
<NOKIA>
<REJECTMCCLIST>232,206,284,219,280,230,238,248,244,208,262,202,216,274,510,272,222,247,295,228,246,270,278,204,242,260,268,226,231,293,655,214,240,228,234,235,520</REJECTMCCLIST>
</NOKIA>
These are - I think - the Mobile Country Codes (https://en.wikipedia.org/wiki/Mobile_country_code) it gets from the cellsite. This list is basically the EU + South Africa, Thailand and Indonesia. Don't know what things are like in SA, Thailand or Indonesia but in the EU this sort of thing would not be acceptable. Looks also like there is a hard-coded short-circuit in getLocation() in com.evenwell.autoregistration.Util.GetInfo to always return no location lat-longs which appears to trigger another shortcut in RegisterManager that shortcuts out to the "Caivs not in registration phase" log output which returns without triggering the sendToServer() calls on other code paths.
I am not convinced that this will never send location back, but looks like it might have been updated with to prevent phoning home in those countries in the MCC list (and maybe by hard-coded shortcuts the actual code). This would meet with what was said with there recent phoning home response from Nokia - i.e. (https://translate.google.com/translate?u=https://nrkbeta.no/...)
Click to expand...
Click to collapse
As foobarbazetc noted, the listed packages have been specifically developed for Nokia (HMD). And although many only actually send telemetry on Nokia phones that have been sold in China, there is still quite a lot of data at stake that can be used to track the device when combined with data from other sources.
I wanted to share my findings to create the awareness that the mechanisms are there and it only takes a little misconfiguration (see https://arstechnica.com/gadgets/2019/03/hmd-admits-the-nokia...) and all this goes straight to the Chinese authorities.
Click to expand...
Click to collapse
full thread: https://news.ycombinator.com/item?id=19530670
This is why I feel like a custom rom for this phone is long overdue so we can use our phones free of concerning bloatware and privacy issues.
TL;DR: Could you check with AIDA64 if your phone support Wi-Fi Aware and report the result here?
Hello everyone, I am trying to create a list of the Android devices compatible with Wi-Fi Aware.To this date, the Pixel 3/3XL and the Galaxy Note 10/10+ are the only certified smartphones for Wi-Fi Aware. Oddly enough, none of them actually advertise that they support it on their storage page.I discovered that some other devices, like the Pixel 2 or Xiaomi Mi 8 and Pocophone are compatible with this technology but do not advertise their compatibility as well.
In a nutshell, I have no way to know which phones are compatible without getting my hand on them.
For this, I would like to request you to check if your phone is compatible with this technology. You must have Android 8 or more to have support for Wi-Fi Aware. If you match this requirement, you can know if your phone support Wi-Fi Aware by using the application AIDA64, which provide multiple specifications of your phone. The information can be find in the Network page, in Wi-Fi category. It requires to have the Wi-Fi switched on in order to test the API access.
Whether your phone support or not the technology, please report the result here, alongside with your phone model.You can report the result the way you want, screenshot, text. I will then add your phone capability to this list (That I cannot link yet because of this forum restriction...)
I am currently especially focused on smartphone having Snapdragon 845 or Snapdragon 855 processors
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!
Hey,
Germany is implementing EU-Alert (ETSI TS 102 900 [1]) at the moment and referring to the local News, it is a huge mess [2].
But let's start at the beginning.
CellBroadcast is a core component of each mobile network generation (2G,3G,4G,5G,...) and part of the 3GPP spec. CellBroadcast basically allows the network to send a simple SMS to all mobile phones connected to a specific base station. Thes SMS-CB are sent with a Message Identifier (aka Channel, aka Topic) which gives them a special purpose by convention. e.g. ID / Channel 50 is often used for area related information [3], while channel 207 might broadcast local weather information. Since not all Channels are standardized, there is also the option to broadcast an Index that lists all channels with a description. And since users probably don't want any message broadcasted, users have to subscribe to these channels.
Since decades now, CellBroadcast is also used for public Emergency Warnings. This means that, by definition of a country, a specific channel is used to broadcast Emergency Warnings. Long time ago, in many countries it looks like Channel 919 was used for this purpose. For this to work properly, mobile phones were instructed to subscribe to channel 919 by default and also use a special ringtone (even if muted) to alert such a message.
Later - over 12 years ago - additional channels from 4370-4399 were standardized in ETSI TS 123 041 [4] for public warning systems like CMAS, EU-Alert, KPAS. All using the same channels which is beneficial for global roaming.
Android of course supports these public warning systems specified in ETSI TS 123 041 [4] since at least Android 4.2.2 [5]. And nations that use these systems already, like CMAS in the US, report very high and reliable coverage.
However, referring to German news [2] and government, not many phones that are currently on the market will actually support EU-Alert in Germany, despite already supporting EU-Alert in Netherlands or CMAS in the US.
How is this possible when exactly the same SMS-CB is broadcasted, just in a different country?
Golem [2] says that Samsung and Google already confirmed that EU-Alert is currently not supported in Germany, but updates will be rolled out to recent devices.
This strongly suggests to me that OEMs like Samsung and Google actually added country specific filters/configurations for these public warning systems to their phones without deploying a reasonable fallback. Public warning systems based on ETSI TS 123 041 [4] thus may only work in countries that were known to use these systems when the phone was released.
Isn't this an obvious issue?
Google said, starting with Android 11+ it will be possible to update the CellBroadcastReceiver App via Google Play. So devices with Android 11+ will likely receive an update to support EU-Alert in Germany. For Android 10 and older, OEMs will have to supply updates.
What also confuses me is the fact that all Android Phones I own (Nexus 4 with Android 5, Nexus 5X with Android 8, Pixel 3a with Android 12) here in Germany do actually offer the setting for Emergency Warnings and they are already enabled by default. So I assume they would work? Did Google actually deploy a sane default configuration here already?
But if they did - why isn't it working on ALL Android 11+ Phones already? I'm pretty sure my Pixel 3a uses Googles CellBroadcastReceiver App which is provided through the Play Store. So all Android 11+ phones should already use the exact same App?! Or am I wrong here? So what is this update Google actually needs to provide?
And does this also mean that with Android 11+ OEMs are not allowed / cannot implement their own Emergency Warning CellBroadcastReceiver?
This topic is really confusing to me
Shouldn't it be really simple?
All phones, regardless of the OEM, should have a proper SMS-CB Application which allows you to subscribe to custom channels, view the index, and manage your SMS-CB Messages.
Phones should also be aware of special channels to apply special ringtones etc if needed, but they should have a sane fallbacks!
A phone that knows about NL-Alert and CMAS may call messages on Channel 4370 received in the Netherlands "NL-Alert". But when it receives the same message in Germany, it shouldn't just drop it! It should display it as warning and call it whatever it wants. And if it doesn't know about CMAS / EU-Alert, it should just receive it as regular SMS-CB.
Can't be that hard?
Interestingly enough, Samsung phones allow you to subscribe to custom channels. Google phones do not :/
Should there be a better / more enforced standard, so that a country that wants to implement CMAS/EU-Alert in the future doesn't have to rely on OEMs help?
And finally some technical Questions:
I found zero Apps for Android that would allow me to subscribe to custom CellBroadcast Channels on my Google Android phones. Is this even possible?
Also, is it possible to test these CellBroadcasts somehow? Is it possible to write an App that can inject SMS-CB into the system?
Sorry for the long post, but I think this an important Topic.
Let me know what you think
Do you have experience with these Emergency Warnings already?
[1] https://www.etsi.org/deliver/etsi_ts/102900_102999/102900/
[2] https://www.golem.de/news/cell-broadcast-warum-es-am-warntag-ruhig-bleiben-koennte-2206-165822.html
[3] https://source.android.com/devices/architecture/modular-system/cellbroadcast#channel-50
[4] https://www.etsi.org/deliver/etsi_ts/123000_123099/123041/11.04.00_60/ts_123041v110400p.pdf
[5] https://cs.android.com/android/plat...ternal/telephony/gsm/SmsCbConstants.java;l=58
Hey! I was just researching something about this. Thanks for your detailed post.
I am from Chile and, in my case, my operator had subscriptions to two channels: 919 and 920.
In order to see the Cell Broadcast menu in the Messages app, I had to override a CSC setting (I use a Samsung device), particularly "CarrierFeature_Message_DisableMenuCBMessage") because it seems some Chilean operators ordered Samsung to hide it.
Even then, the Google Cell Broadcast app would not let me modify settings other than test alerts.
In my country these emergency alerts are quite unreliable and are often sent by mistake or to the wrong place (i.e. sending a tsunami alert to an area more than 100 km away from the coast).
Shooting Star Max said:
Hey! I was just researching something about this. Thanks for your detailed post.
I am from Chile and, in my case, my operator had subscriptions to two channels: 919 and 920.
In order to see the Cell Broadcast menu in the Messages app, I had to override a CSC setting (I use a Samsung device), particularly "CarrierFeature_Message_DisableMenuCBMessage") because it seems some Chilean operators ordered Samsung to hide it.
Even then, the Google Cell Broadcast app would not let me modify settings other than test alerts.
In my country these emergency alerts are quite unreliable and are often sent by mistake or to the wrong place (i.e. sending a tsunami alert to an area more than 100 km away from the coast).
Click to expand...
Click to collapse
Can you explain how you disabled this CSC setting and on what samsung phone/os?
You can see Googles/Androids latest default configuration for Chile (MCC 730) here:
https://cs.android.com/android/plat...apps/CellBroadcastReceiver/res/values-mcc730/
The config.xml really has some restrictive features enabled :/
Thanks for your reply!
Please note that all the following information assumes you have rooted your device. It's impossible to override this configuration otherwise.
My device is a Galaxy Note20 Ultra (Exynos version, SM‑N985F) running Android 12, One UI 4.1.
As you might know, Samsung devices include several packages named “CSC”, which define settings according to a sales code matching with a region. For example, a device sold in Chile without a carrier uses the sales code CHO, while one sold by operator Movistar uses the sales code CHT.
In the Galaxy Note20 Ultra, the CSC packages are stored in /optics/config/carriers/single (older Samsung devices might use /omc/).
Once you find the sales code matching with your current configuration, you can grab two files: cscfeature.xml and customer_carrier_feature.json. Taking CHO again as an example, the files would be /optics/config/carriers/single/CHO/conf/system/cscfeature.xml and/optics/config/carriers/single/CHO/conf/system/customer_carrier_feature.json.
These files are encoded, but OmcTextDecoder can take care of that.
In the case of CHO, customer_carrier_feature.json has the value "CarrierFeature_Message_DisableMenuCBMessage":"TRUE", which hides the cell broadcast menu in the stock Messages application. Just replace “TRUE” with “FALSE”, save the file and push it to its location. The next time you reboot your system, it will be applied.
Regarding the link you sent, I think we could get around that configuration by decompiling the GoogleCellBroadcastApp.apk through Apktool, modifying the restrictive values, and then pushing the APK to the device, replacing the original version.
Thank you!
Let me know if you managed to patch your original CellBroadcastReceiver.apk!
I actually tried using Runtime Resource Overlays (RROs) which is described on the official docu about CellBroadcast in Android.
You can find the result here: https://github.com/xsrf/android-de-alert
However, I didn't quite get these RROs. It looked like in Oreo you can use RROs to overlay any resource of any app without any permissions or matching signatures, which is quite a surprise to me?!
On my phones with more recent OS, I get signature mismatch errors and also it looks like apps now have to define what resources can be overlayed ...