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.
Related
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.
Hi.
I'm experimenting to write a personal app to help me get to know more songs. I want to catch the spotify intent that indicates when the track changes and use the data on my app.
I have been investigating how to do it and tried multiple lines of code like this (iF.addAction("com.android.music.metachanged"); ), but no luck yet. Everybody (stackoverflow) says there is no way to get that info. But the fact is that there is one app that is able to catch that info: musiXmatch. It is able to detect when the track on the spotify free radio changes and deliver the corresponding lyric.
So, I tried decompiling both the musicXmatch and spotify apks using apktool but wasn't able to find the way the apps comunicate with one another. I have yet to get deeper on smali but by what I see this far, the answer isn't there.
So, the next thing I was thinking I'd try was to make an AOSP rom with some extra logging habilities so that i can listen to the communication between the apps (namely, the broadcastreceiver).
My question: ¿Is there such an aosp distro? One that has extra sniffing/logging capabilities. Also, Anyone has an extra idea on how to accomplish my goal, or maybe some reason for which it will be impossible for me to do it (like for example the intent from spotify being explicit).
Thank you very much in advance for your time.
I solved it. I got the intent.
In case anyone wonders how I did it, here it is:
Rooted my phone (I have a Nexus 4 which lost root with one OTA update and never bothered to recover it)
Installed CydiaSubstrate. A wonderful piece of software by @saurik that allows you to literally modify any java or native C/C++ class during runtime seamlessly. It also does lots of other stuff I don't really understand.
Had to put SELinux to permissive on KitKat because it is on enforced by default since 4.3, in order for the Substrate to work
Got IntroSpy from git and wrote a Custom Hook for IntentReceiver startActivity() method
Enabled IntroSpy for musicXmatch app and it dumped all the app's intents to logcat
ztrange said:
I solved it. I got the intent.
In case anyone wonders how I did it, here it is:
Rooted my phone (I have a Nexus 4 which lost root with one OTA update and never bothered to recover it)
Installed CydiaSubstrate. A wonderful piece of software by @saurik that allows you to literally modify any java or native C/C++ class during runtime seamlessly. It also does lots of other stuff I don't really understand.
Had to put SELinux to permissive on KitKat because it is on enforced by default since 4.3, in order for the Substrate to work
Got IntroSpy from git and wrote a Custom Hook for IntentReceiver startActivity() method
Enabled IntroSpy for musicXmatch app and it dumped all the app's intents to logcat
Click to expand...
Click to collapse
Thanks, are you going to share said intents?
Nice work, but it would have been great with some more details...
Hi, please we need a follow up.
All,
First, let me say that this is not a jailbreak tool for RT 8.1! All clear? Good.
I've written a simple little driver and exe tool to patch the g_CiOptions and SeILSigningPolicy variables in ci and ntos. The obvious kicker is that you need the driver loaded for this to work -- but once loaded you can effectively use this to turn on/off the signing at will (eg: useful to avoid -- not disable -- patch guard).
I've tested this on my Surface RT as well as Windows 8 without issue.
You can find the code and binaries on github ( https://github.com/bfosterjr/ci_mod ). There isn't a whole lot of documentation (nearly zero), but you'll find batch files, windbg scripts, and various other bits which should help you figure out how it works (or you can just read the code).
Now, before you all flame me about how useless this is without a jailbreak or kernel execution for RT 8.1, let me say this: I've spent the last few days catching up on a lot of threads (over a years worth) in this form and there is enough information (if you look hard enough, open your mind, and tilt your head) in the threads to successfully start your own driver on 8.1 RT.
Cheers!
Any hint please?
Note that I would not recommend leaving this hack enabled on 8.1 once whatever programs are loaded. This will set off PatchGuard and the system will bluescreen. Enable it, run whatever, then disable it. Most programs should be OK once fully started to leave running with the hack disabled. Only loading unsigned DLLs from that point on would mess up.
8.0, do whatever; doesn't matter.
Melissa
Myriachan said:
Note that I would not recommend leaving this hack enabled on 8.1 once whatever programs are loaded. This will set off PatchGuard and the system will bluescreen. Enable it, run whatever, then disable it. Most programs should be OK once fully started to leave running with the hack disabled. Only loading unsigned DLLs from that point on would mess up.
8.0, do whatever; doesn't matter.
Melissa
Click to expand...
Click to collapse
Quite right - which is why the ci_mod program I wrote will run indefinitely waiting for user input to toggle on, or off, the kernel patching. So.. (1) Load the driver which will immediately toggle patching ON... (2) start ci_mod.exe and toggle patching back OFF ... (3) leave ci_mod.exe running. Doing so you will always re-toggle patching on (then off again) so you can run your unsigned app with minimal likelihood of PatchGuard being a problem.
Hopefully that makes sense.
Obviously, if anyone wants to make changes to the driver or program -- perhaps to alter it to suit initial driver execution conditions -- they're welcome too -- the code is GPL.
Cheers!
LolitaPlus said:
Any hint please?
Click to expand...
Click to collapse
Sorry no. There are serious reasons why I can't explain further. So please don't ask.
But trust me.. the bits you need are there... you just need to stitch them together.
bfosterjr said:
Sorry no. There are serious reasons why I can't explain further. So please don't ask.
But trust me.. the bits you need are there... you just need to stitch them together.
Click to expand...
Click to collapse
Hai, I'm kinda new to this whole hacking scene especially to the x86/x64 bit one (has been working on arm for a little while) and I was wondering what knowledge was necessary to be able to glue everything together? Which glue I need to use so to say
Thanks.
filfat said:
Hai, I'm kinda new to this whole hacking scene especially to the x86/x64 bit one (has been working on arm for a little while) and I was wondering what knowledge was necessary to be able to glue everything together? Which glue I need to use so to say
Thanks.
Click to expand...
Click to collapse
Years of Windows internals/development/debugging makes for good glue. That and the general desire (and patience) to want to mess with software....
bfosterjr said:
...
You can find the code and binaries on github ( https://github.com/bfosterjr/ci_mod ). ...
Click to expand...
Click to collapse
Hey mate, this looks very nice and far more user(noob)-friendly. Thank you soo much for sharing. :good:
Cheers
Blade
P.S.:
1) Is your deleted sign.bat a kind of launcher which : toggle -> start app -> toggle ?
2) Is it possible to share the compiled version? [Don't want to bother you] (Just formated my dev-pc and set it up to compile Android 4.4.4 for my desire Z. I know i need a new pc with a bigger hdd) :crying:
BIade said:
Hey mate, this looks very nice and far more user(noob)-friendly. Thank you soo much for sharing. :good:
Cheers
Blade
P.S.:
1) Is your deleted sign.bat a kind of launcher which : toggle -> start app -> toggle ?
2) Is it possible to share the compiled version? [Don't want to bother you] (Just formated my dev-pc and set it up to compile Android 4.4.4 for my desire Z. I know i need a new pc with a bigger hdd) :crying:
Click to expand...
Click to collapse
Hey Blade!
1) nope. that was a batch file to test sign the driver. its not required. the toggling of the patching is done by the user through cimod.exe (runs in a continuous user-input loop)
2) binaries for all supported platforms are there already -- https://github.com/bfosterjr/ci_mod/tree/master/bin
Cheers!
It would be really cool to hook the CreateProcess and LoadLibrary calls such that, if the target binary is unsigned and the caller isn't in an appcontainer, the policy is (automatically) flipped juuuust long enough for the call to succeed, and then (automatically) flipped back. That means minimal risk of a BSOD and maximum user-friendliness.
I proposed this approach months ago on the JB discussion thread, but never got around to writing it. Now bfosterjr has written the driver part (probably by far the hardest part) in a few days! We missed you...
GoodDayToDie said:
It would be really cool to hook the CreateProcess and LoadLibrary calls such that, if the target binary is unsigned and the caller isn't in an appcontainer, the policy is (automatically) flipped juuuust long enough for the call to succeed, and then (automatically) flipped back. That means minimal risk of a BSOD and maximum user-friendliness.
I proposed this approach months ago on the JB discussion thread, but never got around to writing it. Now bfosterjr has written the driver part (probably by far the hardest part) in a few days! We missed you...
Click to expand...
Click to collapse
Thanks man. Really wasn't all that difficult. The driver isn't quite as flexible (or perfect) as it could be. To accomplish what you're suggesting might take some effort because, IIRC, the normal process create callbacks don't get triggered until after process image verification. I'll have to double check that.
I might take a stab at updating the driver to make it more automated. Once I have a bough free time. Stay tuned
Cheers!
bfosterjr said:
Thanks man. Really wasn't all that difficult. The driver isn't quite as flexible (or perfect) as it could be. To accomplish what you're suggesting might take some effort because, IIRC, the normal process create callbacks don't get triggered until after process image verification. I'll have to double check that.
I might take a stab at updating the driver to make it more automated. Once I have a bough free time. Stay tuned
Cheers!
Click to expand...
Click to collapse
What GoodDayToDie suggested is not using PsSetCreateProcessNotifyRoutineEx but hooking Ring3 API. I can offer some help if you need ARM Ring3 inline hook. I already wrote a hook engine though it is more like a POC.
LolitaPlus said:
What GoodDayToDie suggested is not using PsSetCreateProcessNotifyRoutineEx but hooking Ring3 API. I can offer some help if you need ARM Ring3 inline hook. I already wrote a hook engine though it is more like a POC.
Click to expand...
Click to collapse
Yeah, I got that.. but I'm just not a fan of hooking the be-jesus outta usermode to solve this problem. I don't' like hooking in general.. as it tends to just lead to more problems and complications. I'd rather try to find a more clever way to solve this problem with callbacks or some other OS supported mechanism.
Cheers!
Yeah... another option would be hooking NtCreateProcess (ring 0) either in the actual entry point or at the syscall table, but I can't imagine you're *more* enthusiastic about hooking kernel-mode than user-mode, and messing with the syscall table could make PatchGuard angry too. With that said, the user-mode hook would be pretty easy, actually; once the tool is running, it uses the process instrumentation/shimming stuff in Windows (ImageFileExecutionOptions key?) to have every EXE load a (homebrew) DLL at startup. The DLL installs the requisite hooks (and probably then unloads itself). You'd need to inject that DLL into already-running processes, but that's not hard.
Windows automation isn't my strong point, but I know the x86 emulation layer is able to detect when somebody tries to run an x86 EXE and intercept the attempt *before* the process launch fails. Is this usable here (i.e. does whatever that listens on trigger before the signature check)? If not, a hook may be the only workable approach, hacky though it is.
bfosterjr said:
there is enough information (if you look hard enough, open your mind, and tilt your head) in the threads to successfully start your own driver on 8.1 RT.
Cheers!
Click to expand...
Click to collapse
Well I've been looking, and contributing, for a long time, but still cant quite crack it ...
Can't quite understand
I have read through your source code. I don't quite understand the point though. Is this app and driver to allow unsigned exe to run? Is the batch file required? From what I can see all that is required is netham45's Jailbreak and this to run unsigned exe. I would like to share my finding's in an instruction post but thought I would ask your permission first. May I?
Thanks,
Wcomhelp
The purpose of this is to make it "safer" to jailbreak 8.1, since if you change the code integrity flag in 8.1 and leave it changed for any length of time, the system will crash due to PatchGuard. This driver is so you can only change the code integrity settings when you need to load unsigned code, giving minimal time for PatchGuard to notice and minimizing the risk of a crash.
HOWEVER, you cannot load this driver unless you already have unsigned code execution through some other means. That other means has not yet been published; if you want to use this tool you will need to figure out how to install it yourself (or wait for a published hack).
EDIT:
Wouldn't CVE-2014-4148 / CVE-2014-4113 (MS14-058) be sufficient to initially load this tool?
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4113
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4148
technet.microsoft.com/library/security/MS14-058
Yeeeeesssssss... yes it probably would!
Of course, you'd need to avoid installing the patch for it - not really a "proper" jailbreak, in that sense - but yeah, that should work. All you need to do is toggle code signing off for a second to load the driver, and code execution in Win32k.sys should manage that.
Oh, win32k, how we love you... so many vulnerabilities in just one little kernel-mode component!
GoodDayToDie said:
The purpose of this is to make it "safer" to jailbreak 8.1, since if you change the code integrity flag in 8.1 and leave it changed for any length of time, the system will crash due to PatchGuard. This driver is so you can only change the code integrity settings when you need to load unsigned code, giving minimal time for PatchGuard to notice and minimizing the risk of a crash.
HOWEVER, you cannot load this driver unless you already have unsigned code execution through some other means. That other means has not yet been published; if you want to use this tool you will need to figure out how to install it yourself (or wait for a published hack).
Click to expand...
Click to collapse
Does this work?
http://msdn.microsoft.com/en-us/library/ff547565.aspx
dmesg dump from unit:
http://pastebin.com/D5YpijAR
working on filesystem dump.
Actually, the update images appear to be incomplete. They don't include any of the SYU or JY apk's. Among other files I have seen that are missing in the update .zip's.
Modify system app with shared user id 1000
Not sure if this is the right place to post, but I am trying to extend the functionality of my Joying 2gb sophia head unit (5.1.1).
I am making changes to the apk that accepts the key presses (Sofia-1-C9-Server-V1.0.apk) and translates them into commands. For example, I want to start the google voice search activity from the steering wheel buttons. I also modified the applications that are cycled through with the 'Source' key.
I have made all the modifications to the smali code and rebuilt the apk . The problem comes when I try to install/use it the system will not recgonize it. From the error I get, it needs to be signed with the same signature as the other apps that share this user ID 1000 (android.uid.system). It looks like there are 23 other programs using this ID.
Is there anyway to have the HU accept this modified package? I was thinking about re-signing all 22 of the apk files that use this shared id, but not sure if that would work. Thought I would ask to see if anyone has any experience with this issue.
Any suggestions?
Thanks
gustden said:
Not sure if this is the right place to post, but I am trying to extend the functionality of my Joying 2gb sophia head unit (5.1.1).
I am making changes to the apk that accepts the key presses (Sofia-1-C9-Server-V1.0.apk) and translates them into commands. For example, I want to start the google voice search activity from the steering wheel buttons. I also modified the applications that are cycled through with the 'Source' key.
I have made all the modifications to the smali code and rebuilt the apk . The problem comes when I try to install/use it the system will not recgonize it. From the error I get, it needs to be signed with the same signature as the other apps that share this user ID 1000 (android.uid.system). It looks like there are 23 other programs using this ID.
Is there anyway to have the HU accept this modified package? I was thinking about re-signing all 22 of the apk files that use this shared id, but not sure if that would work. Thought I would ask to see if anyone has any experience with this issue.
Any suggestions?
Thanks
Click to expand...
Click to collapse
Could you use MTCD tools to do this. I'm thinking it should work on these.
Wow! I was actually searching to see which APK received input from the HW Keys. I couldn't get any data from /dev/input/eventX so I began to search elsewhere. Great find! Are you able to post the de-compiled version so others may assist as well?
gustden said:
Not sure if this is the right place to post, but I am trying to extend the functionality of my Joying 2gb sophia head unit (5.1.1).
I am making changes to the apk that accepts the key presses (Sofia-1-C9-Server-V1.0.apk) and translates them into commands. For example, I want to start the google voice search activity from the steering wheel buttons. I also modified the applications that are cycled through with the 'Source' key.
I have made all the modifications to the smali code and rebuilt the apk . The problem comes when I try to install/use it the system will not recgonize it. From the error I get, it needs to be signed with the same signature as the other apps that share this user ID 1000 (android.uid.system). It looks like there are 23 other programs using this ID.
Is there anyway to have the HU accept this modified package? I was thinking about re-signing all 22 of the apk files that use this shared id, but not sure if that would work. Thought I would ask to see if anyone has any experience with this issue.
Any suggestions?
Thanks
Click to expand...
Click to collapse
gtxaspec said:
Wow! I was actually searching to see which APK received input from the HW Keys. I couldn't get any data from /dev/input/eventX so I began to search elsewhere. Great find! Are you able to post the de-compiled version so others may assist as well?
Click to expand...
Click to collapse
I think he will but the code is in smali. I tried to decompile the bluetooth app to see if i can change things. All written in smali language.
I have a mibro-air watch, and the firmware does not support right-to-left languages
The firmware is sent to the phone from the manufacturer's app
1. is it possible to "capture" the firmware (using an emulator?)
2. What tools would I need to reverse engineer the compiled firmware, and later build a new version
3. How would I send my updated firmware to the watch? (emulator again?)
thanks
Why not simply from Developer Options in Android's Settings, check Force RTL layout Direction ?
Well you want to build a custom rom... For a watch?
jwoegerbauer said:
Why not simply from Developer Options in Android's Settings, check Force RTL layout Direction ?
Click to expand...
Click to collapse
The watch firmware is a custom o/s not Android or wear o/s
It is not android or wear os? What does it show in settings?
LR7875 said:
Well you want to build a custom rom... For a watch?
Click to expand...
Click to collapse
Yes.
Is there another option to fix the right-to-left rendering of notification (e.g sms, whatsapp) nessages?
So everything is lining up from right to left?
Well this may be fixed in settings, depending on your operating system.
Maybe sending me a photo of the issue?
LR7875 said:
So everything is lining up from right to left?
Well this may be fixed in settings, depending on your operating system.
Maybe sending me a photo of the issue?
Click to expand...
Click to collapse
Not really
the problem is with the display of messages from the phone (e.g. telegram, whatsapp, ...) which are received in a right-to-left language (e.g. Arabic, Hebrew, Farsi).
The watch has support for the font, so the characters are displayed correctly, but in reverse order.
For example, the string "השעון לא מציג הודעות בעברית" (which translates to the watch does not display Hebrew messages), would be displayed as:
תירבעב תועדוה גיצמ אל ןועשה
which makes reading messages (or phone contact names for incoming calls) incredibly annoying
As stated, I have no idea what type of o/s is used for the mibro air watch firmware
The current version is 2.04 (which has not been updated in many months, and I suspect will never be updated, as I cannot get any response from their customer support)
So 'hello' will be 'olleh' on the watch?
LR7875 said:
So 'hello' will be 'olleh' on the watch?
Click to expand...
Click to collapse
And "hello world" would be "dlrow olleh"
hrs12 said:
And "hello world" would be "dlrow olleh"
Click to expand...
Click to collapse
Yes. That is frustrating indeed.
Can you manage to get into settings (wait that is sgnittes)?
LR7875 said:
Yes. That is frustrating indeed.
Can you manage to get into settings (wait that is sgnittes)?
Click to expand...
Click to collapse
English text is displayed correctly (everything is left-to-right)
Setting in the watch had the following options:
- off time
- raise to wake
- about watches
- pairing the phone
- restart
- shutdown
- factory reset
Factory reset doesn't fix anything?
LR7875 said:
Factory reset doesn't fix anything?
Click to expand...
Click to collapse
No. The problem stems from an inherent bug (or lazy coding) in the firmware's text rendering. It has been reported by various users online (using Arabic and Farsi), do it is not related only to my watch.
I have 3 watches in the original box, and will not use them if caller name's and messages cannot be displayed correctly.
I see no other option but reverse engineering the firmware
Any advice on the procedure , tools required would be appreciated
Well normal ROM Devs compile a custom ROM (operating system) from sources. You need to create sources from ROM, fix it and then compile it.
Well it might be hard, but wish you good luck!
hrs12 said:
The watch firmware is a custom o/s not Android or wear o/s
Click to expand...
Click to collapse
As I read this smartwatch is intended to be used by children only, hence it's cheap ( $30 ) and has an OS what is not named by manufacturer. It's even not clear what CPU / GPU is inbuilt, so my POV is that it makes no sense to try to compile an Android OS for
this device.
jwoegerbauer said:
As I read this smartwatch is intended to be used by children only, hence it's cheap ( $30 ) and has an OS what is not named by manufacturer. It's even not clear what CPU / GPU is inbuilt, so my POV is that it makes no sense to try to compile an Android OS for
this device.
Click to expand...
Click to collapse
I know it is cheap, and btw the company seems to be out of business (their web site is dead), thus no new ROM is to be expected.
All the same, given the proper tools it could prove to be an educational experience. Especially, as I do not need to perform any hardware i/o modifications only string processing.
So, I ask again, is there a guide or something similar that can help me in capturing the current ROM, performing a binary to source translation and recompiling and somehow sending it to the watch
Naturally, I will have to figure out the cpu's archticture (but that is pretty much similar in cheap smart watches and could be guessed)
hrs12 said:
So, I ask again, is there a guide or something similar that can help me in capturing the current ROM, performing a binary to source translation and recompiling and somehow sending it to the watch
Click to expand...
Click to collapse
As long as you don't know what OS the watch is running on - you need this to know what USB driver is needed to access the internal storage memory of the watch - you can't dump anything from it, IMO.