Database Users

Question about NFC on S2!!!

Hi,
I wanted to know how this NFC chip works? I heard office access cards use NFC, so say if that is true, how do i replicate the access authorizations on the S2? Do I calibrate the access card with the S2 NFC chip??

Most office access cards do not use NFC, they'll use a different type of RFID. Depending on the company, hardware, and NFC chip, you may be able to use it for access, but I doubt it in most cases.
Regardless, the SGS2 in your hand does not have NFC capabilities unless you're in S. Korea.

slice77 said:
Most office access cards do not use NFC, they'll use a different type of RFID. Depending on the company, hardware, and NFC chip, you may be able to use it for access, but I doubt it in most cases.
Regardless, the SGS2 in your hand does not have NFC capabilities unless you're in S. Korea.
Click to expand...
Click to collapse
Or in India !

Lucky you!
If you do have an NFC equipped SGS2, then try tapping it on your door access reader and see if the reader reacts. If it does, then it probably recorded the UID of the tag in your system. You'll just need your system admin to add that UID to your user account and voila, you're in.
If it doesn't react (I have little experience with the NXP chip in the phone), then you might be able to download an app from the market that will allow you to emulate a tag's UID. Note: After a quick look on the market, I haven't found such an app. One might come about later though, as the functionality to emulate tags was not added until 2.3.3 and most of the NFC apps on the market were created for reading only which came in 2.3. You might have luck contacting an existing NFC developer to add that functionality to their app.
If neither of those work, then your door access system uses a different frequency or protocol all together (the majority do) which means you won't be able to use your phone for access
Hope that helps

the indian version has also nfc onboard?
is this confirmed on the indian s2 site?

slice77 said:
Lucky you!
If you do have an NFC equipped SGS2, then try tapping it on your door access reader and see if the reader reacts. If it does, then it probably recorded the UID of the tag in your system. You'll just need your system admin to add that UID to your user account and voila, you're in.
If it doesn't react (I have little experience with the NXP chip in the phone), then you might be able to download an app from the market that will allow you to emulate a tag's UID. Note: After a quick look on the market, I haven't found such an app. One might come about later though, as the functionality to emulate tags was not added until 2.3.3 and most of the NFC apps on the market were created for reading only which came in 2.3. You might have luck contacting an existing NFC developer to add that functionality to their app.
If neither of those work, then your door access system uses a different frequency or protocol all together (the majority do) which means you won't be able to use your phone for access
Hope that helps
Click to expand...
Click to collapse
Yeah thanks for all the info !! I think I was expecting too much...I thought we would be able to calibrate the access card and the phone (so that it uses the same id that is already recorded by the admin department for access) and it would replace the card!! Anyways....will first have to check whether the card reader reacts to the chip or not first !!
ash969 said:
the indian version has also nfc onboard?
is this confirmed on the indian s2 site?
Click to expand...
Click to collapse
Samsung confirmed it on their twitter account!! We shall only know tomorrow for sure though !

But if I'm not mistaken, India is getting the Tegra2 proc and SuperLCD screen.

BarryH_GEG said:
But if I'm not mistaken, India is getting the Tegra2 proc and SuperLCD screen.
Click to expand...
Click to collapse
You are mistaken...
SAMOLED+ & Exynos.
NFC = Maybe, although sites claim it, I will believe it when I see it launched.

dhruvmalik said:
You are mistaken...
SAMOLED+ & Exynos.
NFC = Maybe, although sites claim it, I will believe it when I see it launched.
Click to expand...
Click to collapse
Yeah....agree with u totally!!! We will believe when we see it (or maybe when the specs are officially released in the event today).

dudes, slcd+tegra is not i9100....its totaly different model i9103

And more so, there is no evidence of the i9103 to go anywhere. Its not in anyones inventory list that can prove that it will be made available to anyone YET... I say YET because its most likely that it will happen IF and when the stock gets low or shortage of parts.

[INFO REQ] Details on CIQ from DEV's

We have all seen this CIQ information in SFR thread and repeated all over the internet on various forums and blog sites.
Code:
What Is Carrier IQ? Why Should We Care?
3/31/2011: Hello, Slashdotters!
Put simply - and bluntly - Carrier IQ is a software package buried deep within Android by Samsung at the behest of Sprint. It has been in active use since the time of the Moment, if not before. The company that develops it, also known as Carrier IQ, bills it as "Mobile Service Intelligence". In their own words,
[T]he combination of the MSIP and IQ Insight lets you move seamlessly from broad trend data across many users, through comparative groups down to diagnostic data from individual devices. Now, not only can you identify trends, you have the power to drill down to specific instances, giving you the insight your specialists need to make a difference.
On its own, that description can vary from harmless, to worrying, depending on how you look at it. It's not until one drills deep down into the system and ferrets out every piece of the software that one truly knows what it contains. As some of you might remember, ACS took the first steps toward disabling the Carrier IQ software with the release of SyndicateROM and Xtreme Kernel 1.0. That, however, didn't even scratch the surface.
Carrier IQ's native libraries are plainly visible - libiq_client.so and libiq_service.so in /system/lib. During every boot, this service is launched - you can see it in Settings > Applications > Running Services as "IQAgent Service". These native libraries are called by non-native (Android application) libraries located in ext.jar (the client) and framework.jar (the service). Removal of these (rather obviously-named) libraries alone, be it the .so files or the libraries in framework or ext, will, obviously, break boot. So I - k0nane - had to dig deeper. To make a long story short, reference to the IQ Service and IQ Client were littered across the deepest portions of the framework, and some of the most basic functions of the Android system as we know it.
Carrier IQ as a platform is designed to collect "metrics" at any scale. What I found it to hook into is far beyond the scope of anything a carrier needs - or should want - to be collecting. Carrier IQ sits in the middle of, and "checks" the data of, SMS and MMS messages. It listens for and receives every battery change notifications. It hooks into every web page you view, and every XML file your device reads. It receives every press of the touch screen. It 'sees' what you type on the physical keyboard. It reads every number you press in the dialer. It can track which applications you use, what 'type' they are, how often, and for how long. It hooks into data sent and received.
.................
What I am asking in this thread is for any specific information about CIQ that Dev's who have worked with it are willing to provide from their personal experience with investigating and removing it. I am also asking Dev's and Forum Members who have come across other articles, threads in other forums, etc, to please provide information with links.
Code:
Provided by chris41g
to be effectively removed you only need to remove it from 4 files. it is referenced elsewhere scattered throughout... but the four main files are
DialerTabActivity.apk
ext.jar
framework.jar
services.jar
then in the kernels initramfs, you have to disable the service in the init.rc
Provided by mkasick
Here's all the files that reference "CIQ", "carrieriq", or "libiq" with instances unrelated to Carrier IQ removed:
/ (initramfs):
- init: /dev/ttyCIQ0 UART, presumably to communicate with radio.
- init.rc: Start iqmsd service if property:service.iq.active=1.
- lib/modules/dpram.ko: Implements ttyCIQ UARTs.
/system:
- app/DialerTabActivity.odex
- app/FactoryTest.odex
- bin/iqmsd
- framework/ext.odex
- framework/framework.odex
- framework/sec_feature.odex
- framework/services.odex
- lib/libiq_client.so
- lib/libiq_service.so
Of these, bin/iqmsd is a purpose-unknown daemon, and libiq_client.so & libiq_service.so the client & service native code. The client & service managed code is implemented in framework/ext.odex & framework/framework.odex respectively.
In addition, the following framework classes reference Carrier IQ in some fashion:
framework/ext.odex:
- org.apache.http.impl.client.DefaultRequestDirector
framework.framework.odex:
- android.inputmethodservice.InputMethodService
- android.net.http.Request
- android.webkit.{BrowserFrame,CallbackProxy,LoadLis tener,WebViewCore}
- com.android.internal.telephony.SMSDispatcher
framework.services.odex:
- com.android.server.BatteryService
- com.android.server.WindowManagerService
- com.android.server.am.UsageStatsService
Finally, libiq_service.so is used exclusively by framework/framework.odex (com.carrieriq.iqagent.client.NativeClient), and libiq_client.so is used by:
- bin/iqmsd
- framework/ext.odex (com.carrieriq.iqagent.service.IQService)
- lib/libopencore_player.so
I am seeking facts, file names, files, information on CIQ in the framework, specifically what files CIQ hooks into, etc. Thank you for taking the time to read this.
I received a response yesterday (June 15, 2011) from a group that has disassembled IQAgent & CarrierIQ.
in response to questions about CIQ's capabilities.
We have actually disassembled IQAgent/carrierIQ and captured its behavior to find exactly what it is sending back to sprint on the samsung optimus phone. The information we found it to collect was basic, such as cell towers, signal strengths, device battery. Nothing alarming on that phone, but Sprint could send a remote update to enable the surveillance features without the owner being aware.
Click to expand...
Click to collapse
Now while the above statement is about the Optimus, I was able to confirm through another source that IQAgent & CarrierIQ collection and transmission capabilities are set the same across all Sprint Android offerings.
During a telephone call with Sprint and in a follow up email Sprint responded to requests for information on Carrier IQ, who was responsible for the installation on Sprint's hardware and asked to directly address concerns over its potentially invasive nature.
the software that is in the Android phones is supplied by Google themselves as well as the manufacturer. We
(Sprint) has no control over the actual operating system supplied to us such as the Carrier IQ as it is indigenous to the Android platform.
Click to expand...
Click to collapse
Off the record, Google has denied this referencing that the Nexus S did not have CIQ installed on it because they would not let carriers install such software on their native Android devices.
In the same conversation and follow up email Sprint stated;
removing the Carrier IQ software from your Samsung Epic device can void your manufacturer warranty.
Click to expand...
Click to collapse
The representative was questioned on Sprint's use of the word "can" but could not elaborate on under what circumstances removal of CIQ would not void the warranty.
Update July 5, 2011
Sprint still refuses to address the concerns over Carrier IQ's potentially invasive nature. When directly questioned on if CIQ as it is installed on Sprint hardware is capable of the level of invasive data collection as previously reported by Steve Toplez, Sprint responds with complete silence.
I have since requested contact and an official response from both Sprint's compliance department and General Counsel. Once again, the silence is deafening.

Good thinking

Sweet ... but this might just start another debate ..

Lets hope it doesn't. I would really like to see this community come together and allow this information to be provided with little or no flaming, thread hijacking or warring.

Description of CarrierIQs Service
Mobile Service Intelligence
Mobile Service Intelligence is the process of analyzing data from phones to give you a uniquely powerful insight into mobile service quality and user behavior. Carrier IQ's Mobile Service Intelligence Platform (MSIP) is the smart database at the heart of our solution. It receives raw data (known as Metrics) from phones and converts them into reliable, repeatable Measures which feed into analytic applications. The MSIP delivers true enterprise grade performance, with its proven ability to process data submitted by millions of phones with outstanding integrity and security.
Get the Insight
We know you don't just want data, you want to solve business problems and identify new business opportunities. The IQ Insight application suite uses data from the MSIP to deliver true Actionable Intelligence, tailored to specific business areas. From the performance information to support the launch of a new phone or service to historical information to understand in detail customer behavior and usage patterns, the IQ Insight suite cuts through the complexity to allow you to focus on critical business issues, create and track Key Performance Indicators (KPIs) and all in the knowledge that the data is measured at the point the customer experienced it – in the phone.
What's more, the combination of the MSIP and IQ Insight lets you move seamlessly from broad trend data across many users, through comparative groups down to diagnostic data from individual devices. Now, not only can you identify trends, you have the power to drill down to specific instances, giving you the insight your specialists need to make a difference. That is the power of Mobile Service Intelligence.
Click to expand...
Click to collapse

http://www.freshnews.com/news/383257/carrier-iq-powers-android-platform-mobile-service-intelligence

twolostminds said:
Lets hope it doesn't. I would really like to see this community come together and allow this information to be provided with little or no flaming, thread hijacking or warring.
Click to expand...
Click to collapse
as info is provided, you should compile it (in an easy to read format) in the first post so others don't have to read through (potentially) pages and pages of stuff.. (you can use 'code' HTML tags to 'condense' longer text into smaller boxes I think)
Just my .02
and hopefully the community can come together and compile good/relevant info without all the drama.

http://www.carrieriq.com/overview/IQInsightServiceAnalyzer/ServiceAnalyzer.datasheet.pdf
by the way, as far as framework.. to be effectively removed you only need to remove it from 4 files. it is referenced elsewhere scattered throughout... but the four main files are
DialerTabActivity.apk
ext.jar
framework.jar
services.jar
then in the kernels initramfs, you have to disable the service in the init.rc

http://www.carrieriq.com/overview/IQInsightDeviceAnalyzer/DeviceAnalyzer.datasheet.pdf
this datasheet, makes it sound like its installed for testing the phone, then turned off and can be turned on if needed for support..

daddymikey1975 said:
as info is provided, you should compile it (in an easy to read format) in the first post so others don't have to read through (potentially) pages and pages of stuff.. (you can use 'code' HTML tags to 'condense' longer text into smaller boxes I think)
Just my .02
and hopefully the community can come together and compile good/relevant info without all the drama.
Click to expand...
Click to collapse
I will be updating the OP on a regular basis and once enough verifiable information is gathered I will be creating a Wiki-like posting.

i would think that if we are rooting and also using custom roms or taking features Sprint has built into the phone (Carrieriq) then would we not be violating the terms and conditions of service. And lets not forget that google can tell if we are rooted as we can not get movie rentals from the market. Also google and sprint are able to see what apps we have installed and if they see super user app then its a safebet we are rooted. If google wants to get rid of rooted apps they can by simply removing them from the market upon carrier request like vzw and att did for wifi tether.

chris41g said:
...
then in the kernels initramfs, you have to disable the service in the init.rc
Click to expand...
Click to collapse
sorry noob here, I'm running stock EC05, how do I remove it from init.rc?

chris41g said:
http://www.carrieriq.com/overview/IQInsightDeviceAnalyzer/DeviceAnalyzer.datasheet.pdf
this datasheet, makes it sound like its installed for testing the phone, then turned off and can be turned on if needed for support..
Click to expand...
Click to collapse
I don't know much about it but I do know it runs in the background at boot. To me, that's not "turned off."

dchawk81 said:
I don't know much about it but I do know it runs in the background at boot. To me, that's not "turned off."
Click to expand...
Click to collapse
The service is running, with logging and reporting turned off, and can (presumably) be remotely activated..
Sent from my SPH-D700 using XDA App

chris41g said:
The service is running, with logging and reporting turned off, and can (presumably) be remotely activated..
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Right. So it's not truly off. Standby isn't off.
Since it's not off, I prefer it gone.

From what I've been able to gather from it it doesn't do much of anything. It has the potential to track stuff, but i'd bet stuff for marketing purposes and possibly troubleshooting remotely.
Everyone is all up in arms over removing it, but there or not it doesn't have any effect on your phone, or battery life.
As far as security purposes, you may as well stop using your phone all together, because thats similar to the kind of stuff google can collect from your phone at any point. Its not a big deal, its not important, and the performance gain for removing any of it is nil.

Well if it doesn't do anything at all, it doesn't need to be there.

chris41g said:
http://www.carrieriq.com/overview/IQInsightServiceAnalyzer/ServiceAnalyzer.datasheet.pdf
by the way, as far as framework.. to be effectively removed you only need to remove it from 4 files. it is referenced elsewhere scattered throughout... but the four main files are
DialerTabActivity.apk
ext.jar
framework.jar
services.jar
then in the kernels initramfs, you have to disable the service in the init.rc
Click to expand...
Click to collapse
Does anyone have a list of every file that references CIQ?

twolostminds said:
Does anyone have a list of every file that references CIQ?
Click to expand...
Click to collapse
That would be an almost impossible task, without going through the source... and even then there are likely to be closed source files too....
The list I gave you is what is edited in a nociq rom though..
Sent from my SPH-D700 using XDA App

chris41g said:
That would be an almost impossible task, without going through the source... and even then there are likely to be closed source files too....
The list I gave you is what is edited in a nociq rom though..
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
You are probably right, it would be impossible without access to both open and closed source. My goal is to put together the most complete and comprehensive information source on CIQ's implementation and capabilities as installed in Android. So any other references that have been found would be greatly appreciated.

Possible Google Wallet Fix

I've seen a couple posts regarding getting Google Wallet to work (and hopefully I'm not being redundant with this post). I've had Google Wallet working on my own 2.3.5 source ROM for quite some time now and I figured I'd share what got it working for me. As a matter of disclosure, I do have the 4G, but I haven't seen anything in the code that would give reason for why this wouldn't work.
While I'm able to build a ROM, I for some reason, don't know how to put together a flashable update. Maybe somebody with a little more know-how can piece this together and try it out, or at least tell me I'm wrong.
Files needed from the GWK74 ROM:
system/etc/permissions/com.google.android.nfc_extras.xml
(I just added the permission entry to the existing com.android.nfc_extras.xml file instead to keep the clutter down).
system/framework/com.android.nfc_extras.jar
The version in the GWK74 ROM contains code that has yet to be released, since korg is down and all. The extra file has something to do with NFC emulation, but I've only glanced at it, so I really couldn't tell you what it does.
system/app/Wallet.apk
Obviously.
Here's the catch: The Wallet app requires permissions from Nfc.apk (NFCEE_ADMIN). By default, the Nfc.apk is signed with the "platform" key, but as long as these two files are signed with the same key, it will grant it the proper permissions to Wallet.apk no matter what key that may happen to be. Considering that Nfc.apk also requests other permissions from "platform" as well, certificate consistency would be advisable.
Hope this works out or at the very least, gets the ball rolling.

Hopefully, someone can make like a flashable zip for CM7 or at least let us know which files need to be copied to our GSM phones so we can extract those files and copy it to system

do you mind zipping up the files used and posting them here?

They're basically the stock files from GWK74 with Wallet.apk and Nfc.apk signed with the same key. My only concern is that since I've used a private key on my own ROM for a while now, I don't remember/know how many or which non-stock ROMs are signed with anything other than the testkeys or which key would be the best for (most) everyone. If the testkeys work universally, I could do that, but I'd hate for someone with differing platform keys getting upset that it's still doing the same FC as before.
For those familiar with using the Android Kitchen, it can do the signing and packaging with testkeys if you're willing to reflash. Might be an easier step for some to take if the command line method seems overwhelming.

As far as Google Wallet working on a GSM Nexus S. I believe there is more protection than it appears. I firmly believe Google has not only modified the NFC drivers and added NFC security to both the drivers and the Firmware. But I also think they added security to the rils and network checks.
How did I get to these conclusions? Well I actually ported the whole NS4G rom over to the GSM. The only things I really had to change were ril libs and the build.prop. Everything else is pretty similar between the two phones. NFC worked and I was able to start up Google Wallet, however, when attempting to add a card to Google Wallet, it kept loading for like 10 minutes until it gave an error. No real description of the error and logcats revealing nothing. Taking out my sim card, I was greeted with a message in Google Wallet that I should check my sim card and insert it if its not inserted. Why would Google Wallet even have anything to do with carriers even connected to wifi? There must be some other things added.
Then I went ahead and decided to revert to a backup of my CM7. I noticed NFC no longer would turn on, it kept giving me an error. Looking at a logcat it looked like it was trying to download and install firmware but failed. Other NS4G users have experienced this same error. Logcats show that it is downloading firmware but failing to be able to install it. My theory: Google added extra security to the firmware located directly onto the NFC chip itself. So now no ROMs (including the new 2.3.6) give me working NFC except for that 2.3.7 rom. I'm still working on trying to fix.
Now I am happy you posted this thread, because maybe if I backport these additions to a GSM rom I might be able to fix NFC. I'm not sure as of yet. I am going to attempt Odin next, but I can already guarantee Formatting System, Boot, Cache, Data did not resolve the issue.

They definitely added something to the firmware. After flashing GWK74 nfc no longer works on 2.3.5. If I flash back to GWK74 it works no problem.
Sent from my Nexus S 4G using xda premium

U could test that driver theory with a chip that hasnt gotten the 2.3.7 update.

apreichner said:
As far as Google Wallet working on a GSM Nexus S. I believe there is more protection than it appears. I firmly believe Google has not only modified the NFC drivers and added NFC security to both the drivers and the Firmware. But I also think they added security to the rils and network checks.
How did I get to these conclusions? Well I actually ported the whole NS4G rom over to the GSM. The only things I really had to change were ril libs and the build.prop. Everything else is pretty similar between the two phones. NFC worked and I was able to start up Google Wallet, however, when attempting to add a card to Google Wallet, it kept loading for like 10 minutes until it gave an error. No real description of the error and logcats revealing nothing. Taking out my sim card, I was greeted with a message in Google Wallet that I should check my sim card and insert it if its not inserted. Why would Google Wallet even have anything to do with carriers even connected to wifi? There must be some other things added.
Then I went ahead and decided to revert to a backup of my CM7. I noticed NFC no longer would turn on, it kept giving me an error. Looking at a logcat it looked like it was trying to download and install firmware but failed. Other NS4G users have experienced this same error. Logcats show that it is downloading firmware but failing to be able to install it. My theory: Google added extra security to the firmware located directly onto the NFC chip itself. So now no ROMs (including the new 2.3.6) give me working NFC except for that 2.3.7 rom. I'm still working on trying to fix.
Now I am happy you posted this thread, because maybe if I backport these additions to a GSM rom I might be able to fix NFC. I'm not sure as of yet. I am going to attempt Odin next, but I can already guarantee Formatting System, Boot, Cache, Data did not resolve the issue.
Click to expand...
Click to collapse
Thanks for chiming in. Appreciate the info
Hmm, that's odd because aside from those three files and the vendor binaries, everything else on my ROM is from the 2.3.5 source files (since I don't have a choice for source files, really). The first thing I tried when Wallet was giving me fits was to poke around the APKs to see if they were holding any additional files, but I didn't locate any in Wallet and the NFC app file is too small to hold any additional files (and doesn't, since I checked anyway). The 2.3.7 nfc_extras JAR file only contains three java files (compared to the two from 2.3.5) so I don't suspect anything warranting investigation.
It's hard to imagine Google going through so much trouble to block their own product on their own phone. Unfortunately, I don't have access to a non-Sprint Nexus S, so I cannot account for the SIM message you experienced, but the hardware vendor for the NFC component appears to be the same (NXP) for both phones and it just doesn't make sense for them to use two different components for the same model of nearly identical phones. I'll try using the libpn544_fw.so binary from the standard crespo and see what kind of (ill) effects I experience.
I did notice during my trial-and-error period that the error messages and the manner in which they would show up seemed to vary slightly. Adding the JAR file alleviated the persistent com.google.android.apps.walletnfcrel FC during startup and use. After that, the signing took care of the persistent 'insufficient system privileges' (or something to that effect) on startup.
I'd be interested in what is in your log readout. Personally, logcat gets visually overwhelming to me, so I just use ddms to filter out the other processes and error messages from obfuscating what I'm looking for. The thing that Wallet is trying to access is NFC permissions, which Nfc.apk appears to have sole (or at least primary) responsibility for. All of the protests coming from Wallet that I observed were related to its inability to be granted permissions from Nfc for NFCEE_ADMIN, which is specified in its AndroidManifest file as being under protectionLevel="signature", of which it is assigned to "platform" by default. That would explain why people with the stock ROM can get it to work, since it still retains the Google signature keys structure. I suspect most of the alternative ROMs are running some varying key structure, but that is just speculation on my part. I suppose modifying the AndroidManifest file to explicitly give permission to Wallet would also address that, but at the time, I considered that unnecessarily tedious.
I'm still betting on certificate-connected privileges being the primary culprit, but I'll give the NFC binary file a run and see what happens.
Update:
Ran with the libpn544_fw.so from crespo and Wallet initially FCed. I pulled the file through ADB first to make sure it was the one installed and it was, but after the FC, I pulled the file again and it was the regular one for crespo4g. So, unless I misread it or made a mistake somewhere, something is replacing the file. I pushed the original file back, ran it, and pulled it again and it seemed to stick, but I suspect it's running from cache. So basically, it appears that the binary from crespo is insufficient, as I got numerous errors in ddms as a result. I don't know if it has the same effect both ways though. Has anybody tried the crespo4g NXP binary yet with any luck?
Also, I do apologize for some misinformation earlier. The 2.3.7 NfcGoogle.apk does contain a libnfc_jni.so file, but it's already in system/lib, so I don't know if that has to do with anything relevant.

Need some help i get this error message when i push the files to newest Cm7 nightly based on 2.3.7. Any ideas?

XK72 said:
It's hard to imagine Google going through so much trouble to block their own product on their own phone.
Click to expand...
Click to collapse
Well keep in mind it's not just Google that's involved, but MasterCard, Citi, MoneyNet or whatever that service is that processes the transactions... they may have mandated that some extra security measures be taken to keep the initial rollout limited to a relatively small specific group.

david279 said:
Need some help i get this error message when i push the files to newest Cm7 nightly based on 2.3.7. Any ideas?
Click to expand...
Click to collapse
I encountered the same issue a while back. It's related to the signature keys on Wallet, which is signed with Google's key out of the box. If the rest of your build is signed with testkeys (which appears to be the case), you can resolve that by signing Wallet.apk with testkeys as well.

tobiasly said:
Well keep in mind it's not just Google that's involved, but MasterCard, Citi, MoneyNet or whatever that service is that processes the transactions... they may have mandated that some extra security measures be taken to keep the initial rollout limited to a relatively small specific group.
Click to expand...
Click to collapse
While Google Wallet is a proprietary application, and as such, Google or the forces that be could possibly be responsible for what's occurring and I wouldn't be able to discern whether or not that is true, I personally don't believe that is the reason behind what is happening.
(This is just as I understand it). There certainly are security measures in place for NFC, which the Android system is responsible for handling. The Wallet app is essentially an interface that is PIN secured on the user end and requests relevant permission from Nfc.apk that manages interaction with the NFC-related subset on its behalf. If anything, the credit card companies are concerned with unauthorized transmissions that could result in financial liability on their end. The fact that Wallet requires signature-protected permission authorization from Nfc to access the NFC element shows that Android is not leaving security duties up to the Wallet app alone.
I think the hindrances in getting this to work for everyone is that the people who could develop a fix probably don't have access to the Nexus S hardware variants. I started with the same or similar issues that people faced when trying to incorporate Wallet into their build and eventually got it to work on a 2.3.5 sourced build was the steps above, but I also don't own a standard Nexus S for me to test with, so I couldn't proclaim that it was a definitive fix. I was hoping, at the very least, that it might be contributive towards finding a fix for everyone.

XK72 said:
I encountered the same issue a while back. It's related to the signature keys on Wallet, which is signed with Google's key out of the box. If the rest of your build is signed with testkeys (which appears to be the case), you can resolve that by signing Wallet.apk with testkeys as well.
Click to expand...
Click to collapse
How do I sign apks? Can you send me a wallet apk signed with test keys?
Sent from my Nexus S 4G using xda premium
---------- Post added at 06:03 PM ---------- Previous post was at 05:39 PM ----------
Ok i found a app in the market for signing apks, zips, etc. but im getting the same error.

XK72 said:
While Google Wallet is a proprietary application, and as such, Google or the forces that be could possibly be responsible for what's occurring and I wouldn't be able to discern whether or not that is true, I personally don't believe that is the reason behind what is happening.
(This is just as I understand it). There certainly are security measures in place for NFC, which the Android system is responsible for handling. The Wallet app is essentially an interface that is PIN secured on the user end and requests relevant permission from Nfc.apk that manages interaction with the NFC-related subset on its behalf. If anything, the credit card companies are concerned with unauthorized transmissions that could result in financial liability on their end. The fact that Wallet requires signature-protected permission authorization from Nfc to access the NFC element shows that Android is not leaving security duties up to the Wallet app alone.
I think the hindrances in getting this to work for everyone is that the people who could develop a fix probably don't have access to the Nexus S hardware variants. I started with the same or similar issues that people faced when trying to incorporate Wallet into their build and eventually got it to work on a 2.3.5 sourced build was the steps above, but I also don't own a standard Nexus S for me to test with, so I couldn't proclaim that it was a definitive fix. I was hoping, at the very least, that it might be contributive towards finding a fix for everyone.
Click to expand...
Click to collapse
I will attempt to port it over. Good news is there's some 2.3.7 source available now to build with. I don't have much hope though because a full port didn't even work on a GSM device. Although newer libs might help.
Sent from my Nexus S using xda premium

apreichner said:
I will attempt to port it over. Good news is there's some 2.3.7 source available now to build with. I don't have much hope though because a full port didn't even work on a GSM device. Although newer libs might help.
Sent from my Nexus S using xda premium
Click to expand...
Click to collapse
Do you know where they're hosting the 2.3.7 source? I just realized that they released the 2.3.7 binaries for both crespo and crespo4g, so between those two, there really shouldn't be anything else getting in the way of making this work.

Here: http://forum.xda-developers.com/showthread.php?t=1284517
People are reporting that Wallet works just fine on I902x phones and stock rooted 2.3.6. I'm only one there unable to add prepaid card. Guess it's because my IMEI is generic, and i'm pretty sure that google is using IMEIs for authentication and similar processes...

One factor may be branch of code. In build numbers, the letters have meanings. First letter is Android version (G for Gingerbread). Second letter is branch. Usually this is R for Release. The build for NS4G is W. I don't know what this W branch is. Maybe special "Wallet" branch.
http://source.android.com/source/build-numbers.html
Sent from my Nexus S using XDA App

[REQEST] Working google wallet

I'm looking for working moded google wallet with tap to pay for LG G2 ATT... Thanks

You'll only get it to work if you change your build.prop file.
Sent from my LG-D800 using Tapatalk 2

Google Wallet
I mean could we possibly change our build prop to the lg nexus, or sprint variant of the phone and have it tricked to think its not carrier specific. I did this to my vzw s3 by changing it to the sprints s3 build prop rebooted and VALA! there was google wallet and with nfc i tested out in a few stores and it worked!

secure element
I've been under the impression that google wallet wont look on the sim for the secure element and the g2 doesn't have one built in like the s3. I've done the build.prop and xposed methods without luck so far. keep climbing...

changing the build.prop will not work on this phone.
The problem is that the new (and old) wallet apps only support tap to pay on devices that have the NFC Secure Element implemented in a way that Google Wallet supports. Which to my knowledge is basically, on battery, or in the phone itself. Nothing else will work.
This is not due to our phone being inable to work technically, but Google simply hasnt added support for NFC Secure Elements contained in SIM cards.
It's completely possible to that even if/when google adds support for that, that VZW will have some sort of lock on the SIM that will still break it for us.
Add this to the fact that even ISIS doesnt work on this phone (or at least all previous root check bypasses I've tried dont work) and the fact that ISIS sucks... And you have a very non capable phone as far as tap-to-pay is concerned. Not sure if anything can be done by modders as far as the Secure Element in SIM issue is concerned, Here's hoping, but I have a feeling we're gonna have to hold out until Google at least adds the base support, and then mod past anything else verizon throws at us from there.

http://forum.xda-developers.com/showthread.php?t=2457569
Will this work on the G2?

sansart said:
http://forum.xda-developers.com/showthread.php?t=2457569
Will this work on the G2?
Click to expand...
Click to collapse
No.... reread Waco's post above yours.....

I installed this on my t-mo g2, don't know if this is what your looking for.

Ready2Mosh said:
I installed this on my t-mo g2, don't know if this is what your looking for.
Click to expand...
Click to collapse
Yes it installs, but what people want to work is tap to pay, and it doesn't ....

Sprint G2 coming... cross your fingers
Sprint has been the savior many times over for each phone that didn't support Google wallet on the other carriers. They are releasing the G2 in the beginning of November.
We'll have to wait and hope that we can pull the correct files from the Sprint model and enable the secure element that way.
I'm not the person to do it but I bet someone reading this is....

http://forum.xda-developers.com/showthread.php?t=2486738
This thread has a system dump of the Sprint G2 for anyone who wants to take a look through it for the files needed.

WACOMalt said:
changing the build.prop will not work on this phone.
The problem is that the new (and old) wallet apps only support tap to pay on devices that have the NFC Secure Element implemented in a way that Google Wallet supports. Which to my knowledge is basically, on battery, or in the phone itself. Nothing else will work.
This is not due to our phone being inable to work technically, but Google simply hasnt added support for NFC Secure Elements contained in SIM cards.
It's completely possible to that even if/when google adds support for that, that VZW will have some sort of lock on the SIM that will still break it for us.
Add this to the fact that even ISIS doesnt work on this phone (or at least all previous root check bypasses I've tried dont work) and the fact that ISIS sucks... And you have a very non capable phone as far as tap-to-pay is concerned. Not sure if anything can be done by modders as far as the Secure Element in SIM issue is concerned, Here's hoping, but I have a feeling we're gonna have to hold out until Google at least adds the base support, and then mod past anything else verizon throws at us from there.
Click to expand...
Click to collapse
Fyi, the xposed module in thread http://forum.xda-developers.com/showthread.php?t=2425346 allowed me to get past the root check. Isis still sucks and wouldn't accept my credit cards, but the root check seems to be defeated.
Sent from my VS980 4G using Tapatalk

WACOMalt said:
...The problem is that the new (and old) wallet apps only support tap to pay on devices that have the NFC Secure Element implemented in a way that Google Wallet supports. Which to my knowledge is basically, on battery, or in the phone itself. Nothing else will work.
Click to expand...
Click to collapse
We now know that Google Wallet will install and function on most current Android phones. The tap and pay function now relies on a simulated secure element to allow NFC transactions. As of today, the only phone without the hardware secure element that is said to have successfully implemented the tap and pay feature, is the Sprint G2. There has been a Sprint system dump out in XDA for a few weeks now, but I have not seen any further development on tap and pay functionality on any of the other G2 variants.
I've searched, but was unable to find any successful tap and pay transactions for the Nexus 5 yet in the US. Is it too early? I would've thought someone would have tried it by now...

This isn't Google's problem
WACOMalt said:
changing the build.prop will not work on this phone.
The problem is that the new (and old) wallet apps only support tap to pay on devices that have the NFC Secure Element implemented in a way that Google Wallet supports. Which to my knowledge is basically, on battery, or in the phone itself. Nothing else will work.
This is not due to our phone being inable to work technically, but Google simply hasnt added support for NFC Secure Elements contained in SIM cards.
It's completely possible to that even if/when google adds support for that, that VZW will have some sort of lock on the SIM that will still break it for us.
Add this to the fact that even ISIS doesnt work on this phone (or at least all previous root check bypasses I've tried dont work) and the fact that ISIS sucks... And you have a very non capable phone as far as tap-to-pay is concerned. Not sure if anything can be done by modders as far as the Secure Element in SIM issue is concerned, Here's hoping, but I have a feeling we're gonna have to hold out until Google at least adds the base support, and then mod past anything else verizon throws at us from there.
Click to expand...
Click to collapse
This has nothing to do with Google's implementation or support. They are being prevented by T-Mo/ATT/VZ from accessing the Secure Element.
The Secure Element is not on the battery. Samsung put their NFC antenna in the battery (maybe that's what you're thinking), but the Secure Element is in the phones circuitry or on the SIM or a SD card. Google does support secure elements in SIM's. T-Mo/ATT/VZ wont allow any applications other than theirs to access the secure element in the SIM.

I use Google wallet everyday on my VZW G2. It works great if you are running CM. Not really sure if it will run on stock as I have not tried.
Sent from my LG-VS980 using xda app-developers app

Xiaomi Mi Bluetooth LE Band Protocol reverse engineered!

Since there is no Forum for the Mi Band ...
After receiving my Mi Band yesterday I started digging inside the sourcecode of the Mi Band App to find out interesting stuff.
It works with all BLE device, not only Xiaomi ones
It uses an unsecure protocoll which can be reverse engineered, so you could build an API out of it or port it to other mobile OS.
I will update algorithms & the protocol asap, but there is already a lot of usefull stuff on the protocol inside my blog: http://allmydroids.blogspot.de/2014/12/xiaomi-mi-band-ble-protocol-reverse.html
If someone is interested in writing an API, contact me.

Great! But some questions:
1) when you say "I started digging inside the sourcecode" you mean the smali decompiled from the app apk, right? Or is there some open code I missed?
2) if we create an apk which exposes the API (for example via android intents) can it connect to the device at the same time with the original Mi app? Or is the pairing exclusive to an app so we have to hack the app itself (for example via an Xposed module)? (Note: I'm extremely ignorant about bluetooth LE).
Thank you!

bitblaster said:
Great! But some questions:
1) when you say "I started digging inside the sourcecode" you mean the smali decompiled from the app apk, right? Or is there some open code I missed?
Click to expand...
Click to collapse
Decompiled and looked at smali + java from smali (which skips stuff so make sure to check original smali, too)
bitblaster said:
if we create an apk which exposes the API (for example via android intents) can it connect to the device at the same time with the original Mi app? Or is the pairing exclusive to an app so we have to hack the app itself (for example via an Xposed module)? (Note: I'm extremely ignorant about bluetooth LE).
Click to expand...
Click to collapse
We are currently developing a BLE app to a customer and I agree that it is horrible. Android has really messed up everything they could when it comes to BLE.
Other apps could access at the same time. Pairing is done through the Android not the app itself. Although it could be that the band itself limits this somehow. I will check that soon.

Awesome...I'm glad I found this. I just got my band and didn't realize it only worked with the app from XIAOMI. Very disappointed. Also, I can't even set mine up right now. I set up an account and when I go to sign in it says I have the wrong password! When I go to reset the password it has to SMS me a verification code and it NEVER COMES. Total waste.
I hope you guys get this working soon and we can use it with apps that won't send our data back to mainland China. Do you know if this will work with 'Sleep as Android'? That's what I got this for. I thought it was a basic bluetooth device, not some proprietary POS.

NeoMatrixJR said:
Do you know if this will work with 'Sleep as Android'? That's what I got this for. I thought it was a basic bluetooth device, not some proprietary POS.
Click to expand...
Click to collapse
I uploaded a very first Android App today but it can do only very few things yet - but currently it doesn't do the setup. I don't know that app so I don't know if it can interact with other devices and if, how good. But the Miband can detect sleep phases (pretty good for me) and can wake you, so I guess it could be possible.

motioncoding said:
I uploaded a very first Android App today but it can do only very few things yet - but currently it doesn't do the setup. I don't know that app so I don't know if it can interact with other devices and if, how good. But the Miband can detect sleep phases (pretty good for me) and can wake you, so I guess it could be possible.
Click to expand...
Click to collapse
Downloaded and tried to install your app. Unfortunately gave me an error. Looking forward to a new version.
Thanks for your effort [emoji106]

andbroe said:
Downloaded and tried to install your app. Unfortunately gave me an error. Looking forward to a new version.
Click to expand...
Click to collapse
Does your device support Bluetooth LE and is Bluetooth enabled?

motioncoding said:
Does your device support Bluetooth LE and is Bluetooth enabled?
Click to expand...
Click to collapse
Yes and yes. The problem is during installation. "Error parsing the package"
My phone is a Samsung Note 3
Cheers from Switzerland

andbroe said:
Yes and yes. The problem is during installation. "Error parsing the package"
Click to expand...
Click to collapse
Ah you tried the .apk from /bin? Thats not working. You have to compile it. I will upload a working one when it has some more features.

Hello again,
downloaded and installed Android Studio. Compiled your project, all went quite smooth. Unfortunatly the app still does not quite work. Without the band close it quickly complains that there is no band around (good). With my miband close, it scans for ever (not good). Somehow it does not communicate with it.
The BLE Device Monitor detects it well.
Regards

andbroe said:
Hello again,
downloaded and installed Android Studio. Compiled your project, all went quite smooth. Unfortunatly the app still does not quite work. Without the band close it quickly complains that there is no band around (good). With my miband close, it scans for ever (not good). Somehow it does not communicate with it.
The BLE Device Monitor detects it well.
Regards
Click to expand...
Click to collapse
Hi,
I tried the same actions. Seems problem with discovering.
According to google:
startLeScan: Added in API level 18 This method was deprecated in API level 21.
Changed API from default 21 to 18 - nothing has changed.
MI device is visible in other BLE apps, in Bluetooth settings as well. Original translated app working well.
Nexus 4, android 4.4.4
Android Studio 1.0.1
Regards,
Klym

yeah, I commented out the code that actually loads data. Will fix that.

Could you get the Mi Band to sync with Google Fit?
---------- Post added at 09:45 PM ---------- Previous post was at 08:49 PM ----------
motioncoding said:
I uploaded a very first Android App today but it can do only very few things yet - but currently it doesn't do the setup. I don't know that app so I don't know if it can interact with other devices and if, how good. But the Miband can detect sleep phases (pretty good for me) and can wake you, so I guess it could be possible.
Click to expand...
Click to collapse
There is an api for Sleep as Android.
https://sites.google.com/site/sleepasandroid/doc/sleepcloud-api

How about accelerometer raw data or sleep data, is it available?

Hi,
i try to connect my miBand with my laptop.
I found this site with some source code:
https://bitbucket.org/OscarAcena/mibanda
I installed all dependencies and run this as sudo python miband.py:
Code:
from gattlib import DiscoveryService
service = DiscoveryService("hci0")
devices = service.discover(2)
for address, name in devices.items():
print("name: {}, address: {}".format(name, address))
But after 10 seconds, I get an empty result.
My hciconfig shows this:
Code:
[email protected]:~$ hciconfig
hci0: Type: BR/EDR Bus: USB
BD Address: 00:C2:C6:59:91:73 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:1475 acl:0 sco:0 events:71 errors:0
TX bytes:1723 acl:0 sco:0 commands:47 errors:0
Does anyone know, what to do?

I'd happily swing a few bucks for an app where it can link with google fit.

reconchrist said:
I'd happily swing a few bucks for an app where it can link with google fit.
Click to expand...
Click to collapse
Well...

I just have a quick questions about the possible functionality of the MiBand and what has been discovered thus far. Can the LEDs be individually controlled? Also, I know you can dismiss an alarm by touching the MiBand, does it detect this touch through motion or is there a capacitive switch in the MiBand?
I don't know how much help I can be, but I'm just curious about the technologies that they've been able to pack into the band.

Devo7v said:
I know you can dismiss an alarm by touching the MiBand, does it detect this touch through motion or is there a capacitive switch in the MiBand?
Click to expand...
Click to collapse
Seems there is no "touchpad", when needed (alarm and pairing) bracelet just detect vibrations from finger knocks.
Very likely it's internal firmware function and can't be accessed outside.
Also some advertising: useful additions for Mi Band

@motioncoding
Can you please tell me what Bluetooth profiles are supported by Mi Band ?
For this:
1. Go to the Bluetooth settings on your phone
2. There you will see the names of Bluetooth devices listed including the Mi Band
3. There will be a gear (or options) icon beside the name... tap on that and please post a screenshot of the screen that appears.
Thank You