Database Info

[APP][1.6+] PDroid - the better privacy protection app - will you use it?

Hi,
I have recently developed a privacy protection application for Android.
You can use it to block access for any installed application to the following data separately:
Device ID (IMEI/MEID/ESN)
Subscriber ID (IMSI)
SIM serial (ICCID)
Phone and mailbox number
Incoming call number
Outgoing call number
GPS location
Network location
List of accounts (including your google e-mail address)
Account auth tokens
Contacts
Call logs
Calendar
SMS
MMS
Browser bookmarks and history
System logs
SIM info (operator, country)
Network info (operator, country)
For device ID, phone and mailbox number, SIM serial, subscriber ID and device location it also allows supplying custom or random values.
Unlike others (e.g., Permissions Denied or CM) this does not make applications crash when access to private data is blocked.
The following short video shows some of its functionality.
PDroid does not require ROOT or any Android permission to function, nor does it need any services running in the background. But it does require patching some ROM components, so that it needs to be ported to different devices. Currently it is available for Nexus One, Nexus S, Desire HD (Gingerbread) as well as Magic with CM 6.1 (Froyo).
So I am wondering if I should release it for public use and maybe port to other devices. I will only do so if you would like to use it, since it requires some fine-tuning to be more user-friendly. So please vote if you would like to use PDroid.

I would love to use this app on my galaxy s and tab.
Especially the point to give the apps random or custom information instead of just blocking the access is important.
If you need help testing the app on those mentioned devices just let me know
I hope you get enough positive feedback to port and continue developing this app.

I ll love to have such an app on my Xperia X10 mini pro (cyanogenmod 7)

so basicly it's a LBE replacement? The major disadvantage of that one is being closed-source. Do you plan to open-source yours?

I would like to give this app a shot too with my devices (Nexus S 4G, EVO 3D and Epic Touch 4G). Does not require root, but assume that root is ok? Also seen that you have for Nexus S, but was not sure if that implies to the NS4G as well. Looks promising.

XlAfbk said:
so basicly it's a LBE replacement?
Click to expand...
Click to collapse
Kind of. The functionality is similar to that of LBE while I tried to account for its disadvantages, such as not being able to disallow access to some data (e.g., system logs, incoming and outgoing call numbers etc.), requiring root or being unreliable since LBE requires its protection service to be running so that malicious apps still can steal data if they are started before LBE after boot.
XlAfbk said:
The major disadvantage of that one is being closed-source. Do you plan to open-source yours?
Click to expand...
Click to collapse
Most likely yes (depends on how much spare time I can allocale to this project).

Tahde said:
Does not require root, but assume that root is ok?
Click to expand...
Click to collapse
Yes, it won't interfere
Tahde said:
Also seen that you have for Nexus S, but was not sure if that implies to the NS4G as well.
Click to expand...
Click to collapse
Yes, basically any device, for which Android can be directly built from AOSP (and this includes Nexus 4G) is supported right now.

Love to see it for the T-Mobile G2x especially if it is open.

svyat said:
You can use it to block access for any installed application to the following data separately...
Click to expand...
Click to collapse
That's a nice list. I'd really like a version for my Motorola Defy.
How hard would it be to reuse the code to make it run like LBE, i.e. make an apk that works on every phone without having to patch ROMs for every type of device?

I too would like to use this app, sounds awesome. If you need any beta testers, I volunteer

rogier666 said:
How hard would it be to reuse the code to make it run like LBE, i.e. make an apk that works on every phone without having to patch ROMs for every type of device?
Click to expand...
Click to collapse
Impossible, since the actual application logic performing the data access control is based on the Android application framework and not the SDK. Plus, doing it the LBE way requires root and will never be 100% reliable. In other words, there is no way of creating a proper solution without patching the ROM.

I would like to have this for t-mobile US Vibrant since we're getting no Gingerbread love from t-mo or Sammy and I'm all flashed out with nothing else to do.

I would like to give your app a spin to see how it works

KB0SDQ said:
I would like to give your app a spin to see how it works
Click to expand...
Click to collapse
I am also interested in this app... Sounds very promising and I hope this will get ported for the G2/DesireZ, so I can get some freakin' privacy!
If I can help in any way, any way at all, I'd be very happy to do so.. I'm running CM7.1.0 on my DesireZ @ 1.2ghz...
Thanks a lot!

Looks great. I'd love to get that on my Thunderbolt (CM7) would there be anyway to block permissions like internet and SD card access, I know Cyanogenmod lets you disable them but you have to reset your phone after a change for them to take effect. Also I don't know if it falls into the scope of what this project is intended for but I've seen people ask about making certain apps work on 3G that only work on wifi or the other way around if you could make an app think it was using one or the other for a connection I think that would be very helpful to some folks.

I'd test this on the t-mo Galaxy S2 if you're willing to do it...
Sent from my SGH-T989 using xda premium

I guess this is TISSA (http://www.csc.ncsu.edu/faculty/jiang/pubs/TRUST11.pdf) ?
I would like to see for Desire , Great to have this kind of app! I'll help which ever way

IvanNCase said:
would there be anyway to block permissions like internet and SD card access
Click to expand...
Click to collapse
Not in near future. Doing that would require modifying the kernel and that, in turn, would make PDroid much less portable.
IvanNCase said:
Also I don't know if it falls into the scope of what this project is intended for but I've seen people ask about making certain apps work on 3G that only work on wifi or the other way around [...]
Click to expand...
Click to collapse
Nope, it doesn't
ukanth said:
I guess this is TISSA (http://www.csc.ncsu.edu/faculty/jiang/pubs/TRUST11.pdf) ?
Click to expand...
Click to collapse
Nope, I've developed PDroid completely from scratch as a part of my Master's Thesis.

svyat said:
Not in near future. Doing that would require modifying the kernel and that, in turn, would make PDroid much less portable.
Nope, it doesn't
.
Click to expand...
Click to collapse
Fair enough.
By the way how do you install this does the ROM patching need to be done by the original creator or done with a zip file through recovery?

svyat said:
Nope, I've developed PDroid completely from scratch as a part of my Master's Thesis.
Click to expand...
Click to collapse
That's great to hear. Good job done ! I can't wait to see you release. I'll surely try to port it for Desire

[Q] NFC Card Emulation on ICS 4.0.3

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.

Hooking into S-Pen Sensor to Change Keyboard

Lenny and I were talking and sorta had the same idea independently, in that it would be nice to be able to use one keyboard "normally", and another when the S-Pen is in use (ie. removed).
Here's my thinking...
1) Hook into the framework via Xposed Framework such that when the S-Pen is removed, we store the current default keyboard.
2) Change the current default keyboard for the alternative keyboard (ie. the one for use when S-Pen is removed from phone)
3) When S-Pen is replaced into the device, the reverse is done - we backup the "S-Pen" keyboard, and restore the previous default.
This way, the user doesn't actually need to program it with their choice of keyboard - instead, it will simply learn what they use
Problems I anticipate:
Root access needed to change default keyboard
Can't remember where default keyboard is stored, but it might be in a database, needing me to actually write more than a few lines of code.
Any thoughts/comments?

What about hooking into the multiwindow keyboard? Or is that just complicating things?

q426669 said:
What about hooking into the multiwindow keyboard? Or is that just complicating things?
Click to expand...
Click to collapse
Not sure what you mean by this tbh... I don't use stock keyboard enough right now to know it..
I have looked at the sdk and there is functionality for the holster state of the s-pen.
I need to think through this, as likely we need a screen on receiver to run a service but only wake if the state changes...

pulser_g2 said:
Lenny and I were talking and sorta had the same idea independently, in that it would be nice to be able to use one keyboard "normally", and another when the S-Pen is in use (ie. removed).
Here's my thinking...
1) Hook into the framework via Xposed Framework such that when the S-Pen is removed, we store the current default keyboard.
2) Change the current default keyboard for the alternative keyboard (ie. the one for use when S-Pen is removed from phone)
3) When S-Pen is replaced into the device, the reverse is done - we backup the "S-Pen" keyboard, and restore the previous default.
This way, the user doesn't actually need to program it with their choice of keyboard - instead, it will simply learn what they use
Problems I anticipate:
Root access needed to change default keyboard
Can't remember where default keyboard is stored, but it might be in a database, needing me to actually write more than a few lines of code.
Any thoughts/comments?
Click to expand...
Click to collapse
ive read about Xposed framework but am not sure why/how its any usefull for this?
also what keyboard vs another would you be using in both situations ? or are you referign to handwriting style vs normal mode ?
when you pull the spen there is already an option in settings to have a pop up version of snote 'poping up' that means the framework is already able to make the call when spen is pulled ..
poping up the ime switcher instead of snote...i assume one to many steps for you .. how about a gesture to launch the keyboard of your choice ?
other then easy workarounds , I think you would need to write more then a few lines of code , like an app or something .. especially for step 3 ...

If you check out a rom with multiwindow, you'll be able to use the mini floating keyboard whem you have two things on the screen so you don't loose visibility of content. Anyways, I think that's just complicating things.
The purpose of this project is so that I could use the 4.2 keyboard whwn my s-pen is holstered, and then the samsung keyboard when it is out.
Currently when I'm using the Android IME I have to make a manual switch to the Samsung keyboard when I pull out my spen.
This would allow one IME to be used while the s-pen is unholstered, and a seperate IME when the pen is put away.

q426669 said:
If you check out a rom with multiwindow, you'll be able to use the mini floating keyboard whem you have two things on the screen so you don't loose visibility of content. Anyways, I think that's just complicating things.
The purpose of this project is so that I could use the 4.2 keyboard whwn my s-pen is holstered, and then the samsung keyboard when it is out.
Currently when I'm using the Android IME I have to make a manual switch to the Samsung keyboard when I pull out my spen.
This would allow one IME to be used while the s-pen is unholstered, and a seperate IME when the pen is put away.
Click to expand...
Click to collapse
Yup that's my thinking!
Multi windrow would be nice at a later date, but that's another stage of this

pulser_g2 said:
Yup that's my thinking!
Click to expand...
Click to collapse
Is there any type of notification (or intent? I get those mixed up) sent by the system when the spen is pulled? If so, a program could be launched on SPen removal. The next step would only be to change the default keyboard (which likely will require root, but should be doable.) So, instead of hacking anything, this would just be a separately installed apk.

garyd9 said:
Is there any type of notification (or intent? I get those mixed up) sent by the system when the spen is pulled? If so, a program could be launched on SPen removal. The next step would only be to change the default keyboard (which likely will require root, but should be doable.) So, instead of hacking anything, this would just be a separately installed apk.
Click to expand...
Click to collapse
I started looking at the samsung sdk and there is a receiver for the spen being removed.
I agree, this can be a standalone root app...
I didn't know the sdk could do this, but it can

I'm not a developer and just a noob, but I noticed that if you have anyother keyboard activated and showing, and you plug an usb on the go cable with a keyboard, you just have to press OK on a popup and then the keyboard changes.
Since I'm not even good at english, I recorded it on screencast. I'm sorry if this is useless, but I thought it could be some more starting point.

This is a very interesting idea, is this project "dead"?
I would be more than happy to help (or do it on my own if it's dead), furthermore I have collected everything I need to make this thing work ...

Okay guys, I will start working on the app. Anyone interested in the details of progress?
If you want to help, you can think of a name better than the one I thought about (SPen IME Switcher)
Or an Icon would be very much appreciated as I'm very bad at picture creating.
EDIT: Changed mind to SPenBoard Switcher

LegendK95 said:
Okay guys, I will start working on the app. Anyone interested in the details of progress?
If you want to help, you can think of a name better than the one I thought about (SPen IME Switcher)
Or an Icon would be very much appreciated as I'm very bad at picture creating.
EDIT: Changed mind to SPenBoard Switcher
Click to expand...
Click to collapse
I'm interested. But I'm not a developer, so I can just help by beta-testing .
Post your progresses here or just open a new topic for the app

Okay then, here's the current progress:
The app is still in the works of course, but I have a working prototype! And it's working better than expected , the prototype changes the keyboard immediately according to the state of the pen (inserted or removed), but currently the keyboards are hardcoded into the service (Swype and Samsung's Keyboard in my case).
I have to find a way to get all installed keyboards and let the user choose which keyboard is wanted for which state (I have an idea how to do that), then I'll have to get enough info from the selected keyboards to switch between them (I also have an idea on how to do that )
Only downside to the app now is, the app MUST be in /system/app.
Currently I'm adding two options, one to enable/disable the service, and one to enable service at boot.

(putting on the 'moderator' hat for this post...)
In trying to promote the purpose of this section (development discussion), can you please share details (and perhaps even code snippets) on what you are doing to detect the s-pen state, how you are going about changing the active keyboard, etc.
If you choose not to share this information, please create another thread in another section for your application.
Thank you
Gary

LegendK95 said:
Okay then, here's the current progress:
The app is still in the works of course, but I have a working prototype! And it's working better than expected , the prototype changes the keyboard immediately according to the state of the pen (inserted or removed), but currently the keyboards are hardcoded into the service (Swype and Samsung's Keyboard in my case).
I have to find a way to get all installed keyboards and let the user choose which keyboard is wanted for which state (I have an idea how to do that), then I'll have to get enough info from the selected keyboards to switch between them (I also have an idea on how to do that )
Only downside to the app now is, the app MUST be in /system/app.
Currently I'm adding two options, one to enable/disable the service, and one to enable service at boot.
Click to expand...
Click to collapse
Sounds good. I might take a look at it again.
Perhaps, if you want to make it work, rough-and-ready style, you could simply have two txt files in /data, that define the s-pen and no-s-pen keyboards.
If not, you could take a look at http://developer.android.com/reference/android/view/inputmethod/InputMethodManager.html
The app being in /system/app likely isn't a major issue, though it's possible we could maybe use root to do it directly...

pulser_g2 said:
Sounds good. I might take a look at it again.
Perhaps, if you want to make it work, rough-and-ready style, you could simply have two txt files in /data, that define the s-pen and no-s-pen keyboards.
If not, you could take a look at http://developer.android.com/reference/android/view/inputmethod/InputMethodManager.html
The app being in /system/app likely isn't a major issue, though it's possible we could maybe use root to do it directly...
Click to expand...
Click to collapse
I used another way to do this, the app is actually close to being finished, I just have to add some more tweaks here and there!
I'll make sure to post detailed information on how I achieved this.
As of now, the user can choose to run service, run it on boot, and choose keyboards for each mode (SPen or No Spen), any suggestions for other options that one might need?
Regarding the /system/app thing, I tried to use root to move the app to /system/app on first launch, but failed.
I'll try to do this later, if anyone knows how to do this, then it would be great .
EDIT: Attached a picture of the app in it's current state.

LegendK95 said:
I used another way to do this, the app is actually close to being finished, I just have to add some more tweaks here and there!
I'll make sure to post detailed information on how I achieved this.
As of now, the user can choose to run service, run it on boot, and choose keyboards for each mode (SPen or No Spen), any suggestions for other options that one might need?
Regarding the /system/app thing, I tried to use root to move the app to /system/app on first launch, but failed.
I'll try to do this later, if anyone knows how to do this, then it would be great .
EDIT: Attached a picture of the app in it's current state.
Click to expand...
Click to collapse
Hmmm that looks nice
Regarding moving the app, here's how I'd suggest you do it. Should defo. work, but can't guarantee it is the fastest way.
1) Gain root
2) Remount /system as writable
3) Copy /data/app/com.your.app.name*.apk to /system/app/, chowning and chmodding to 644
4) Extract a helper app from the main APK, and install it to /data, and gain root
5) Use helper app to delete the /data/app/com.your.app.name*.apk file
That should work after a reboot, I reckon...

thread cleaned. Please read the section guidelines BEFORE posting. LegendK95, if you've started another thread for your app, you are welcome to post a link to it here (so that people can post their comments on that app in another section.)
Gary

garyd9 said:
thread cleaned. Please read the section guidelines BEFORE posting. LegendK95, if you've started another thread for your app, you are welcome to post a link to it here (so that people can post their comments on that app in another section.)
Gary
Click to expand...
Click to collapse
Thank you.
Here's the link to the finished application.
Anyway, as promised, I'll describe how the app works (for developers):
How do I know when is the pen inserted or removed?
Basically, The whole trick is in a broadcast receiver.
I found the action that Samsung uses for the pen while I was working on my other project (SF).
Details: I searched in android.policy.jar, and found it there, in a broadcast receiver subclass for the huge and important PhoneWindowManager class
The broadcast receiver receives an intent with the action "com.samsung.pen.INSERT"
When it's sent from the system, an extra value comes along.
The value is a boolean, with the String identifier "penInsert".
This broadcast receiver is a subclass of the service that switches the keyboard, once this intent is received, the "penInsert" extra value is assigned to a field inside the service's class.
Click to expand...
Click to collapse
How does the service change keyboards?
The current keyboard can be changed using different methods, but they all do it the same way.
I used the "master" way to change the keyboard, which all the different methods lead to in the end.
The current keyboard is stored as a String inside the Settings Provider's Secure Database, with an identifier String of "default_input_method".
The stored value is called the IME ID, which is generated from the package and class name implementing the method, with a / in-between.
*From developer.android.com
So with this known, if we can get the id of a keyboard, we can use the putString method to replace the value inside the Secure Database, thus resulting in changing the default keyboard to that one.
Click to expand...
Click to collapse
How do I get the list of keyboards enabled, and their ids?
You can get a List containing the information for all keyboards enabled using the InputMethodManager service, then calling getEnabledInputMethodList().
From there, you can use each Object in the list (the object will be an InputMethodInfo instance) to get their ids, labels, icons...
Click to expand...
Click to collapse
That's it I guess, if you have questions, feel free to post them here so that everyone can benefit from this.

[Q] Google Wallet Tap and Pay?

Does tap and pay work for this phone with CM11? Is there anything special I need to do to make it work?
I've installed google wallet successfully, enabled tap and pay in settings, but I've tried tapping at several stores and nothing seems to happen, both from the lock screen and after unlocking and opening the wallet app (not sure if that's necessary, but tried it anyway).
I did some searches and read stuff about hacked versions of google wallet and other workarounds (like forum.xda-developers.com/showthread.php?t=2280943 ) but it seems these apply to older android versions only.

I don't think Google Wallet was ever officially supported on the Q. Like you said, some people hacked it up and I think a few made it work... but not many. Doesn't seem to be worth the effort.

arrrghhh said:
I don't think Google Wallet was ever officially supported on the Q. Like you said, some people hacked it up and I think a few made it work... but not many. Doesn't seem to be worth the effort.
Click to expand...
Click to collapse
Someone with a similar username to you is one of the few that made it work last year (from that other thread):
Aaargh! said:
I made an in store purchase today and it worked perfect. Pretty cool technology
Click to expand...
Click to collapse
However that thread seems to be for CM10.1/Jellybean not CM11/Kitkat so was hoping for something more recent before I start just trying things I don't fully understand.

After much more reading and questiong etc I think I figured this out and thought I'd post the details incase anyone else is interested:
#1 - Google stopped supporting tap&pay for anything earlier than KitKat summer 2014. So the older versions/hacks won't work anymore even if running older android version, etc.
#2 - There are several NFC chips, our phone uses NXP PN544 - same as Droid Razr any many other brands. There are no open source drivers for this chip, so AOSP, which CM is based on, doesn't have these drivers. Other NFC chips, like Broadcom BCM20793, do have open source drivers and they are included in AOSP, so phones with those do work for tap & pay with CM11. It also seems there is a newer NXP chip in some new phones, PN547, which may possibly work with recent AOSP 4.4.3 but I didn't keep reading about those details.
#3 - People have been trying to get NXP to release open source drivers for PN544 to AOSP, as well as trying to reverse engineer closed-source drivers from factory roms that support it natively, as well as looking at possible compatibility with PN547 drivers, but no success in any case yet. The following thread tracks that effort: http://forum.xda-developers.com/showthread.php?t=2573842
Conclusion - No way to make it work with our phone at this time. Perhaps in the future if NXP releases open source drivers or someone brilliant hacks something out.

[Joying for VW] Universal steering wheel controls with arduino

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.