Related
Hi,
I've made my first steps with the dsixda's Android kitchen, which worked out well so far. However I've realized that the ROM will get signed during the ROM creation.
Now I'm wondering what the purpose of this is. What advantages do I get? Are there any downsides? After I've got some basic knowledge about cryptography,
I can see why OEMs are using this, but in contrast we don't have their private keys, whereas everyone downloading the kitchen can get the private key and have s-off devices anyway.
Furthermore in order for this model to work properly the public key (or some sort of root certificate) must be put on the device, so the device then can check against it. I suppose S-ON is exactly doing this, as only signed code can be executed.
So what is this ROM signing about? I've searched for reasons why to sign a ROM, but could only find instructions how to do it without any background information. What are these keys used for? I hope it is not used as root certificate in any way, so that packages signed with the publicly available private key can be installed/executed without any warning. Does it make it sense to generate a pair of keys for myself or will the private key will be included in the ROM anyway?
Best regards,
johnpatcher
Just sign it, means you don't need to know! If you don't sign it no one can flash it unless they disable signature checking
EddyOS said:
Just sign it, means you don't need to know!
Click to expand...
Click to collapse
Well, I tend to want to know what I'm doing, especially because I'm interested in cryptography and try to have security in the back of my head always . Basically I don't want to include some (private) keys I don't know anything about and the reason why they are needed.
EddyOS said:
If you don't sign it no one can flash it unless they disable signature checking
Click to expand...
Click to collapse
I don't see any point in the signing, beside some basic verification whether the ROM is damaged. Every harmful change done by someone on purpose will also change the included private key, so basic hash functions would also do the job and would be a lot more efficient. So I think there must be a better reason for this public-key crypto. Any clues?
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 All,
I was wondering if you could point me in the direction of (IF SUCH A UTILITY EXISTS) a webpage / App / Windows Utility, that can open a pre-made existing custom rom. And say for example it can.....
1) Change the Build.Prop file, from Chinese to English and strip out any other unneeded settings.
2) Remove Chinese Apps, or any other unneeded Apps
3) Replace key Chinese Apps, with English Apps... (ie: swap pre-configured MS Bing Voice keyboard to Google Keyboard)
Basically, just tidy up a pre-released Chinese rom, into English....
Does such an App, or service exist....??? If so, can anyone point me in the right direction please...
Thanks, Lister
What you are asking for is very complex and is never one in the same across other devices. In this typical situation the best solution is to manually make the changes.
Hi Modding.MyMind,
Thank you for your quick reply, indeed I was able to make the changes post (AFTER) the initial setup, which I had to exit the setup process as the built in Voice Keyboard didn't recognise some of the words I was saying, and there was no fall back typing keyboard to type what I intended. So it meant I missed some of the in-setup questions / options. Sure, I can sign into my Google account once swapped out to the Google Keyboard that I kept on the SD card. But things like personalizing it were missed.
I'm sure about a year ago or so, there was an App on the PlayStore that could packup your installed live rom, and turn it into a flashable rom. Sure I guess thats what CWM or TWRP project can do... But sure there was a specific App that made it more like a rom packager...??
Any clues...?? Thanks, Lister
Modding.MyMind said:
What you are asking for is very complex and is never one in the same across other devices. In this typical situation the best solution is to manually make the changes.
Click to expand...
Click to collapse
Hello all, I'm trying to debug the gboard app that I want to make some edits to. I used apktool 2.2.2 to decompile and make some xml edits, and recompile. I signed the new apk with apk-signer. After I install the app, it just force closes and does nothing. I made very rudimentary edits to the emojis, so nothing majorly changed, only a few strings. Ideally, I'm trying to edit the text emojis such as "=-O" to better ones like =O and maybe email addresses or some passwords.
The big picture of what I'm trying to accomplish is have a single button press that inserts my own text, like a gaming computer G-key. I was able to do this with earlier versions of the google keyboard,m but now want to try with Gboard since it's such a better keyboard. If you have any suggestions to solve either editing the apk or any keyboards that have fully customizable keystrokes please let me know.
Hey,
I did a custom google keyboard APK a few years ago and, as I replaced my phone with a Galaxy S8+ running Android 7.0, the app is not working anymore. I'm trying to redo it with a newer version of the app, but I'm facing the same issue as you: I'm able to decompile, edit, recompile, sign and install the app but as soon as I open the keyboard settings or the keyboard itself, it crash.
My first version had a similar issue, but I was able to open the settings, and manually download the dictionnaries needed (English and French in my case), then the keyboard would work. In the present case, i'm not even able to open the settings of the keyboard before it crash. I don't know if the dictionnaries are still the issue, thought...
I have read somewhere that it could have to do with the signature not being recognized as a Google App signature, or something like that.
If you have any news, please let me know
Jonathan
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.