Related
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,
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.
It was bound to happen, so here it is. The Grouper running Android 6.0!
What works:
- WiFi
- display
- audio
- Bluetooth (partially)
- Multiwindow
- Auto-rotate
What's broken:
- OTG
- surfaceflinger*
What's untested:
- camera
- NFC
I will not offer a ROM zip at this point due to the fact that the rootfs is inherently insecure for the time being. However, the sources are available below and should be bootable.
Sources:
http://github.com/Grouper-aosp
CREDITS:
@dolorespark - ramdisk fixes, sepolicy fix (3.1 compatible)
@Ziyan - kernel work and device tree
@GtrCraft - device tree help, testing and support
I highly encourage the use of the stock 3.1 kernel. I've modified sepolicy to allow old kernels to run.
Wow ☺
what does it mean, broken surfaceflinger*?
Thanks dude! Will try to flash when rom is linked and when I can access my Nexus 7!
TheXorg said:
what does it mean, broken surfaceflinger*?
Click to expand...
Click to collapse
For some reason, surfaceflinger isn't looking in the /system for the GPU binaries. To bypass this I had to symlink them to the rootfs.
Wow. Though, it would be great if anyone -- or the OP -- could cook the ROM and share the link. Looks good enough.
itskapil said:
Wow. Though, it would be great if anyone -- or the OP -- could cook the ROM and share the link. Looks good enough.
Click to expand...
Click to collapse
A link will be posted as soon as we fix Surfaceflinger and a couple bugs in the 3.4 kernel.
@Motorhead1991 thanks a lot for the heads up! Waiting patiently.. pls tag once it's up. :good:
Having done this already, let me add:
most likely also you have gps broken, and nfc broken
i am guessing selinux is also not doing all it should
also the issue is not with surfaceflinger (that is just the symptom)
I was hoping someone could port 6.0 to this device. Waiting for the OP to show ready to rock and roll !
@Motorhead1991 awesome work @dmitrygr saw a reddit post where you said you are working on nexus 7.... patiently waiting for it after trying your nexus 4 build
2012katas said:
@Motorhead1991 awesome work @dmitrygr saw a reddit post where you said you are working on nexus 7.... patiently waiting for it after trying your nexus 4 build
Click to expand...
Click to collapse
Other way around, friend . @dmitrygr did the N4. I started on the N7 (2012) myself and received assistance from him and others .
Excellent work! I'll be watching this with interest.
Thanks! I'm waiting for your release
Camera, NFC and OTG is not important for me right now.
dmitrygr said:
Having done this already, let me add:
most likely also you have gps broken, and nfc broken
i am guessing selinux is also not doing all it should
also the issue is not with surfaceflinger (that is just the symptom)
Click to expand...
Click to collapse
For NFC, we need to revert this commit - adding it to the device tree is way too problematic, and this shouldn't cause problems for other devices anyways....
For SELinux on 3.1, we need these commits, and we need to remove three recovery-related neverallowed rules from the device tree (not a huge deal really) - these commits are already included in my 3.4 kernel (thanks to the android-3.4 merge), but it's not ready to be shipped... posting a screenshot of M running with 3.4 was a mistake.
For EGL, I use this workaround, which fixes that particular problem without modifying the system libraries - it would be really nice if you knew another, nicer solution, also without modifying the system libraries
Right now, GPS, camera and audio is broken (thought audio might be broken because of camera - I experienced similar symptoms while working on 3.4).
dmitrygr said:
Having done this already, let me add:
most likely also you have gps broken, and nfc broken
i am guessing selinux is also not doing all it should
also the issue is not with surfaceflinger (that is just the symptom)
Click to expand...
Click to collapse
The NFC propably needs the NXP NFC stack which had been dsiabled building by google and can be reverted: https://gerrit.omnirom.org/#/c/14956/
My Optimus G needed relocations for the nfc hardware lib, but I think it might be not needed, anyway this is hacky change to make relocations warnings again: https://gerrit.omnirom.org/#/c/14955/
Ziyan said:
For NFC, we need to revert this commit - adding it to the device tree is way too problematic, and this shouldn't cause problems for other devices anyways....
For SELinux on 3.1, we need these commits, and we need to remove three recovery-related neverallowed rules from the device tree (not a huge deal really) - these commits are already included in my 3.4 kernel (thanks to the android-3.4 merge), but it's not ready to be shipped... posting a screenshot of M running with 3.4 was a mistake.
For EGL, I use this workaround, which fixes that particular problem without modifying the system libraries - it would be really nice if you knew another, nicer solution, also without modifying the system libraries
Right now, GPS, camera and audio is broken (thought audio might be broken because of camera - I experienced similar symptoms while working on 3.4).
Click to expand...
Click to collapse
In hindsight, yeah showcasing 3.4 was jumping the gun a little bit. I just got ahead of myself and wanted to bring hope to people that still use such an "old" device.
Update: I was able to fix gps in a similar way. Also, it seems like 3.1 + M isn't going to play together (serious memory management issues), so I had to switch back to 3.4 (me and @sheffzor are working on 3.4 day and night). So, only camera and audio remains
Sweet! @Ziyan, @sheffzor and all the other devs for the win!
Hi,
I am back with one of my builds. Again this is just result of my hobby, feel free to use it, but do it on your own risk. Also any updates will be probably sporadic.
I wanted to publish my build as quickly as possible, becasuse I promised in another thread. So I simply took, what I have (and I am using right now). As a result there some detail I`d like to change for public release like this for the future (e.g. all the special feature enabled by default, the big dmesg buffer). Be careful. I`ll try to do better version as soon as possible. I don`t recomend this for begginers. Be sure you have backup.
This build is based on the official LineageOS code and contains several of my changes. In some cases it could be considered as fix, improvement, but sometimes a hack or even even security risk, so please read carefully following list. All the changes I did because I wanted the system on my device behave that way (at least time to time). Take it or leave it. Please note, that all the features are enabled by default. Be careful.
- built-in root support
- RIL is based on stock KitKat version (works better for me than the official version)
- the sensors libraries are also from stock KitKat (same reason as above )
- barometer sensor is correctly recognized by the system
- the menu button does, what it always did
- notification led brightness can be configured by user
- entering safe mode by holding specific keys during boot can be disabled by setprop persist.safe_mode_disabled true (this has always only annoyed me, but be sure you know you are doing)
- device wakeup by power button can be disabled when proximity and light sensors are blocked (e.g. in a pocket). Execute setprop persist.pwrbtn_proximity_block true
- external sdcard can be made world writeable by setprop persist.world_writable_sdcard true (be careful with this one, this opens a security risk)
- the notification led can blink when the battery is fully charged - enable by setprop persist.blink_when_charged true
- F2FS support
- the notification icons are also on the lock-screen as they ware in
previous Android versions. The carrier name is moved above the clock
(this cannot be turned off)
- the dmesg buffer size is increased to 16M. I set this for debugging
and remove it in next published build.
- ramdisk LZMA compression support
- sdcardfs support - This is faster replacemnt for the FUSE filesystem. I backported this for higher kernel version. Although I`ve been using this for several months without any problem, please consider this experimental. Enable with setprop persist.sys.sdcardfs
force_on
- mount directories for sdcard are protected against writing while the sdcard is not mounted (this solves a race condition problem which allows some apps to create files in there)
- there some other small changes related to my multiboot envrionment, czech translation, carrier name, etc.
Source code
In the installation zip there is a directory code_info with following content:
roomservice.xml - roomservice.xml for the build
commits - list of git repositories and commits used for the build
patches - directory tree with structure reflecting the source and containing
patches for individual projects. The idea (not always followed) is that one patch is one feature,if possible.
code1.diff - all the patches from patches directory together
code2.diff - changes which are not in patches directory
diff-commits.txt - obsolete, I`ll remove this one in the future or maybe use
it again
The only bug I know about is occasional crash of MTP, but I didn`t notice any negative consequences. There may some problem with battery charging (the display turns on time to time without no obvious reason during charging), but it may be some hardware error (bad cable or charger).
Since this is based on official LineageOS, thanks to everyone who contributed to it.
I am using this build for over a week without any problem, except those mentioned above.
Continue here, for the latest build.
UPDATE:
I totally forget about this yesterday - here are the proprietary files I used for this build proprietary-files-ocm13-skk-ril.tgz It is a mixture from the CM 13 official build and KitKat stock files, with modified ks file (then connect symbol is replaced with xonnect, so it doesn`t crash), maybe some other files and changes. I really don`t remember, I put this together during a long period of time. If you find any of your work inside, please accept my apologies and let me know. From my point of view it just works. If you want to apply the patches, then you will most probably want to change the hardcoded full path to these files in device/samsung/i9305/extract-files.sh.
UPDATE:
If you want to use anything from my patches, feel free to do so, just follow the license of the original project.
I tested it for about 4 hours for modem stability, taking the logs. All SAHARA transfers were ok, with no errors and retries. I should have mentioned your name in some post earlier
gongrats and many thanks @p.a.n. Your rom runs very well, its awesome. :good:
Do you mind, if I take your sources or parts of it or some files from your rom.zip for my builds? If I do so, I will mention you and what I took and give you credits.
rodman01 said:
gongrats and many thanks @p.a.n. Your rom runs very well, its awesome. :good:
Do you mind, if I take your sources or parts of it or some files from your rom.zip for my builds? If I do so, I will mention you and what I took and give you credits.
Click to expand...
Click to collapse
Thanks Use whatever you want from it just follow the license of the original project (I updated OP with similar note).
Help??? How to fix gps on this Rom plzz
Great work p.a.n.
Using for 24 hours no problems yet and seems very smooth.
Used it for a few hours with the built-in kernel then switched to Boeffla to get Boeffla Sound etc.
Very nice to have the customisable LED again as it was missing from the official LineageOS.
More importantly for me, the magnetic compass seems to work properly. I couldn't get it to work on official, nor on Rodman's RR.
No issues with GPS for me.
I had to install 'The SELinux Toggler' to set permissive so I could get Viper4Android to work (as with official) but I expected that.
One other thing, the MTP crash is the 'MTP host' app. I just disable this as it's only needed if you need your phone to be an MTP host for something like a digital camera, which I don't. It doesn't affect connections to your PC.
Is there an issue with the automatic execution of init.d scripts? I'm on Boeffla so it may just be that. Luckily you can tell Boeffla app to execute them anyway.
@Glenn2, thanks for testing I am not completely sure about it, but if I remember well, the compass problem is caused by the opensource sensor library (I think that just replacing the/system/lib/hw/sensors.smdk4x12.so with the one from my build should fix that). But the problem is not actually with the compass sensor, that one is ok, but in the opensource version there are missing some "fake" sensors, which provide calculated data based other "real" sensors. One of them provides orientation information, often used in apps as compass. Try some app (e.g. Androsens2) which lists all the sensors and you`ll see the difference - the "fake" ones have iNemo in their name.
I actually don`t care about the MTP crashes. It mostly happens after uninstalling some app, which doesn`t happen too often and otherwise I haven`t noticed any negative related to that. It is just annoying popup for me.
What do you mean by the question about init.d scripts?
p.a.n said:
What do you mean by the question about init.d scripts?
Click to expand...
Click to collapse
I have a couple of scripts and they were not running on boot. I don't know if Boeffla kernel affects busybox. I remedied this by telling the Boeffla Config app to run init.d scripts when it launches.
Also, I had a power manager service wakelock that kept my phone awake for hours, only a reboot cleared it. I had this happen a couple of times on official LineageOS too. Not the famous mdm_hsic_pm0 which now seems to be cured at long last! I had a period of no signal when I was on the London Underground, maybe that was the cause.
Glenn2 said:
I have a couple of scripts and they were not running on boot. I don't know if Boeffla kernel affects busybox. I remedied this by telling the Boeffla Config app to run init.d scripts when it launches.
Click to expand...
Click to collapse
There is /system/etc/init.d/* scripts, which run OK, or at least /system/etc/init.d/00banner does. There is also /system/etc/init.d/90userinit, which executes /data/local/userinit.sh. I remember that seme previous CM version there was also a user defined init.d somewhere in /data. This may what has changed, but I am not if this is your case.
Glenn2 said:
Also, I had a power manager service wakelock that kept my phone awake for hours, only a reboot cleared it.
Click to expand...
Click to collapse
This on is also often on the top of my kernel wakelock list, but never that bad, always with reasonable times.
Glenn2 said:
Not the famous mdm_hsic_pm0 which now seems to be cured at long last!
Click to expand...
Click to collapse
Yes, the solution has been sitting in the Samsung kernel source for a long time ...
Glenn2 said:
Great work p.a.n.
Using for 24 hours no problems yet and seems very smooth.
Used it for a few hours with the built-in kernel then switched to Boeffla to get Boeffla Sound etc.
Very nice to have the customisable LED again as it was missing from the official LineageOS.
More importantly for me, the magnetic compass seems to work properly. I couldn't get it to work on official, nor on Rodman's RR.
No issues with GPS for me.
I had to install 'The SELinux Toggler' to set permissive so I could get Viper4Android to work (as with official) but I expected that.
Click to expand...
Click to collapse
Do you install the last rom ??? Or not
It is worth pointing out that after backing and restoring between roms, the SELinux attributes for efs files can become not correct. That can lead to something like this :
Code:
06-28 04:17:43.705 3799 3799 W ks : type=1400 audit(0.0:30): avc: denied { read } for name="efs1.bin" dev=mmcblk0p11 ino=8200 scontext=u:r:qcks:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
Code:
06-28 04:17:43.712 3799 3799 E kickstart: Requested ID 16, file "/tombstones/qcks/efs1.bin"
06-28 04:17:43.712 3799 3799 E kickstart: ERROR: function: open_file:80 Unable to open input file /tombstones/qcks/efs1.bin. Error 13: Permission denied
It results in not working RIL because of enforced SELinux. Running restorecon fixes the problem.
moad gastro said:
Do you install the last rom ??? Or not
Click to expand...
Click to collapse
I don't know what your question means, as there is only one ROM. I installed from the link in the OP (dated the same date as the OP).
Still using this ROM, and still very few problems.
The day before yesterday it crashed with the screen off. Had to hold power button in to restart.
And yesterday the damn wakelock. It got stuck at a time when I had no signal, and also I used the camera, so either may be relevant. It didn't seem to cause any drastic battery drain though (see images attached). I suppose when the CPU is awake but only at 200MHz and not doing much it uses little more than when it is sleeping?
Regarding init.d scripts. I added one to /system/etc/init.d that simply writes a file to /data when it runs, to test that it DID run. Script starts #!/system/bin/sh
Results:
1) rom with its own kernel - didn't run
2) rom with Boeffla kernel - didn't run
3) rom with Boeffla kernel and Boeffla Config app set to execute init.d scripts itself - did run
One more, just for fun!
Two days ago I was at the Wimbledon tennis, and the location service and/or weather widget decided I was in Boulogne-Billancourt (Paris) instead! I then opened and closed Maps, refreshed the widget and it changed to the correct location!
..
Hi,
I'm trying to install the current build using TWRP 3.0.2-1, but it gets stuck at the "Patching system image unconditionally..." step with the progressbar at around 40%. It's been sitting there for about 10 minutes. Does anyone know how that'd be fixable?`
Cheers
Latest build is ok for me. I've flashed it using TWRP 3.1.0 build from rgib
https://drive.google.com/drive/folders/0B7pwslEEF0l4Yzk2Nm1jOGRDQVU
I am using NFC Tools to try and read and write some tags that I had previously used successfully with my old Xiaomi Mi5s. My old phone reads the tags immediately but the X3 is really struggling and takes repeated attempts to get it to read. So far, I have not been able to write at all. I was just wondering if this is common or just me?
Which ROM are you using? Could you provide more information about your device and what is running on it?