Anyone used this software before? Sounds quite interesting and works on the HD.
http://www.microsoft.com/tag/
Works very well.
I loaded it up a few weeks ago when it was announced.
It starts fine and accesses directly the camera. It searches automatically for tags and then launchs internet to connect to the tag.
I installed it this morning and seems to work pretty well. However I haven't seen any websites or posters with that on it, so it might be a while before we are actually able to use the software.
I to have just installed the app. I like the look of it. I guess we'll just have to wait and see how long before it becomes of use to us.
So useless, why use MS Tags if a worldwide standard - Barcodes - exists already for years - and works on mobile phones with reader software. Just another attempt by MS to waste money.
Lucas0511 said:
So useless, why use MS Tags if a worldwide standard - Barcodes - exists already for years - and works on mobile phones with reader software. Just another attempt by MS to waste money.
Click to expand...
Click to collapse
My thoughts exactly. We have a GREAT 2D-barcode standard QRCode (and to some degree DataMatrix), that's already widely used (by delivery companies, postal workers, public transit companies etc. etc.) and supported, works in black&white and is an open standard (ISO/IEC) that anyone can implement free of charge (Denso Wave has chosen not to exercise it's patent, other than to limit the use of the trademark term QR Code).
Microsoft advertises the technology by comparing the size of the resulting code, naturally a four-color code is smaller than a 1-bit implementation, but 2D barcodes are used to store very little information (shipment ID, URL, phone number etc.), so that's just stupid.
The only interesting thing is the fact that Microsoft tags require less image quality to be scanned successfully, but I for one have never had problems with that even with older phones (sub-VGA cameras), let alone modern ones.
It's nice to see interest in physical interfaces to mobile web like these grow, but I really don't think Microsoft Tags bring enough improvements to the table to warrant using them over standardized technology.
Just my $0.2
Thanks for your insight, quality posting. Sad thing is that few consumers are motivated to use barcodes. Offering rebate through them, like virtual coupons, might be a way to change that.
If MS would truly innovate, they would work on something like this, social tagging:
http://tonchidot.com/index_info.html
I agree with most of the comments questioning the usefulness of this app.
I must admit to actually liking it a lot - works well, simple interface, grabs pictures with the crappy HD camera very well.
BUT, I have never seen a MS Tag in the wild yet, maybe in a few years when I've moved to an iphone (ho ho) ...
When I initially read this, I thought it was ground breaking. However, I was under the illusion that it was using OCR to read whatever you take a photo of to intelligently derive tags and therefore referals to websites.
However, the OCR is only based on Microsoft barcodes. This is a very limited market.
Yet, again Microsoft taking over the world but I sense this will fall flat on it's face.
The standard barcode workaround may work, but how many film poster's or bus timetables (for example) do you know that have a barcode ? This strikes me to be more about physical consumer products than anything else.
Having been using QR Codes for a while now, I must admit I think MS tags are brilliant.
So many cameras on phones struggle with QR Codes, but MS tags can be easily read even when out of focus. There are other things I like about the tag: the ability to track the geolocation of where it was scanned (opt-in basis by people running the tag reader). On their site they have detailed info about just how poor some HTC cameras are when passing streams of data over to other apps - makes for interesting reading!
What I absolutely despise about it is
a) the fact that there is no SDK for it and making up tags using the web site is NOT an option for anybody but the hobyist
b) the fact that MS hasn't clarified whether or not they'd be charging for it
c) I'm not comfortable in leaving all the tracking data in the hands of one company
QR Codes have the benefit of not needing to be printed in colour, but MS tag has the benefit of being read easier using mobile phones.
I don't believe QR Codes will disappear but I do believe MS Tags will be successful. I certainly belive that there's room in the market for it, PROVIDED MS doesn't charge for it.
There have been some indications the Galaxy Nexus would include an FM radio. Is there any conclusive evidence of FM ?
If Google ships the Nexus with an FM app, that would be a departure from previous practice.
The Nexus One shipped with the HTC Desire FM hardware intact, but no app.
The Nexus S did not have the Silicon Labs Si4709 FM chip that the Galaxy S did, and the Broadcom BCM4329 BT/WiFi/FM combination chip was not wired to allow FM.
This Galaxy Nexus apparently has a Broadcom BCM4330 BT/WiFi/FM combination chip like the Galaxy S2 has. But the S2 uses a dedicated Silicon Labs FM chip like the original "S1".
I doubt the BCM4330 will be wired for FM, so I'd guess there must be a Silicon Labs FM chip if the Galaxy Nexus supports FM.
I doubt Google would have created their own FM app, but who knows ? Would it be incorporated into the music app ? Would they use Samsung's FM app, perhaps modified ? Or have they decided their new music store sales will be improved if they neglect FM ?
And if there is an FM app in Google's Galaxy Nexus, can we presume that the source code will be open ?
Kess78 pointed me to Supercurio's doc here: https://docs.google.com/document/d/1a6808W2GwBkBX8x1YwaW3tYm3JSzkp87uQBNWY3TFmE/edit?hl=en_US&pli=1 .
He says : "FM Radio app is not present."
The only other FM reference there is for the Audio Codec:
Linux ALSA driver source code and its register definitions, describing basic audio hardware features available.
Main input/output type supported:
* Headphone
* Speaker
* Microphone
* Bluetooth
* Voice
* FM - digital
* SPDIF over HDMI
...
Click to expand...
Click to collapse
But IMO that doesn't prove anything. First, I don't think he has the exact source code for the kernel on the phone. I've heard the source code is expected to be released in about a month. But maybe I'm wrong, for the kernel code at least.
Second, there are "phantom" FM definitions for a number of Samsung Galaxy devices that don't have the FM chip: The Galaxy Tab, I think the Nexus S and the Galaxy S2 devices with no FM chip, such as AT&T and T-Mobile variants.
So my thinking now is that Google won't be releasing an FM app. Whether or not there's a Silicon Labs FM chip remains to be seen, but I suspect Google went cheap as with the Nexus S and there is no usable FM chip. But I'm just guessing for now.
I believe the Samsung Note spec states that it has an FM radio with RDS. It may be that they use similar chipset in the Galaxy Nexus and there is hope for FM Radio down the road sometime.
htc6500uk said:
I believe the Samsung Note spec states that it has an FM radio with RDS. It may be that they use similar chipset in the Galaxy Nexus and there is hope for FM Radio down the road sometime.
Click to expand...
Click to collapse
A lot of Android phones, I'd say most of them, have bluetooth chips that include support for both sending and receiving FM.
The problem is just that Android lacks a framework and API for it. ST-Ericsson submitted a framework and example app for it to AOSP that has been worked on openly in Gerrit for months with input from several Google people. Unfortunately Gerrit is still down so we don't know the latest progress but it will hopefully be officially supported in the future. Until then, we will probably see FM support for it in CM like many other phones currently enjoy.
htc6500uk said:
I believe the Samsung Note spec states that it has an FM radio with RDS. It may be that they use similar chipset in the Galaxy Nexus and there is hope for FM Radio down the road sometime.
Click to expand...
Click to collapse
MAYBE.
But the Galaxy S and Nexus S are almost the same phone. Yet the Galaxy S has the Silicon Labs FM chip, while the Nexus S does not.
The same is true for some variants of the Galaxy S2. The "canonical" Samsung Galaxy S2 has the Silicon Labs FM chip, while the AT&T and T-Mobile variants appear to have omitted it.
IMO, at least 2 reasons: (1) The phone is a bit cheaper if they don't install the FM chip, and (2) Carriers want us to use their expensive data plans for streaming.
I think Google also has some interest in keeping cheap, "old fashioned" airwave radio from us. Same for Apple.
blunden said:
A lot of Android phones, I'd say most of them, have bluetooth chips that include support for both sending and receiving FM.
The problem is just that Android lacks a framework and API for it. ST-Ericsson submitted a framework and example app for it to AOSP that has been worked on openly in Gerrit for months with input from several Google people. Unfortunately Gerrit is still down so we don't know the latest progress but it will hopefully be officially supported in the future. Until then, we will probably see FM support for it in CM like many other phones currently enjoy.
Click to expand...
Click to collapse
I've spent most of this year developing an FM app for various Android devices. See my sig.
My impression is that the ST-Ericsson Android FM API is doomed. Nobody but them has committed to it. Broadcom is the biggest provider of FM combo chips and has said nothing, and continues to keep their specs secret.
Except for some Japan market Sharp models, can you show me ANY Android phone that supports FM transmit ? Stock or with developer mods ? I tried this on my TI based HTC Legend and it won't work. It needs the proper antenna (and perhaps power) connections, and I've found no phone that has that, likely because they were never designed to transmit, and were even designed to prevent transmit.
Even with a theoretically usable Bluetooth/WiFi/ FM combo chip (Broadcom or TI), if the power, antenna and audio connections are not in place, FM receive is impossible. There are several phones in my app incompatible list that never had an FM app, and that I and nobody else has ever been able to FM enable. IMO nobody will ever FM enable these without impractical hardware modifications.
so this does have an fm radio ! i seen where some say it doesn't and then I seen some that say it does, The unlocked version of the SGS2 has one but the AT&T didn't so this seems too
Technical Details:
Network
2G Network GSM 850 / 900 / 1800 / 1900
3G Network HSDPA 850 / 900 / 1700 / 1900 / 2100
Camera - 5MP
Touch Screen - Yes
Weight - 135g
External Memory - No
Memory Slot - No
Bluetooth - Yes
Vibration - Yes
3G - Yes
GPS - Yes
Connectivity
GPRS Yes
EDGE Yes
3G HSDPA, 21 Mbps; HSUPA, 5.76 Mbps; LTE
WLAN Wi-Fi 802.11 a/b/g/n, dual-band, DLNA, Wi-Fi hotspot
Bluetooth Yes, v3.0 with A2DP
USB Yes, v2.0 microUSB
Additional Features
OS Android OS, v4.0 (Ice Cream Sandwich)
CPU Dual-core 1.2GHz Cortex-A9 CPU, TI OMAP 4460 chipset
Messaging SMS(threaded view), MMS, Email, Push Mail, IM, RSS
Browser HTML
Radio Stereo FM radio with RDS
Games Yes
GPS Yes, with A-GPS support
Java Yes, via Java MIDP emulator
- NFC support
- Barometer sensor
- Digital compass
- Active noise cancellation with dedicated mic
- MP4/H.264/H.263 player
- MP3/WAV/eAAC+/AC3 player
- Organizer
- Image/video editor
- Document viewer
- Google Search, Maps, Gmail,
YouTube, Calendar, Google Talk, Picasa integration
- Adobe Flash support
- Voice memo/dial/commands
- Predictive text input
The specs you have listed are from GSMArena and "may" be wrong. The two people afaik who have the GN have said that there is no native FM radio app. At present we dont even know if the FM chip is even correctly wired inside to receive signals. If it is, then CM7 (or 8) will be able to support it.
mikereidis said:
I've spent most of this year developing an FM app for various Android devices. See my sig.
My impression is that the ST-Ericsson Android FM API is doomed. Nobody but them has committed to it. Broadcom is the biggest provider of FM combo chips and has said nothing, and continues to keep their specs secret.
Except for some Japan market Sharp models, can you show me ANY Android phone that supports FM transmit ? Stock or with developer mods ? I tried this on my TI based HTC Legend and it won't work. It needs the proper antenna (and perhaps power) connections, and I've found no phone that has that, likely because they were never designed to transmit, and were even designed to prevent transmit.
Even with a theoretically usable Bluetooth/WiFi/ FM combo chip (Broadcom or TI), if the power, antenna and audio connections are not in place, FM receive is impossible. There are several phones in my app incompatible list that never had an FM app, and that I and nobody else has ever been able to FM enable. IMO nobody will ever FM enable these without impractical hardware modifications.
Click to expand...
Click to collapse
I think the API has potential still. A reason for not seeing any commits from other manufacturers for it is that it's still not finished and polished enough to be approved by Google. If it is, I think that we will see some more action by the other manufacturers. Also, in theory the Broadcom plugin could be developed by the community since it seems one of the MIUI guys have access to confidential information about commands etc. The basic functionality could probably be implemented by information from what is currently used in MIUI and CM.
I have not seen a phone that supports FM transmit, no. That would just be a bonus though. Why do you say they are specifically designed not to transmit FM? FM transmitting with limited power (to allow close range music transfer) is legal now in many countries. Also, I know for a fact that receiving works fine in many phones in CM so at least that functionality should be possible.
blunden said:
I think the API has potential still. A reason for not seeing any commits from other manufacturers for it is that it's still not finished and polished enough to be approved by Google. If it is, I think that we will see some more action by the other manufacturers.
Click to expand...
Click to collapse
I went searching for this API last night. I couldn't find ANY sign of it except for the original posts and documentation from a year or so ago. Where is this Gerrit code ? Or any evidence of recent activity ?
AFAICT, Google has nothing to do with the SE FM API. Do you have any evidence otherwise ? NONE of the chip manufacturers has said ANYTHING about it either, AFAIK.
blunden said:
Also, in theory the Broadcom plugin could be developed by the community since it seems one of the MIUI guys have access to confidential information about commands etc. The basic functionality could probably be implemented by information from what is currently used in MIUI and CM.
Click to expand...
Click to collapse
In theory ? Probably ? I really don't want to sound harsh, but I will speculate that you are just speculating about these things. And I think you are being too hopeful.
blunden said:
Why do you say they are specifically designed not to transmit FM? FM transmitting with limited power (to allow close range music transfer) is legal now in many countries.
Click to expand...
Click to collapse
Yes, sure it's legal, with the proper FCC or whatever certifications. Those cost money, as does the engineering. The chip connections are specifically made to disable transmit. Thus, no software can enable FM transmit.
I'd be happy to learn I am wrong about any of the above. But until I see evidence, these are my current opinions based on my knowledge and experience.
mikereidis said:
I went searching for this API last night. I couldn't find ANY sign of it except for the original posts and documentation from a year or so ago. Where is this Gerrit code ? Or any evidence of recent activity ?
Click to expand...
Click to collapse
When the kernel.org servers were taken down recently it also meant that AOSP and Gerrit that were both hosted there got taken down too. When Gerrit comes up again and if they keep all the history (that's not decided yet according to jbqueru) you can see for yourself. It used to be available on the following links.
https://review.source.android.com//#change,20506
https://review.source.android.com//#change,20507
https://review.source.android.com//#change,20508
https://review.source.android.com//#change,20509
I do have a limited part of the history from 20507 on gmail but I unsubscribed after a while because it was spamming my inbox. Here is a PDF of the parts I have. Some of it is missing though.
mikereidis said:
AFAICT, Google has nothing to do with the SE FM API. Do you have any evidence otherwise ? NONE of the chip manufacturers has said ANYTHING about it either, AFAIK.
Click to expand...
Click to collapse
Google is involved as in being actively commenting and reviewing it in Gerrit at the time. They provided details of changes they wanted to see etc. and seemed to show some interest in the API. You are right though in that it was written entirely by ST-Ericsson. Also, it's not made by SE (meaning Sony Ericsson) but by ST-Ericsson, a partnership between ST-Microelectronics and Erocsson. No Sony involded.
mikereidis said:
In theory ? Probably ? I really don't want to sound harsh, but I will speculate that you are just speculating about these things. And I think you are being too hopeful.
Click to expand...
Click to collapse
This part was speculation, yes. A third party plugin would not make it into any official builds at least. What I said about someone close to MIUI having some inside knowledge about what commands to send to the chip using hci_tool to enable FM receiving, RDS etc. was based on a claim they made themselves. That claim was send to me indirectly by a researcher from this group. It started with me submitting some comments on Gerrit. It started with me being approached by ST-Ericsson (Andreas Gustafsson specifically) asking if I could provide some more information and if I wanted to help them test it. I was later forwarded a message from the mentioned research group. After some emails back and forth it turned out they needed RDS which is currently not supported for the broadcom chip drivers used in CM. I therefor suggested that he should contact the MIUI guys to find out where they got the basis for the drivers they had written. That's when he told me a that a friend of xinyu had the datasheet for it but wouldn't share it.
mikereidis said:
Yes, sure it's legal, with the proper FCC or whatever certifications. Those cost money, as does the engineering. The chip connections are specifically made to disable transmit. Thus, no software can enable FM transmit.
Click to expand...
Click to collapse
You might be right about it not being wired up for transmission of FM. Receiving works on most phones with compatible chips though as shown by it actually working in CM and MIUI.
mikereidis said:
I'd be happy to learn I am wrong about any of the above. But until I see evidence, these are my current opinions based on my knowledge and experience.
Click to expand...
Click to collapse
Now you at least know what I base my opinions on. Too bad Gerrit isn't up.
blunden said:
When the kernel.org servers were taken down recently it also meant that AOSP and Gerrit that were both hosted there got taken down too. When Gerrit comes up again and if they keep all the history (that's not decided yet according to jbqueru) you can see for yourself.
Click to expand...
Click to collapse
Thanks ! You are more familiar with this than I thought, so my apologies for assuming otherwise.
I'm surprised that 20 minutes of Google searching didn't reveal anything but a few year old documents and posts. Gerrit is still down ? Sheesh ! And that was the only place for somewhat open discussion ?
I've been working 60+ hour weeks on my Android FM app since February, and am trying to earn a meagre income from this project to keep it going indefinitely.
The reverse engineering I continue to do is VERY time consuming, generally has problems, and my app only runs on a fraction of the Android devices out there. So I am EXTREMELY interested in this API, if it has success.
I vaguely recall checking up on this API around August, probably via Gerritt. I had the impression it wasn't going anywhere very fast.
blunden said:
Google is involved as in being actively commenting and reviewing it in Gerrit at the time. They provided details of changes they wanted to see etc. and seemed to show some interest in the API.
Click to expand...
Click to collapse
OK, from your PDF I see one Google email address (Dave Sparks), as well as Broadcom and TI. Interesting...
See my next post for more...
I had an interesting email from someone working for an org with interest in enabling OTA radio on more smartphones.
I posted the Q's and A's on my app thread for anyone interested: http://forum.xda-developers.com/showpost.php?p=19242542&postcount=1601
I think he and I agree that the biggest obstacles include the lack of usable, open APIs, the secrecy of the chip documents, and the manufacturers that specifically disable FM on many devices.
blunden said:
This part was speculation, yes. A third party plugin would not make it into any official builds at least. What I said about someone close to MIUI having some inside knowledge about what commands to send to the chip using hci_tool to enable FM receiving, RDS etc. was based on a claim they made themselves. That claim was send to me indirectly by a researcher from this group
It started with me submitting some comments on Gerrit. It started with me being approached by ST-Ericsson (Andreas Gustafsson specifically) asking if I could provide some more information and if I wanted to help them test it. I was later forwarded a message from the mentioned research group. After some emails back and forth it turned out they needed RDS which is currently not supported for the broadcom chip drivers used in CM. I therefor suggested that he should contact the MIUI guys to find out where they got the basis for the drivers they had written. That's when he told me a that a friend of xinyu had the datasheet for it but wouldn't share it.
Click to expand...
Click to collapse
Yes, as soon as I read the Broadcom chip header file for the MIUI/CM FM app, I was convinced the MIUI folk had some inside info. You don't get register defines like BC_REG_SPARE0 by reverse engineering alone.
My app runs on Broadcom and TI chips using what I've learned through hard rev eng work and what I've found on the net, including that header file. I support Samsung Silicon Labs and V4L too, but those "specs" are more open.
My app also supports RDS. AFAIK, neither the CM FM app, nor the MIUI app support RDS, so I think mine is the only 3rd party Android app that does on these chips. FMTwoo works w/ RDS on Galaxy S/Silicon Labs (as does mine).
And I think my app is the only one that communicates directly through the HCI UART. I had to do that because so many devices use Broadcom proprietary Bluetooth which doesn't support normal HCI access, AFAICT.
BTW, AFAIC, the MIUI and CM FM apps are now distinct. Some call the CM app MIUI, and About still says so. The MIUI FM app for Droid X is using Motorola and TI specific libraries. OTOH, the CM TI support is based on work that I did, via hcitool and (for my app direct access to HCI).
Last I looked the ST Ericsson API was VERY rich (IMO) with a lot of potential features, including handling Audio routing, which is a big problem I deal with regularly.
And yet the only multi-chip opensource Android FM code is the CM code, which is still pretty basic. Until not that long ago it only sent commands blindly, and couldn't get values such as the end frequency from a seek command.
So I feel that unless some individual or company "champions" it, I don't see much prospect for a community API implementation that goes beyond basics anytime soon. And it's not just the FM chips, it's the audio routing system for the phone, and sometimes other things, like antenna switches.
I don't think anybody is going to retrofit current phones with this API, except perhaps on specific aftermarket ROMs like MIUI and CM. There MAY be manufacturer support for this API on future phones.
I've considered writing some plugins myself, given my codebase and info. But for now I'm just waiting to see if this API goes anywhere, and if so I will support another API in my app, in addition to the 5 current APIs, possibly with a 6th (Broadcom proprietary) in the next several months.
I'd be very interested if you could give a name of someone who might be able to share more recent info on the progress of this API.
Thanks !
mikereidis said:
Thanks ! You are more familiar with this than I thought, so my apologies for assuming otherwise.
I'm surprised that 20 minutes of Google searching didn't reveal anything but a few year old documents and posts. Gerrit is still down ? Sheesh ! And that was the only place for somewhat open discussion ?
[...]
OK, from your PDF I see one Google email address (Dave Sparks), as well as Broadcom and TI. Interesting...
Click to expand...
Click to collapse
I understand. There are a lot of uninformed posts on XDA so it can serve to be sceptical sometimes.
Gerrit seems to be relatively poorly indexed on Google, if it's indexed at all. Yes, it's still down unfortunately. It makes me kind of sad since that was the only place I've found that you see and participate in open discussions between Google and the submitter. They usually respond if you make an informed comment or ask a relevant question. Unfortunately it's very hard to get in touch with developers to discuss improvements or report mistakes made in the non-open souce apps.
mikereidis said:
[...] I've considered writing some plugins myself, given my codebase and info. But for now I'm just waiting to see if this API goes anywhere, and if so I will support another API in my app, in addition to the 5 current APIs, possibly with a 6th (Broadcom proprietary) in the next several months.
I'd be very interested if you could give a name of someone who might be able to share more recent info on the progress of this API.
Thanks !
Click to expand...
Click to collapse
I contacted both people I've spoken to at ST-Ericsson about this to ask if there has been any progress as well as if I should refer you to them. I described your interest in this and how you can potentially help out. Unfortunately one of the addresses returned a "no such user" error but one of them seems to work fine still.
EDIT: I should also once again point out after reading the Q&A post you linked to that ST-Ericsson is entirely separate from Sony Ericsson and is therefor not affected by any Sony buy out as far as I know. The thing they have in common is that they both were spawned by Ericsson and then fusioned with competitors and that they are partly owned by Ericsson.
blunden said:
EDIT: I should also once again point out after reading the Q&A post you linked to that ST-Ericsson is entirely separate from Sony Ericsson and is therefor not affected by any Sony buy out as far as I know. The thing they have in common is that they both were spawned by Ericsson and then fusioned with competitors and that they are partly owned by Ericsson.
Click to expand...
Click to collapse
Thanks ! Yes I sent an email to the one shown for Andreas Gustafsson and got that "550 No such user" bounceback. I hope that's just a spam issue and not a sign this API development is dead or struggling,
Yes the names and shifting ownerships etc. is confusing. I had thought that Sony-Ericcson was the only phone manufacturer to have committed to supporting this API.
So was it ST-Ericsson that made this commitment ? And they are a chip company, so how could they make such a commitment unless they have FM chips and were supporting the FM portion of the API, or the same for audio chips.
Basically I'm wondering if any hardware company has made any commitment to producing plugins for their hardware. Or is it all experimental at this point ? I can understand though that various Linux driver standards (such as V4L which also has a radio portion) have had little commitment from HW manufacturers, yet the "community" created drivers and apps for them.
"Geritt" naming is confusing too. CyanogenMod uses "Geritt" and they are up on their servers. So it's "Android Geritt" ?
-----
And yes, I could in theory help out. I could create plugins using my existing code. I guess this only makes sense if I open source the code.
Should I ? I don't know; There are pros and cons. It doesn't make much sense to me that I would do this for FM chips, while "rich" companies like Broadcom do nothing.
I could also do the app side, but there again, drivers are still needed. And it seems a bit more logical that the open source CM FM app be modified to use this API, or even the Qualcomm Code Aurora app.
Open source is great, but doesn't pay the bills unless some corporate sponsorship is involved.
mikereidis said:
Thanks ! Yes I sent an email to the one shown for Andreas Gustafsson and got that "550 No such user" bounceback. I hope that's just a spam issue and not a sign this API development is dead or struggling,
Yes the names and shifting ownerships etc. is confusing. I had thought that Sony-Ericcson was the only phone manufacturer to have committed to supporting this API.
So was it ST-Ericsson that made this commitment ? And they are a chip company, so how could they make such a commitment unless they have FM chips and were supporting the FM portion of the API, or the same for audio chips.
Basically I'm wondering if any hardware company has made any commitment to producing plugins for their hardware. Or is it all experimental at this point ? I can understand though that various Linux driver standards (such as V4L which also has a radio portion) have had little commitment from HW manufacturers, yet the "community" created drivers and apps for them.
"Geritt" naming is confusing too. CyanogenMod uses "Geritt" and they are up on their servers. So it's "Android Geritt" ?
-----
And yes, I could in theory help out. I could create plugins using my existing code. I guess this only makes sense if I open source the code.
Should I ? I don't know; There are pros and cons. It doesn't make much sense to me that I would do this for FM chips, while "rich" companies like Broadcom do nothing.
I could also do the app side, but there again, drivers are still needed. And it seems a bit more logical that the open source CM FM app be modified to use this API, or even the Qualcomm Code Aurora app.
Open source is great, but doesn't pay the bills unless some corporate sponsorship is involved.
Click to expand...
Click to collapse
ST-Ericsson have chips with FM, as well as complete SoCs. I think Andreas might have either changed address or company but I spoke with a guy named Ulf as well and his address worked.
Gerrit is actually the name of the review system that is written by Google and released open source. CM started using it to improve the quality of the code in the project. Usually when people refer to Gerrit it should be fairly obvious which one they are talking about based on context. I was talking about AOSP Gerrit though.
I think the plan was to get other chip manufacturers interested in writing the plugins for it as that would allow them to market yet another feature of the chip to Android phone manufacturers. The chance of a phone manufacturer including functionality that requires them to write a whole new Android hardware API is highly unlikely, unless it's something like 3D screens that is very compelling for the marketing department. For that reason it's important to get the APIs implemented.
I did not mean that you should have to do an official implementation but rather that you might help them make it easier developers to test it. As you said, the manufacturers should not expect the users to implement these plugins. I just let them know you were interested about this and might have some valuable input.
I got an update from Ulf at ST-Ericsson. Work on the API has been moved to their branch in India. I should receive contact information for that team. Not that much has happened with it since AOSP Gerrit went down except for a few bugfixes.
blunden said:
I got an update from Ulf at ST-Ericsson. Work on the API has been moved to their branch in India. I should receive contact information for that team. Not that much has happened with it since AOSP Gerrit went down except for a few bugfixes.
Click to expand...
Click to collapse
Thanks ! Yes, please let me/us know of any developments.
My first impression is that moving a project to a different country is not a good sign.
My second impression is that "not a good sign" is an understatement.
IMO, Life goes on with proprietary APIs and minor roles for ALSA and V4L.
Hi, any news about GN fm radio possibility?
bye
Has anyone heard of using an NFC enabled device to imitate a RFID gate pass? My complex won't give me another one for my fiance. I thought I could copy it, and swipe my Gnex at the gate while my fiance use the proxicard HID.
I'm ignorant of the details of the two technologies, so this is probably impossible. Worth asking. Thanks
I would sure hope not. Sounds like that would be a pretty big security risk for companies that use such cards for sensitive locations.
Sent from my Galaxy Nexus using Tapatalk 2
It is possible I believe. I know for Bamboozle that the NFC wristbands had no security and I was able to get into VIP area with no problems.
I would imagine that it is likely since I doubt that their NFC security is high.
With Regards to cloning an NFC tag and an RFID card. No it won't be possible. You have mentioned two technologies that are similar but not the same. NFC and RFID work the same in theory, but at different radio bands. Think of it like ATT phones vs. T-Mo phones. Some PC adaptors can read/write both, but the GNex can't.
Second flaw is that you probably wouldn't be able to use the GNex itself to open the door. The much more likely solution would be to use the GNex to capture the info on the old tag and write it to a different tag of the same type.
Third, and this ties into what Self Righteos Banana said about the NFC wrist bands at Bamboozle, most places don't have high security on their NFC or RFID solutions, but the software isn't quite there for GNex to fully exploit this. We were able to read the wristbands and determine that all of them, VIP, 1 day, 3 day etc. etc. had the same info stored on the tag. They were relying on the site staff to visually identify the various wristbands as well as scan to see if they were genuine. With this, a little social engineering got us into restricted access. We weren't able to rewrite the wristbands completely without altering other bits yet though. One of us wrote Hello to an unused portion of the memory, but it wrote header info in adjacent bits, not zeroes. I assume this is based on protocols that the phone (or other NFC devices use). So we were able to read and write to the tags, but could not clone them. For that I think you would still need a PC until software catches up.
EDIT: Also since this is a question, I feel I should remind you to post it in the Q&A section and not general. Also there is an NFC Hacking subforum.
Thanks a lot for the valuable info. I'll hunt around in the NFC hacking section. Sorry about posting in the wrong forum. I won't make mistake again.
When will the widespread and accepted use of NFC in America happen? We've had it on phones for about 2 years now but it's still not implemented fully. Almost all new android and a few WP8 phones are getting it, but it still doesn't have great usage. Among us technologically advanced people it has uses but what about everyone else? Wallet seemed strong. It with everyone blocking it it's iffy. The s beam commercial is helping but it's still not @ it's potential.
Sent from my razr m using xda app-developers app
IMO once the carriers get sorted with NFC mobile payment. and integrated into our public transit systems it will start really kicking off. At least thats how it is in Japan. Unfortunately the average consumer wouldnt likely take advantage of the more complex, yet outstanding features. Even something such as tasker integration seems too difficult for most consumers. However, add wallet less payment and instant rewards, they'll be all over it.
Sent from my SAMSUNG-SGH-I747 using Tapatalk 2
Widespread acceptence is quite a broad request. Once peer-to-peer mode is widely available on handsets the standard will likely be used to exchange data or play simple games with each other. Exploring reader functionality for non geeks will probably be more widespread over time. Features like business cards etc may take of as well as other cool stuff that is done via tasker. You always have to see though that making stuff with tasker etc requires a bit of knowledge by the user hence why there are many users that may never use nfc with its potential because they just don't know / understand how to do it. Not every smartphone user is sufficient in programming etc. (A fact that is forgotten by many devs these days it seems to me.)
Use cases that will require card emulation will take quite some time though. Number one reason is that manufacturer and service providers try to block each other. Number two reason is that there is no standard out there yet. Wanna use Isis? Well buy an Isis ready phone (those are smartphones with a special version of the OS) etc. Right now every NFC payment and physical access service requires a different service provider specific OS. As long as this does not change I doubt its going to get widely spread.
At least 2 or 3 more Years would be my vote. So I take 2014
NFC
Honestly, I just found out about wallet a few months ago, sadly enough. Sounds like a promising technology though. The GS3 commercials were classic in illustrating its....capabilities...
I don't think, NFC will see any widespread uses anytime soon.
Configuring your phone by tapping it to a tag is a geeky thing to do. Most people are not geeks. They either go with a mediocre "one size fits all" setup or will manually adjust their devices whenever needed to avoid the learning curve and the additional costs of programming tags.
Wireless money transfer? Dream on! That's the wet dream of the banks. Who are interested in putting transaction fees on every purchase. Only problem: even non geeks understand that paying by just holding the phone next to a reader will make it subject to e-pickpocketing.
onyxbits said:
I don't think, NFC will see any widespread uses anytime soon.
Configuring your phone by tapping it to a tag is a geeky thing to do. Most people are not geeks. They either go with a mediocre "one size fits all" setup or will manually adjust their devices whenever needed to avoid the learning curve and the additional costs of programming tags.
Wireless money transfer? Dream on! That's the wet dream of the banks. Who are interested in putting transaction fees on every purchase. Only problem: even non geeks understand that paying by just holding the phone next to a reader will make it subject to e-pickpocketing.
Click to expand...
Click to collapse
Dude, most stores here in NYC (including Macy's, which has non-geeky people) have Google Wallet compatible card readers. There are Samsung ads on my campus and in the city on telephone booths that say "Tap your phone for free music/eBooks/videos". It's spreading slowly but surely. It's available on pretty much all phones coming out now, and stores and other places of interest are starting to take notice. I mean look at the latest Samsung ads. People with iPhones keep asking me if they can do "the bumpy thing" to send things to each other.
Product F(RED) said:
Dude, most stores here in NYC (including Macy's, which has non-geeky people) have Google Wallet compatible card readers. There are Samsung ads on my campus and in the city on telephone booths that say "Tap your phone for free music/eBooks/videos". It's spreading slowly but surely. It's available on pretty much all phones coming out now, and stores and other places of interest are starting to take notice. I mean look at the latest Samsung ads. People with iPhones keep asking me if they can do "the bumpy thing" to send things to each other.
Click to expand...
Click to collapse
Yes, NYC, but we were talking about widespread adoption, which to my understanding means: pretty much everywhere, not just in the hip places. Around here, I see little about NFC technology. In fact, NFC was one of the reasons for me to get a Nexus 7. I was rather disappointed when I found out that non of the major hardware stores seem to carry them. Personally, I think that availability of tags is a major factor for achieving a breakthrough. That "bumpy thing" is cool in the ads (isn't it nice how marketing is able to play us by appealing to our primal instincts?) but in reality is stopped in it's tracks if you don't have compatible devices.
It'll be adopted widespread when iPhones finally adopt it..then everyone will act like apple invented the best thing since sliced bread and fall down and worship the all powerful "i"
thewarhawk said:
It'll be adopted widespread when iPhones finally adopt it..then everyone will act like apple invented the best thing since sliced bread and fall down and worship the all powerful "i"
Click to expand...
Click to collapse
True. The least common denominator.
Sent from my GT-I9300 using Tapatalk 2
https://www.xda-developers.com/android-13-hardware-drivers-licenses/
February 16, 2022 10:26am Adam Conway
Google is changing how new Android 13 devices should store driver’s licensesCarrying a wallet has become less of a necessity for me thanks to my smartphone and Google Pay, but there are a few cards that I can’t go without. A driver’s license would be one such card, though a digital driver’s license offers multiple advantages over the traditional ID card. You can’t lose it, you can wipe it remotely if your phone gets stolen which means you’re less likely to get your identity stolen, and you’ll have an easier time bringing it up on request. Google introduced the Identity Credential API in Android 11 for storing identity cards, though now it appears that devices launching with Android 13 will require additional hardware for storing digital driver’s licenses.
As reported by Esper, a recent code change suggests that chipsets launching with Android 13 must support the Identity Credential Hardware Abstraction Layer (HAL) at feature version 202201 or later. 202201 of the Identity Credential HAL introduces support for presenting multiple documents during a single transaction, such as simultaneously sharing your driver’s license and motor vehicle registration. Google can’t mandate that devices upgrading to Android 13 must support it, but new devices that launch with Android 13 will need to, as enforced through a test in the Vendor Test Suite, or VTS.
For context, the VTS is an automated testing suite that validates the vendor implementation is compliant with Google requirements. It consists of a set of testing frameworks and test cases, testing both the Android system’s core HALs and libraries, and the low-level system software such as the kernel, modules, and firmware.
The Identity Credential HAL enables the storing of identity documents in the device’s secure hardware, which is met by the inclusion of a Trusted Execution Environment, or TEE. This is a dedicated area of the main applications processor for executing sections of code in an isolated environment. Not many devices have actually introduced the Identity Credential HAL despite TEE implementations being widespread.
Interestingly, there’s also the Identity Credential Direct Access HAL too, though its implementation won’t be required. It essentially allows for direct access via NFC to the secure enclave that holds a user’s documents even when the battery is too low to boot the OS. This is only possible when the secure hardware features a CPU and storage device separated from the applications processor. Very few devices meet this criterion, and the only devices that currently implement the Identity Credential HAL itself are Google Pixel devices.
While mobile driver’s licenses are gaining traction across the U.S., Google intends for the identity credentials API to be generic and to hold other secure documents, too. Motor vehicle registration and vaccination records are two potential use cases. The TSA plans to begin recognizing mobile driver’s licenses as valid IDs for domestic travel soon, and at least 30 U.S. states have already issued or plan to issue them. We’ve already seen as well that with iOS 15, Apple announced that the TSA would accept its digital IDs for domestic travel.
There are obviously a ton of security concerns when it comes to storing personal identification on your smartphone, but Google is taking steps to make it as safe as possible. There’s definitely an upside to carrying your documents digitally instead of a physical card that can be lost or stolen, but additional hardware for storing those documents will go a long way towards convincing authorities to use the Identity Credential API when developing these applications.
Click to expand...
Click to collapse
That is impressively backwards. Digital means *easier* to steal than something physical. Regardless of what kind of nonsense hardware is associated with it, gooble's control over their blobware means that this kind of thing OPENS UP THE DOOR to MASS identify theft.
Speaking as a computer engineer.... NO EFFIN WAY.
96carboard said:
That is impressively backwards. Digital means *easier* to steal than something physical. Regardless of what kind of nonsense hardware is associated with it, gooble's control over their blobware means that this kind of thing OPENS UP THE DOOR to MASS identify theft.
Speaking as a computer engineer.... NO EFFIN WAY.
Click to expand...
Click to collapse
You're entitled to your opinion. I think probably 99% of the folks who regularly read in the P6P section already know your opinion on that because you feel a need to visit so many threads and repeat this, and even repeat similar or the same things in multiple threads one right after the other. Whether you're right or wrong, doesn't matter. If you could please resist the temptation to repeat it in my threads, I'd greatly appreciate it.
Maybe make a thread specifically for your purpose.
Thank you.
96carboard said:
That is impressively backwards. Digital means *easier* to steal than something physical. Regardless of what kind of nonsense hardware is associated with it, gooble's control over their blobware means that this kind of thing OPENS UP THE DOOR to MASS identify theft.
Speaking as a computer engineer.... NO EFFIN WAY.
Click to expand...
Click to collapse
Much more fun to give myself to Google and let the ecosystem work for me.
/half sarcasm
Scary stuff. This feels like the precursor to vaccine passports, and social ranking like China. Scan your phone to see if you are allowed to eat here.
roirraW edor ehT said:
You're entitled to your opinion. I think probably 99% of the folks who regularly read in the P6P section already know your opinion on that because you feel a need to visit so many threads and repeat this, and even repeat similar or the same things in multiple threads one right after the other. Whether you're right or wrong, doesn't matter. If you could please resist the temptation to repeat it in my threads, I'd greatly appreciate it.
Maybe make a thread specifically for your purpose.
Thank you.
Click to expand...
Click to collapse
These things can't be repeated enough.