Hi,
Does anybody know if the new features introduced in ICS (Beam feature for instance) may help in the use of 'NFC card emulation' ?
Thanks,
Javier
This is indeed a million dollar question. I would really like to know an official answer to it.
Current research lead me to the following information:
1) Unofficial Android 2.3.4+ supports Card Emulation for Nexus S. This custom Android OS has no official Google support and the APIs may not fully work.
2) You can have card emulation using Inside's Open NFC Stack 4.3.3 for ICS. I checked the website, and the documentation, live working examples were very weak/almost non-existant. Inside attemps to compete with NXP. With such a website, I see failure for Inside.
I also do not fully understand the hype around NFC if the most important feature - Card Emulation - is not functional.
Some companies, such as Assa Abloy have implement mobile keys based on NFC. I do not know whether they used custom-hacked phones to act as card-emulated phones.
Please share any additional info you find on this topic!
A plain reader/writer can't do much in my opinion. In order for interesting applications such as mobile payments, mobile keys etc to work, card emulation should be enabled.
Any news on this topic?
// Offtopic
Another question is whether the Galaxy Nexus supports the single-wire protocol or not? Particularly, is the SIM card physically connected to the NFC controller?
Cheers,
koRn
NFC UID on Nexus S with ICS 4.0.3
Hi there,
I am using a Samsug Google Nexus S (I9023) with ICS v4.0.3
Does anyone know how can i get a Unique Identifier (UID) in my card emulation application (Mifare 1K) instead of the Random Identifier (RID) ?
I can't use NFC in my company access control if the Identifier is never the same...
Is there any form to pass trough this?
Is this one intentional leak on google official API?
It appears that nobody has yet performed card-emulation on the Nexus S running ICS 4.0.x.
Update:
I tried it myself, and obtained limited functionality. I was also not able to read the ID of the emulated card when the phone was off. (that somehow defies the purpose of card emulation.)
UPDATE (05.05.2012):
I managed to force the ID of the secure element to be fixed. The phone can now be read by an NFC reader even when the phone is off. The Nexus S' NFC antenna (found on the back cover, under a black coating) is powered by the RF field generated by the reader and the embedded SE can be read by the external reader.
If anybody is still interested in the above subject, I will post my steps and compiled sources.
marco-f.nunes said:
Does anyone know how can i get a Unique Identifier (UID) in my card emulation application (Mifare 1K) instead of the Random Identifier (RID) ?
Click to expand...
Click to collapse
Yes, with the hacked Gingerbread OS provided by M0rtadelo (you have to compile from source - nasty procedure, requires good knowledge and confidence with Linux) or by softy007 (search his blog for the compiled binaries), you will be able to have card-emulation working. It is for experimental purposes only. The UID will be fixed, but you cannot do much from there.
marco-f.nunes said:
I can't use NFC in my company access control if the Identifier is never the same...
Click to expand...
Click to collapse
Card emulation is too much in its infancy to be able to do what you want right now. You may do some research on SEEK for Android. I don't know about your company, but the latter might not like a hacked android phone due to security issues.
marco-f.nunes said:
Is this one intentional leak on google official API?
Click to expand...
Click to collapse
Yes, this is intentional. Nick Pelly and Jeff Hamilton officially state so on the official Google IO 2011 presentation. (http://www.google.com/events/io/2011/sessions/how-to-nfc.html)
Hi shailentj,
I'm really interested in this post. Currently, I'm doing the same thing that marco-f.nunes wants to do.
I would like to emulate all the Galaxy Nexus of my company to allow them to open every locked doors. Thus, I just want to emulate a passive NFC tag (through an app for now) [EDIT: but it's just a POC!]
shailentj said:
If anybody is still interested in the above subject, I will post my steps and compiled sources.
Click to expand...
Click to collapse
So, I would be really interested and grateful if you could post it!
Thanks.
Software Developer
Hi Shailentj,
I am trying to develop a NFC application to read the nfc tag, this works fine on emulator, but not working on device/phone.
Please do advice me the steps that help me to read nfc tag through the phone. the app is also having other non nfc model along with it. all others models are working fine expect the nfc part.
Please do help me. also please provide me the steps that you performed and also the compiled source.
Thanks and Regards
Srikanth k
shailentj said:
It appears that nobody has yet performed card-emulation on the Nexus S running ICS 4.0.x.
Update:
I tried it myself, and obtained limited functionality. I was also not able to read the ID of the emulated card when the phone was off. (that somehow defies the purpose of card emulation.)
UPDATE (05.05.2012):
I managed to force the ID of the secure element to be fixed. The phone can now be read by an NFC reader even when the phone is off. The Nexus S' NFC antenna (found on the back cover, under a black coating) is powered by the RF field generated by the reader and the embedded SE can be read by the external reader.
If anybody is still interested in the above subject, I will post my steps and compiled sources.
Click to expand...
Click to collapse
I there, been watching this subject for a while ago and things are going slower then we'd like...'cause everyone wants card emulation to work so that you can just forget your card at home and then pull out your phone and still go to work without calling a mate to open up the door for you.
There's still nothing done, pretty and nifty but it seems there are quite a few solutions to turn up...recently i checked this:
hxxps://play.google.com/store/apps/details?id=at.mroland.android.apps.nfctaginfo
which reads all of my MIFARE 1k cards and pulls out a lot information, but it still as a problem to get the KEYs, of course...the sectors are encrypted...but the above app let's you force the keys A and B to use to read all sectors...you just need to crack A and B KEYs.
So i think, dispite the phone beeing able or not to emulate a tag...i think there's still the problem of getting the keys...so it can truelly emulate the tag, am i correct fellows? 'cause i didn't see anyone talking about this...and it's clear for me...
MIFARE Classic algorithm was hacked some years ago that's not the problem, we can get the keys, proof of concept was people got transportation cards cloned (Oysters for ex.)...but to do so they needed to clone the cards, and for that they had to hack MIFARE Classic algorithm...
Still with me?! Bottom line...maybe i'm getting all wrong...so without getting the KEYs of the card (hacking it!) you won't be able to emulate it with your phone...
Correct, a lot of work cards, gate cards, etc have proprietary software and codes. So getting the keys from the card is a huge issue, and a security issue.
Sent from my Nexus S using Tapatalk 2
I have random access to the security systems at ond of my sites and if i hold my nexus up against the reader it beep / pulse the invalid Card witch it should say once, when then go in to the security logs loads of card ids in the log, is there a way to get the phone to always have the same id?
Sent from my Nexus S using Tapatalk 2
I am really want to know this solution. Can you post the steps here?
shailentj said:
UPDATE (05.05.2012):
I managed to force the ID of the secure element to be fixed. The phone can now be read by an NFC reader even when the phone is off. The Nexus S' NFC antenna (found on the back cover, under a black coating) is powered by the RF field generated by the reader and the embedded SE can be read by the external reader.
If anybody is still interested in the above subject, I will post my steps and compiled sources.
Click to expand...
Click to collapse
I am really want to know this solution. Can you post the steps here?
shailentj, would u please post the steps here?
Why card emulation makes so complicate
I might be wrong. I think the card emulation make things too complicate. If a NFC enabled phone, why not just act as a simple tag with no SE, no SWP, no UICC. Or reader just read such emulated card's UID then proceed the server-side data read back. It likes an ID card, no need to store any sensitive data. When reader gets the UID, anything can be done.
card emulation
Cyanogen9.0 (ICS) supports true card emulation as a 14443-4A/B card
xrodriguez said:
Hi,
Does anybody know if the new features introduced in ICS (Beam feature for instance) may help in the use of 'NFC card emulation' ?
Thanks,
Javier
Click to expand...
Click to collapse
[email protected] said:
Cyanogen9.0 (ICS) supports true card emulation as a 14443-4A/B card
Click to expand...
Click to collapse
Ohhh waiting for to come in JB CM
Sent from my Nexus S using Tapatalk 2
Some science on this topic:
Software NFC emulation
This is really an interesting topic.
It would be great to use my phone to open the door instead using my card...
Any development on this?
Cheers!
I too hope there is some progress in this field?
It would be really great to just clone/dump the raw information from my RFID tag (Mifare Classic 1K) at work, and then use card emulation on my phone to access all the doors and elevators.
What I'm struggling to understand, and where I'm hitting a wall in my research, is where the true limitation(s) lie? Is it in the Secure Element access, and that we need it to control the NFC chip? Or is it simple lack of high level APIs to gain access to the low level functionality of the NFC chip?
Mifare 1k classic emulation on Nexus S
shailentj said:
It appears that nobody has yet performed card-emulation on the Nexus S running ICS 4.0.x.
Update:
I tried it myself, and obtained limited functionality. I was also not able to read the ID of the emulated card when the phone was off. (that somehow defies the purpose of card emulation.)
UPDATE (05.05.2012):
I managed to force the ID of the secure element to be fixed. The phone can now be read by an NFC reader even when the phone is off. The Nexus S' NFC antenna (found on the back cover, under a black coating) is powered by the RF field generated by the reader and the embedded SE can be read by the external reader.
If anybody is still interested in the above subject, I will post my steps and compiled sources.
Click to expand...
Click to collapse
Hi, would you please sharing your steps with us, may be with some code snippets. I am also trying to reach similar goals with Mifare 1k emulation on Nexus S. I would like to know your steps to make the phone respond even when it is turned off with desired UID.
Related
Hi,
someone is interested to develop a Rom with Froyo for the device "Disgo Tablet 6000"?
Thanks in advance
Il Conte 81
I'd love any info on this too. Disgo Tablet 6000 has a rather locked down version of Android that doesn't even have Marketplace nor Facebook. I like it but it's currently useless until you add in some apk's.
I'm therefore willing to experiment a bit with loading roms onto it. Done so on my Hero but would need a few pointers on this one as I go.
Ive updated my rom to 2.2 using a rom for the sylvania tablet - but have lost root access and considering downgrading - I aslo have a running android market but no paid apps (looking into how to enable this)
Its a good cheap device - any input greatly recieved
I downgraded my rom to 2.1 and got root back!! YAY!! Im trying out getting android market on it tonight and seeing if I can get apps2sd working.
Id love to know how to build roms....but...there is no recovery image just the option to install from sd or via the OTG port.
Rom building I have no clue with and unlike regular android which can utilise the recovery process and a rom in zip form you need special drivers and program to push it to the device (if doing it via the otg port) Similar to the RUU for winmo.
The file extension is IUS - I have the files for the 2.1 update and 2.2 and uide if anyone is interested?
Plus Ill post back if I get market working.
Gurry
I've been trying to update a disgo (hwver=12.2.0.5) to froyo but have no idea which of the ius files are safe to flash , i did flash disgo_12.2.0.5.1.4.ius but it seems to be exactly the same as i had already
noticed these are down to £70 on play at the moment has anyone had any more luck with theirs?
disgo (my_disgo) UK on Twitter
alecoddlyiv said:
noticed these are down to £70 on play at the moment has anyone had any more luck with theirs?
Click to expand...
Click to collapse
Recently posted at androidtablets.net, disgo (my_disgo) UK on Twitter & "Should I get one?"
No "official" 2.2 Froyo, however some newly purchased tablets are pre-loaded with 2.2 but it seems to have issues. Others, as noted above, have manually updated using the Sylvania files which seems to be the same as Disgo is doing causing issues.
disgo (my_disgo) UK http://twitter.com/#!/my_disgo is posting updates on their Twitter page.
17 Mar - currently working on a 2.2 update & hopefully it will be released in April with our Disgo Tablet 8000 10.1 Android 2.2 Tablet
Click to expand...
Click to collapse
27 Apr - Still experiencing technical difficulty at the moment. Sorry for the delay, we are working on trying to find a solution!
Click to expand...
Click to collapse
27 May - Sorry no update yet!
Click to expand...
Click to collapse
16 Jun - Hi Sorry for the late reply! The new update is expected hopefully at the start of July!
Click to expand...
Click to collapse
This string of Tweet's is telling, the distributors (Disgo, Sylvania "Digital Gadgets", and others) are having issues with infoTMIC delivering working firmware for these tablets.
Disgo 6000 owners hang in there you may get an update soon.
Click to expand...
Click to collapse
Since the Disgo 6000 is similar to the 7" Sylvania's tablets, this post, in response to Should I get one? in the Sylvania Tablets forum at adroidtablets.net, maybe applicable.
Can be rooted
Can enable adb over wireless
Cannot enable adb through USB
Can enable USB Debugging with work around
Can enable Mock Location with work around, however Not Location aware
SD card cannot be mounted by PC to enable file transfer
No "official" update to 2.2 Froyo however some newly purchased devices have 2.2 pre-loaded
Can update manually using InfoTM Update Wrap tools - USB Link to OTG or Boot Disk on micro SD
No "Recovery", can do a Factory Reset which may or may not work
No ROM Manager support
No Clockwork Recovery Image
No Custom ROM
No CM7 "CyanogenMod" support
Extremely small development community compared to other InfoTM powered tablets
BUSYBOX is installed but some updates can brick the tablet
Support community exists since mid November 2010, several Novice support groups (Facebook page, YAHOO Group)
No "official" Android Market, however can be installed but NO paid applications
No "official" Google Experience except Gmail, however can be installed
No FLASH 10.1 or any other version even with pretty please.
Netfix - can't work/works
WiFi is flaky on some devices, limiting range, unable to scan, causing woes, problem and slowdown.
Battery - wide range of results depending on version, applications, tweaks, WiFi use
Memory - sometimes reported as zero requiring Factory Reset, which may or may not work
eBook reader requires micro SD
Downloads requires micro SD
Some SD cards are not recognized, reported as damaged
mini HDMI works but must follow instructions to initiate communication
Digital Gadgets instructional videos on YouTube, website FAQ
my_Disgo support reported as challenging, Twitter feed, expected update "start of July!"
Design Quality / Durability
No replacement for touch Screen/glass which can be broken by: playing Angry Birds forcefully, sitting on it, repeatedly dropping from fairly low heights onto hard surfaces, or even tripping on the power cord flinging the tablet to the floor/wall.
Mini Tablet Accessory Kit from Digital Gadgets exists that includes screen protectors, silicon cases, stylus and case stand.
Click to expand...
Click to collapse
the source code has been released
including the kernel over at http://www.androidtablets.net/forum/sylvania-tablets/
i have got a disgo 6000 and it is stuck in a boot loop any ideas on how i could kick it out of this, pls??
Choppah, use the three finger salute.
Hold a finger on the screen, keep the menu button pushed in, and hold the power button. Keep all three fingers on until you see text, then remove all fingers and push the menu button once.
You're welcome
vnonvmousx Choppah, use the three finger salute.
Hold a finger on the screen, keep the menu button pushed in, and hold the power button. Keep all three fingers on until you see text, then remove all fingers and push the menu button once.
You're welcome
Click to expand...
Click to collapse
Hi all, know this thread has been quiet from quite a long time but.... I have exactly the same problem as choppah When you switch it on it sticks at the
" Disgo tablet 6000RL
Finger touch
Stylus Free"
Boot screen
I have been given the tablet to try and "fix".... I have tried the 3 finger boot to recovery however i then get "Getting recovery Image" "No recovery image found, try recover from SD."
As you may be aware the usb's on the sides are both HOST apparently the one nearest the HDMI port is the OTG port but when i try and connect it to my pc neither device recognises the other. I read somewhere that you needed to press both the power and menu buttons and i did that to no avail.....
I would love to just get the thing working optimally by installing a Stock ROM, from all my searching i believe that there is no stock for this device but have also found it may be possible to install a sylvania rom. As i have never had this tablet boot up and i have not got any box\instructions, plus there is no serial number on the back only model etc i have no idea which sylvania rom would be safe to install and if this could be done by sdcard at all?
Any and all help/advice welcome
Hi All,
I have managed to get a little further with this.... But only a little. Using Techvendetta's newsd.img i have managed to get to a point where the tablet will load images from the sdcard! Thats about it though. I am still stuck at the inital Disgo screen as i dont know enough about how the boot actually works... i am unsure how i can sort this issue. Is this an actual hardware failure? I suspect not as the recovery appears towork using the newsd.img. At least it appears to write the correct data. I cannot as i have stated beofre get otg working.
If anybody reads this... please help if possible....
So the Galaxy Nexus guys got Wallet working on their phone with just an .Apk. I installed the .apk and it installed but FCed every time I tried to run it with NFC enabled. I was hoping someone more talented than me would be able to make it work for us.
http://forum.xda-developers.com/showthread.php?t=1365360
[APP] Google Wallet (Flash: 1.1-R41v8, APK: 1.1-R41v8) [18/12/2011]
I'm running the taste of ics from and tried side loading the apk today. All I got was a black screen.
i installed the apk and when the app started up i got an error saying my version of android was not supported (2.3.5) and then a second error saying that my device is not supported. Im thinking that maybe if i installed a 2.3.6 rom and then modified my build.prop to fake my device as a sprint nexus s, maybe that would trick the app into working? The rom will need to have nfc enable of course too. Anyone know of a good 2.3.6 rom with nfc?
I'm running TPCv2 with DaG.3 kernel and didn't get any errors when installing it. The app came up and said NFC needed to be enabled and when I did that it FCed. But otherwise it didn't FC or error.
EvilEvo said:
I'm running TPCv2 with DaG.3 kernel and didn't get any errors when installing it. The app came up and said NFC needed to be enabled and when I did that it FCed. But otherwise it didn't FC or error.
Click to expand...
Click to collapse
Same here. Installed fine and asked to enable NFC in settings. Once enabled though, Wallet forced closed. Running Quikwiz 1.0.3
I'm curious if changing build.prop to what the galaxy nexus is would fix the issue.
I would be eternally grateful if a dev were able to get this working for us.
I got the same result. Launched at first to tell me NFC needed to be enabled, but after I enabled it, I got force closes. Running QuickWiz 1.0.3
Its sounds like we are missing some important libraries that are required for wallet to talk to the NFC hardware. I noticed that the process for the nexus includes adding another JAR and APK which look like they add additional NFC functionality. Has anyone tried going thru the install process listed on this thread?
http://forum.xda-developers.com/showthread.php?t=1365360
sclarke27 said:
Its sounds like we are missing some important libraries that are required for wallet to talk to the NFC hardware. I noticed that the process for the nexus includes adding another JAR and APK which look like they add additional NFC functionality. Has anyone tried going thru the install process listed on this thread?
http://forum.xda-developers.com/showthread.php?t=1365360
Click to expand...
Click to collapse
Instructions in that thread basically just say install the .apk. I just tried it again with the same result. With NFC enabled, it FCs when trying to load. When NFC is NOT enabled, it starts up and initializes and then says NFC needs to be turned on. When I do that, it FCs.
right, i was talking specifically about the section below that where it talks about installing NFC extras via a command line.
Has anyone looked in their logs to see if they can find a stack trace after a FC happens? It may give a hint as to what we are missing. I dont get the same errors on my phone so my logs aren't useful.
http://forum.xda-developers.com/showthread.php?t=1282890
XK72 said:
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.
Click to expand...
Click to collapse
I suspect that the reason the ADK does not work on the Skyrocket is because the phones have different NFC chip. According to this post, the Galaxy Nexus has the NXP PN65N which contains an NFC controller as well as an embedded secure element (SmartMX) supporting both JavaCard as well as Mifare technology. The Galaxy S II (of which the Skyrocket is a variant) comes with the PN544 which does not have the embedded secure element. This could explain why NFC can be enabled on the Skyrocket (with a custom ROM) but it would FC the Wallet app. The SE (Secure Element) is needed to securely store transaction info and perform all the card emulation functions. Without it, the GW won't work. The app probably just check to see if a SE is available or not, and finding none, simply FC. Now it is possible to use the SIM as a SE but that would require a different SW.
It appears that folks were able to enable GW on the Nexus S, but I think it also sports the PN65N chip with SE. Can somebody confirm it?
wyt168 said:
I suspect that the reason the ADK does not work on the Skyrocket is because the phones have different NFC chips.
Click to expand...
Click to collapse
I think I have found some support for my speculation. In a thread on Android Developer Google Group, Michael Roland explained the 3 different modes of NFC. In particular, the role of SE in the card emulation mode, supports my view expressed earlier, I've lifted the relevant paragraphs here:
So the card-emulation mode allows the emulation of a contactless smart
card (and not an NFC tag, although the smart card could *possibly* be
used as NFC tag). As applications like credit cards typically have high
security requirements, card emulation is not handled by the NFC device
itself (i.e. the application processor of an NFC-enabled mobile phone).
Instead, the NFC device has a dedicated hardware component (the
so-called Secure Element) that handles all the card emulation. (*)
(*) This is not entirely true, as some NFC controllers (like the
PN544) would theoretically allow the emulation of ISO/IEC
14443-4 contactless smart cards from the application processor.
Yet, I don't know of any NFC phone that makes this functionality
available to the user and I rather doubt that this will become
available on the Nexus S.
The Secure Element (SE) is typically a smart card itself. But instead of
a normal contact/contactless smart card interface it has a connection to
the NFC controller, which connects it to the NFC antenna.
The Nexus S has an integrated SE (a SmartMX combined into the same
package as the PN544 NFC controller). This SmartMX emulates a ISO/IEC
14443 (Type A) smart card and a MIFARE Classic card.
In addition to this integrated SE it is possible to use a special UICC
(also known as SIM card) that supports the Single Wire Protocol (which
is an interface designed for the communication between the NFC controller
and a UICC) as the SE.
Click to expand...
Click to collapse
DELETE
Looks like Google Wallet was just released for AT&T Nexus devices, hopefully Skyrocket isn't too far behind. Officially or otherwise androidcentral . com/google-wallet-now-available-nexus-s-and-galaxy-nexus-att
LoSt180 said:
Looks like Google Wallet was just released for AT&T Nexus devices, hopefully Skyrocket isn't too far behind. Officially or otherwise androidcentral . com/google-wallet-now-available-nexus-s-and-galaxy-nexus-att
Click to expand...
Click to collapse
I tried the newest version from the market and got a secure element error. I don't think we're going to get wallet support any time soon because our devices don't have a secure element.
Would it be possible to edit the build.prop to appear as a Nexus S or Galaxy Nexus GSM now to all it to work? It installed fine on my phone but now says my hardware isn't supported.
EvilEvo said:
Would it be possible to edit the build.prop to appear as a Nexus S or Galaxy Nexus GSM now to all it to work? It installed fine on my phone but now says my hardware isn't supported.
Click to expand...
Click to collapse
No because our phones lack a secure element. Physically lack. So no edits to the app will work until Google decides to update this specifically for phones without a secure element.
Sent from my SAMSUNG-SGH-I727 using Tapatalk
I bought some of the nfc tags from sparkfun and the task launcher app and tasker so I could use the tags to run tasker tasks. you know, swipe when you get home, to work, into the car.
When I swipe one I get a force close on the nfc service.:-(
I tried skyicecream and buoyancy roms. fixed permissions. super clean install of rom. Thoughts?
mcmasterp said:
I bought some of the nfc tags from sparkfun and the task launcher app and tasker so I could use the tags to run tasker tasks. you know, swipe when you get home, to work, into the car.
When I swipe one I get a force close on the nfc service.:-(
I tried skyicecream and buoyancy roms. fixed permissions. super clean install of rom. Thoughts?
Click to expand...
Click to collapse
the Alien ROM supports NFC to a certain extent
Hi XDA guys!
A couple days ago I bought the maylong FD-220 "gps for dummies" gps at CVS pharmacy. The unit was deeply discounted ad I got it for $19.99 I knew it was a junk piece of hardware but I tried to go to the MFR website anyways to look for any map updates. No luck- the maps in the unit are from 2009 and they are NOT updating it- EVER. I guess the whole project completely tanked for them.
Anyways, I wanted new maps, and to eliminate using the ugly "for dummies" interface, so I figured I'd use MioPocket to hack my way in to a proper home screen, and install some windows CE 5.0 compatible gps software with newer maps etc.
I used MioPocket Mini 4.0 R2 and created a bootable sd card using the YFgo2CE.bld file trick to boot and complete the install. I was careful to use the Mini version because I ONLY wanted to do this to get more current maps and I don't care about using the device to do any other tricks whatsoever. Plus, I wanted to use whichever method was least likely to brick the device. I was successful and now I have a bootable sd card that loads MioPocket and the unit boots stock without sd card inserted.
Anyway, my question is this:
I know the unit was a el-cheapo Chinese piece of garbage, that's why it's discontinued now. I don't expect much but maps from 2009 with no updates is unacceptable. Does anyone know of any freeware, or even pay gps navigation programs that will run on windows ce 5.0 from an sd card? I just want newer maps- even if I use another discontinued program that at least had its last release in late 2010 or better etc.
I have done some web searching and have not been able to find a single tutorial or hack video etc which is written specifically for this model number. Just a few comments here and there.
Thanks to anyone who can help
Same problem..
I grabbed one at my CVS as well..
Looking for the same thing!
The user ukdutypaid request me and
LNEt - I don't found the profile yet
Robbie P
qazzi76
sergiocabraljr
With some words:
So can anybody tell me either a) why is BT HID so 'rubbish' on Android, ie why is it so rare that anybody seems to have got it to work e.g "Look. It's a massive problem, nobody really knows how to do it. Count yourself lucky that you've got found a GB build where it does work at all. Put the problem down and walk away"; or b) what a solution might be?
I've tried rooting round in builds, until I'm blue in the face but unless the *.so file either has a BT and or an HID in the file name, then I'm in the dark.
qazzi76 ; GregórioAxiaMagno and sergiocabraljr have found various solutions for GB builds I think and I know Samsung seems to have solved the problem. (I've seen videos of the Galaxy Nexus and it worked with no problems on an SII a friend of mine has).
Could it simply be a case of isolating and extracting the magic HID file and putting it into any/all custom roms, or it's a case (for some just to make it harder reason) that the BT files have to be recompiled for each and every build; as GregórioAxiaMagno has kindly pointed out with some of his work.
The holy grail I suppose is a set of files that can be uploaded to any build by apt, that resolve the lack of BT keyboard with every/any build.
Click to expand...
Click to collapse
:good:
The point here is, as always I say, the bluetooth stack on Android is a issue like call recording. And with this cenario, I think we can join people to help on this thread to post information about mods, replacements, hacking, apps and more. Until we find the optimal solution for the largest number of phones what we can. :fingers-crossed:
All is valid: kernels, modules, CWM, apps, tips, :angel: pray... any way of help.
I will ask for you people to post solutions here, and along of the time I will quote it in the second post of this thread.
Also, I want discuss with you about an optimal solution.
So keep this thread clean and focused only about bluetooth.
No, I and nobody thinks what the bluetooth is the world conquest, I want only use the totally potential of this "old" tecnology.
I know we have other tecnologies like OTG, but this thread must be only about how to deal with bluetooth in our daily use and experiences.
Lets start! :highfive: I have your help?
Please, press thanks instead to manifest your support with posts.
Current solutions
[app][beta][2.1+] myblucon v1.0 & mybluime v1.0 - bluetooth kit to hid devices
so you buy a bluetooth mouse but your ginger won't connect it?
Or you have an bluetooth keyboard and can't write at your ice cream?
Solution for:
* ST15a/i - GB/ICS
* Others
Click to expand...
Click to collapse
Bluetooth Keyboard problem resolved
Infamous "paired but not connected."
Solution for:
* Galaxy Note GT-N7000
Click to expand...
Click to collapse
[APP]Bluetooth Keyboard Easy Connect
A service which connects your bluetooth keyboard device.
Android 2.3 has support for HID devices but is not able to connect bluetooth keyboard devices correctly (yet).
This service automates the connection to your keyboard.
Solution for:
* Many Androids
Click to expand...
Click to collapse
Solving Bluetooth connecting problems
My Desire's bluetooth allways worked like a charme untill rooting REDUX 1,2
Connecting to any previously known device, or any new once for that matter, did not work.
Some grey hairs, upgrading to Redux 2.0 and many tries later I concluded some data must be corrupted somewhere.
Deleting the content, not the files, just the content of the following files did the trick, much to my relief.
Solution for:
* HTC - Redux
Click to expand...
Click to collapse
HID Bluetooth Device FIX for 2.3.5 and 2.3.6!!
Like many of you I was extremely excited to learn that android now supports HID devices and immediately rushed out to purchase a HID-BT Keyboard. Getting home, I fired up the phone and keyboard, entered the 6 digit code to pair them and saw the device connecting and disconnecting in an infinite loop. I was crushed and disappointed.
What went wrong? As stated above this is merely a workaround. But the problem lies somewhere between the kernel and broadcom chipset. This fix will reset your bluetooth pairings. It has been tested on my Samsung Galaxy SII I727 but it should work with any other device.
Solution for:
* Many Androids
Click to expand...
Click to collapse
resv 2
:good::good::good:
Congratz... keep going
Looking here:
/data/misc/bluetoothd/<A BLUETOOTH ADDRES>
I was thinking one of this files have a value to set for make an device manually connectable. Like disabling/enabling auto connect. So the market apps to HID devies will work better.
What do you think?
I was messing into the system and looking at this path
system\etc\bluetooth
Inside, we can found some confs, so I was editing and guessing about input.conf.
So I made some mods and I will test today, but if anyone know something more about or want to test, please a hand will be cool xP.
Regards.
EDIT: yeah nothing changes... haha
On Joying headunits with CAN Bus, it is not possibile to use resistor based USWC: this thread aims to overcome the limitation by using an Arduino MICRO connected to the receiving unit of the USWC and to the headunit via USB to simulate a hardware keyboard.
reserved 1
Github repository: https://github.com/MobeedoM-opensource/android-auto
reserved 2
reserved 3
surfer63 said:
In your code you also use the BOOT_COMPLETED broadcast. You know that with the Joying deep-sleep option, you will see that only on rare occasions? This is: only on reboots or power (dis)connects?
Click to expand...
Click to collapse
Yes i know thank you, i noticed that for some strange reason the firmware deactivates the accessibility service even at reboot (at true boot not only with ACC_OFF).
You use the "com.fyt.boot.ACCON" intent filter in your services. If it doesn't have serious consequences please also add the "com.glsx.boot.ACCON" for those users on Sofia that might want to start using your app as well. But this in turn would also require the "minSdkVersion 23" instead of "minSdkVersion 24" like you have now. My PX5 is on 8 so I have api level 26, but my old Sofia on the bench is on 6.0.1 and it would be handy to test there first. (I tried to build your code, but there are many "hurdles" in your app/build.gradle, so I need to dive a little deeper into it)
Click to expand...
Click to collapse
Yes of course i'll add the intent filter, but please note that the current version of the app doesn't use those intents on api level 26+ (my headunit), because of the background execution limits (the implicit intent is simply not received).
The only intent that i was able to trap, but i still need to investigate because it doesn't always work and I haven't figured out why yet, is the android.hardware.usb.action.USB_DEVICE_ATTACHED.
For the build.gradle, if you tell me what are the hurdles maybe i can help, also via PM if you prefere.
You have the method startAccessibilityService with the rooted system call: What does that actually do? Is it for the user to give access? Or the system to give access (as it is rooted)? Is it for the root_preference "OnlyBroadcast"?
Click to expand...
Click to collapse
An accessibility service cannot be started programmatically in android, the user must manually activate it with the switch in the accessibility services section.
That command is used to simulate the behavior of the user who changes the state of the switch, it requires root and it is not granted to work on all roms.
You use the "getCurrentForegroundPackage()". I guess this still works if your have (for example) your navi app in the foreground and your media player in the background and you want to skip to the NEXT, as you automatically come to the last "if" statement in your MediaKeysMapper. But does this also work when your navi app is the foreground program and you are listening to the radio or some "generic_syu" program in the background?
Click to expand...
Click to collapse
Yes you are right, the last use case is not covered. To manage it correctly you need to know which app is currently playing, maybe it is possbile to distinguish syu apps by non syu apps by checking the android AudioManager which i think is only used by non-syu apps.
bambapin said:
Yes of course i'll add the intent filter, but please note that the current version of the app doesn't use those intents on api level 26+ (my headunit), because of the background execution limits (the implicit intent is simply not received).
The only intent that i was able to trap, but i still need to investigate because it doesn't always work and I haven't figured out why yet, is the android.hardware.usb.action.USB_DEVICE_ATTACHED.
For the build.gradle, if you tell me what are the hurdles maybe i can help, also via PM if you prefer.
Click to expand...
Click to collapse
I know about the implicit intents, but on a Sofia on Android 6.0.1 (api level 23) they should still work.
W.r.t. the build.gradle.
I had to remove the private.gradle import statement, some signing statements, defProd and the like, and finally (also literally in time) upgrade my sdk from 27 to 29 to be able to do a simple "./gradlew assembleDebug".
So no issues anymore.
(Of course I had set compile version to 27 in the build.gradle, but I ran into "missing" xmls, which I first blamed on being not committed to the repo (your fault, not mine of course ), but which turned out to be part of sdk 28 and up, so still my fault ).
surfer63 said:
W.r.t. the build.gradle.
I had to remove the private.gradle import statement, some signing statements, defProd and the like, and finally (also literally in time) upgrade my sdk from 27 to 29 to be able to do a simple "./gradlew assembleDebug".
Click to expand...
Click to collapse
Ah yes, the private.gradle... it contains my private keys passwords so i preferred not to publish them on the internet .
Indeed that file must be placed next to the app build.gradle with this content:
Code:
ext {
my_keyAlias = 'YOUR_KEY_ALIAS'
my_keyPassword = 'YOUR_KEY_PASSWORD'
my_storeFileName = 'YOUR_KEYSTORE_FILEPATH'
my_storePassword = 'YOUR_KEYSTORE_PASSWORD'
}
bambapin said:
Yes you are right, the last use case is not covered. To manage it correctly you need to know which app is currently playing, maybe it is possbile to distinguish syu apps by non syu apps by checking the android AudioManager which i think is only used by non-syu apps.
Click to expand...
Click to collapse
Maybe I insult you with providing this link , but anyway: here it is: https://developer.android.com/guide/topics/media-apps/mediabuttons
And the image in post #1. How is red and black connected, and to what?
surfer63 said:
Maybe I insult you with providing this link , but anyway: here it is: https://developer.android.com/guide/topics/media-apps/mediabuttons
And the image in post #1. How is red and black connected, and to what?
Click to expand...
Click to collapse
No insults at all don't worry and even if it were i hardly get offended
Actually i'm not expert on this particular topic, at the beginning i tried to use the standard Android MediaControllers but it seemed to me that when it came to "syu" APPS everything was bypassed, but if you think it's a viable way i'll try again.
The photo is the final version that is now installed in the car.
I noticed that there was enough room inside the SWC receiver to insert the arduino, i made a little hole for the usb socket and i connected the arduino directly (yes i admit, i soldered to save the space of dupont ).
What you see is the inside of the receiver + the arduino. The black and red cables are the power supply of the receiver, the orange and blue are KEY1 and KEY2 (the white and gray of the video). The arduino is simply glued with a removable glue (patafix).
@surfer63 i was thinking again about the autostart after the ACCON.
In the end i managed to make the intent android.hardware.usb.action.USB_DEVICE_ATTACHED always work so the accessibility service is always restarted, but i'm still looking for a better alternative (using the navi app would work but it interfere with the audio mixing level).
I looked again at the code of syu.ms and saw that when the unit wakes up, a series of apps are always launched with hard-coded package names: eg. "com.yh.devicehelper" and "com.cpsdna.mirror" which i don't seem to find installed in the headunit.
Do you have any idea what they are?
If they are never installed, perhaps it is enough to create an app with one of those package names and the system will take care of starting it at ACCON.
bambapin said:
No insults at all don't worry and even if it were i hardly get offended
Actually i'm not expert on this particular topic, at the beginning i tried to use the standard Android MediaControllers but it seemed to me that when it came to "syu" APPS everything was bypassed, but if you think it's a viable way i'll try again.
The photo is the final version that is now installed in the car.
I noticed that there was enough room inside the SWC receiver to insert the arduino, i made a little hole for the usb socket and i connected the arduino directly (yes i admit, i soldered to save the space of dupont ).
What you see is the inside of the receiver + the arduino. The black and red cables are the power supply of the receiver, the orange and blue are KEY1 and KEY2 (the white and gray of the video). The arduino is simply glued with a removable glue (patafix).
Click to expand...
Click to collapse
I do indeed think that the SYU apps do nothing according standard Android rules, so the MediaController would only be helpful for any other app. I do think you need to check if "some" SYU app is active by using something like "this" or by checking the com.syu.ms apk (via jadx(-gui)) or so, because that one also checks on several places whether one of its own SYU app is active or not, and on top or not.
So the bottom side of of the plate with the red led and condensator (or so), is the bottom of the SWC controller circuit?? If so, the image now makes sense.
surfer63 said:
So the bottom side of of the plate with the red led and condensator (or so), is the bottom of the SWC controller circuit?? If so, the image now makes sense.
Click to expand...
Click to collapse
Yes, it is the bottom, when it is inserted it rests on the 4 pillars and leaves enough space below, there will be almost 1cm from the arduino.
The only negative thing i noticed is that with the arduino so close to the antenna the reception distance of the buttons is a little lower than before, but they still work.
bambapin said:
@surfer63 i was thinking again about the autostart after the ACCON.
In the end i managed to make the intent android.hardware.usb.action.USB_DEVICE_ATTACHED always work so the accessibility service is always restarted, but i'm still looking for a better alternative (using the navi app would work but it interfere with the audio mixing level).
I looked again at the code of syu.ms and saw that when the unit wakes up, a series of apps are always launched with hard-coded package names: eg. "com.yh.devicehelper" and "com.cpsdna.mirror" which i don't seem to find installed in the headunit.
Do you have any idea what they are?
If they are never installed, perhaps it is enough to create an app with one of those package names and the system will take care of starting it at ACCON.
Click to expand...
Click to collapse
It worked!!! :laugh:
The app attached is automatically launched by the syu.ms at ACC_ON.
I used the package name "com.cpsdna.mirror", i have no idea what the original app was supposed to do, but now we have a real autorunner at our disposal.
bambapin said:
It worked!!! :laugh:
The app attached is automatically launched by the syu.ms at ACC_ON.
I used the package name "com.cpsdna.mirror", i have no idea what the original app was supposed to do, but now we have a real autorunner at our disposal.
Click to expand...
Click to collapse
:good: Very nice.
There are many apps in this ms.apk that no longer exist. Some are hardcoded called inside the app, some are called via the text files in the assets/property, but no longer exist.
I assume it is related to http://www.cpsdna.com/solutions1.html and a previous "mirrorlink" application. zlink is now by another company.
What I would do (and did in the past) is making a "micro starter app" (11~16Kb) , that only starts the app you want. So the "com.cpsdna.mirror" started by ACC_ON, starts your "com.mobeedom.android.auto.jyhuremote".
If Joying/FYT updates their list of started apps, you can simply take another "old" app and still call your own app without having to rewrite all the packages inside your own code.
(And please don't use the appcompat for such a microstarter . It explodes your code from ~11-16Kb to 1.5MB. I really hate how Studio always adds that to your project even if you target APIs that don't need it, or your app as such doesn't need it)
It would only need something like:
Code:
PackageManager pManager = context.getPackageManager();
Intent intent = pManager.getLaunchIntentForPackage("com.mobeedom.android.auto.jyhuremote");
if (intent != null) {
context.startActivity(intent);
}
surfer63 said:
:good: Very nice.
There are many apps in this ms.apk that no longer exist. Some are hardcoded called inside the app, some are called via the text files in the assets/property, but no longer exist.
I assume it is related to http://www.cpsdna.com/solutions1.html and a previous "mirrorlink" application. zlink is now by another company.
What I would do (and did in the past) is making a "micro starter app" (11~16Kb) , that only starts the app you want. So the "com.cpsdna.mirror" started by ACC_ON, starts your "com.mobeedom.android.auto.jyhuremote".
If Joying/FYT updates their list of started apps, you can simply take another "old" app and still call your own app without having to rewrite all the packages inside your own code.
(And please don't use the appcompat for such a microstarter . It explodes your code from ~11-16Kb to 1.5MB. I really hate how Studio always adds that to your project even if you target APIs that don't need it, or your app as such doesn't need it)
It would only need something like:
Code:
PackageManager pManager = context.getPackageManager();
Intent intent = pManager.getLaunchIntentForPackage("com.mobeedom.android.auto.jyhuremote");
if (intent != null) {
context.startActivity(intent);
}
Click to expand...
Click to collapse
Ok ok, no AppCompat
Maybe i could also put a minimum of parameterization with the ability to choose what to launch, maybe even more than one app.
Do you think something like this could be useful in your JET?
bambapin said:
Ok ok, no AppCompat
Maybe i could also put a minimum of parameterization with the ability to choose what to launch, maybe even more than one app.
Do you think something like this could be useful in your JET?
Click to expand...
Click to collapse
I don't see it yet. What would be useful to start from my Jet apk? Can you explain?
Please also note that when I started the JET apk I knew absolutely nothing about java (and didn't want to know anything about java) and started in appinventor/thunkable, as that was easy enough. But it is a big mess of all kind of shell scripts called from my app using the "rootexec" plugin, because that was the only way to make it work.
If I would start again I would rewrite it immediately in java.
So perhaps your own app would be a much better basis than my JET apk.
Please don't think I'm against it, but I do not understand (yet?) why that would be useful.
surfer63 said:
I don't see it yet. What would be useful to start from my Jet apk? Can you explain?
Please also note that when I started the JET apk I knew absolutely nothing about java (and didn't want to know anything about java) and started in appinventor/thunkable, as that was easy enough. But it is a big mess of all kind of shell scripts called from my app using the "rootexec" plugin, because that was the only way to make it work.
If I would start again I would rewrite it immediately in java.
So perhaps your own app would be a much better basis than my JET apk.
Please don't think I'm against it, but I do not understand (yet?) why that would be useful.
Click to expand...
Click to collapse
Don't know, i thought of your JET because i see it as a great collection of tools dedicated to Joying head units.
Given that on android 8 the intents ACC_ON and ACC_OFF are not usable, it could be an additional tool that allows you to schedule actions to be performed on wakeup without without the need to set Tasker as an NAVI app and without Xposed, since it still doesn't work on SC9853i.
BTW about Xposed i am also afraid, but i really hope i'm wrong, that with the code obfuscation of the firmwware, the maintenance of the Xposed modules will become increasingly difficult.
However, i will make a mini app with a list of apps to launch at ACC_ON (in my case the Accessibility Service, Poweramp and the NAVI), the code will be available if you change your mind .
bambapin said:
Given that on android 8 the intents ACC_ON and ACC_OFF are not usable, ...
Click to expand...
Click to collapse
Based on your work on USB, I also started to work on that idea again and built a "UsbReceiver" in my FytHWOneKey. It works great on my old sofia (6.0.1), but the usb event (""android.hardware.usb.action.USB_DEVICE_ATTACHED"") is never triggered on my 8.0.0 PX5. It doesn't work there.
Does this USB still work for you on 8.1.0?
bambapin said:
BTW about Xposed i am also afraid, but i really hope i'm wrong, that with the code obfuscation of the firmwware, the maintenance of the Xposed modules will become increasingly difficult.
However, i will make a mini app with a list of apps to launch at ACC_ON (in my case the Accessibility Service, Poweramp and the NAVI), the code will be available if you change your mind .
Click to expand...
Click to collapse
Xposed will no longer be feasible indeed when you look at the code obfuscation.
Your list of apps to be started: An internal list or external list (ascii config/ini file?), or preferences list?
surfer63 said:
Based on your work on USB, I also started to work on that idea again and built a "UsbReceiver" in my FytHWOneKey. It works great on my old sofia (6.0.1), but the usb event (""android.hardware.usb.action.USB_DEVICE_ATTACHED"") is never triggered on my 8.0.0 PX5. It doesn't work there.
Does this USB still work for you on 8.1.0?
Click to expand...
Click to collapse
Yes, it's the intent i'm still using to re-activate the accessibility service. It seems strange to me that it is not triggered at all, do you have any other app installed that could "steal" it? Torque for example?
EDIT: did you fetch the last version from github? i added a .xml with the filtered devices, it could be required (it depends on the firmware implementation)
Xposed will no longer be feasible indeed when you look at the code obfuscation.
Your list of apps to be started: An internal list or external list (ascii config/ini file?), or preferences list?
Click to expand...
Click to collapse
Internal, stored in the shared preferences.
bambapin said:
Yes, it's the intent i'm still using to re-activate the accessibility service. It seems strange to me that it is not triggered at all, do you have any other app installed that could "steal" it? Torque for example?
EDIT: did you fetch the last version from github? i added a .xml with the filtered devices, it could be required (it depends on the firmware implementation)
Click to expand...
Click to collapse
No other apps, only my own FytHWOneKey.
I did see the xml, but did not understand it and wanted to ask later. Those vendor id's / product id's: Are those from your usb devices or are they from (internal) Joying devices?
I can only find one vendor-id in the USB device database.