Related
I am aware that this has been asked many many times, but i don't see a thread for this issue. I would like to know what attemps have been made to get some sort of support. I am by no means a developer, but i will try my best to get things running. Would it be something as simple as taking a a file out of a current android phone with the same specs and modding for use with a touch pro.
I'm simply curious if there is a thread or website around that discusses this and other issues in more detail.
I'm no kernel hacker, but I am...curious.
That's what i would like to know. facts about how far the development is. Maybe we could start a thread that has such progress stated. Where only the devs would be able to post, so we can have us a look.
The best you can do is read the IRC logs from #htc-linux. I think I recall reading in the logs that klinux had gotten OpenGL working on the Pro2, even with applications like Neocore (thought they're apparently slow).
You have to be a little bit more clear on what you mean by "open gl working".
I'm the developer who was working on the open gl for the klinux build. Bottom line is that open gl is working, but not with hardware acceleration. We used then nexus one drivers (adreno200) to enable things a live wallpapers. But it's so slow its not even worth it.
Now to get hardware 3d working 100%? a lot more work and testing. lol.
Well is hardware 3d working for any of the current android ports in any capacity?
Also, I'm so used to reading hardware specs in Desktop computer form. But with these phones, the only thing I know about them is the CPU manufacturer, model number, and speed.
Is there a separate chipset that handles audio graphics etc, or is it completely SoC.
I read about recent Android ports on the iPhone, and it seems they already have things like external audio working. Is this because the hardware on the iPhone similar to another HTC Android phone, more so than the hardware in the Rhodium?
awesome thread... actually informative and supportive.
i think what the OP is saying is how can us lowerscale highend users be more involved, perhaps in the debugging, data gathering... we could start a -sub group dedicated to each corresponding issues... bill gates didnt invent windows, him and his crew did. the more the merrier eh?
I have a long running reverse engineering thing going on. I have been looking for more info other than IRC. I would like to put my good skills to work w/out starting from scratch. Any info?
EDIT: I did find this, It has some helpful starting info: http://www.androidonhtc.com/wiki/Get_Involved
This is a great thread! I've been wanting to get in on some of this action. Hopefully this will reduce some of the clutter in Reefer's thread.
I meant to get hardware acceleration working. How far has this come along since i posted this??
Only Diamond / Raphael has hardware 3D enabled so far.
Very limited 3D for "low resolution" could be enabled in blackstone or other devices with workaround but that is somehow meaningless.
phh has tried different combinations of memory allocation but in vain.
so am I... given up at the moment.
mcdull said:
Only Diamond / Raphael has hardware 3D enabled so far.
Very limited 3D for "low resolution" could be enabled in blackstone or other devices with workaround but that is somehow meaningless.
phh has tried different combinations of memory allocation but in vain.
so am I... given up at the moment.
Click to expand...
Click to collapse
Phh recommended to trace down mem locations used by wince and that has been done but it still refuses to fire up once pmem.c is modified.
Recently i got the wince dmesg from my rhod in hopes that a cold boot would show as to how the 3d is being activated but that also showed no results. I get this crap when Manila is launched.
[ManilaToday](34156): ### Launching manila ###
23:20:09 [DISP] DrvEscape::HTC_SET_3D_LAUNCHING_FLAG.
I'm not sure what HTC_SET_3D_LAUNCHING_FLAG is.
The next step would be to make an android app and trace down what the hell the libgles_qcom driver is actually doing to see if it is working properly. If you load up ahi2dati.dll on winmo you can actually use the functions to show crap on the screen so i'm hoping the same can be done on android.
Not sure what else can be done at this stage.
[ACL] said:
Phh recommended to trace down mem locations used by wince and that has been done but it still refuses to fire up once pmem.c is modified.
Recently i got the wince dmesg from my rhod in hopes that a cold boot would show as to how the 3d is being activated but that also showed no results. I get this crap when Manila is launched.
[ManilaToday](34156): ### Launching manila ###
23:20:09 [DISP] DrvEscape::HTC_SET_3D_LAUNCHING_FLAG.
I'm not sure what HTC_SET_3D_LAUNCHING_FLAG is.
The next step would be to make an android app and trace down what the hell the libgles_qcom driver is actually doing to see if it is working properly. If you load up ahi2dati.dll on winmo you can actually use the functions to show crap on the screen so i'm hoping the same can be done on android.
Not sure what else can be done at this stage.
Click to expand...
Click to collapse
Ok, i would love to help out as i have never rly done anything like this b4. What exactly are you doing. How do you get HTC_SET_3D_LAUNCHING_FLAG?
How would i open a .dll, i dont think these can just be opened up to see what they are doing. I am on the dark side of the moon here. I know whats going on, but have no clue what to do to help.
garage_man said:
Ok, i would love to help out as i have never rly done anything like this b4. What exactly are you doing. How do you get HTC_SET_3D_LAUNCHING_FLAG?
How would i open a .dll, i dont think these can just be opened up to see what they are doing. I am on the dark side of the moon here. I know whats going on, but have no clue what to do to help.
Click to expand...
Click to collapse
I actually found HTC_SET_3D_LAUNCHING_FLAG on the wince dmesg. You can do this by doing a pwf dump.txt 0x16a00000 0xFFFF0 in haret. I did it after a cold boot to see if anything is done to the gpu once wince boots.
Loading the dll is easy. just make a simple win32 app and do a loadlibrary. This part works but it's not helping on android. I'm interested to see what mcdull thinks since i think he has ventured a lot into this as well. Right now if we can make a simple app in android to load the libgles_qcom.so directly and trace every step, i think that would be helpful to see where we are failing. I'm close to giving up..lol i already took 2 sick days from work to get to where i am now so i could use some help.
Here is what i got out of the chip in wince.
name: ATI HandHeld Interface
versions: 2.07.05110.34681
Revision: 0
ChipID: 1362104322
revisionid: 0
TotalMemory: 15990784
BusInterfacemode: 2
InternalmemSize: 262144
ExternalMemSize: 0
Surface info: 800x480
surface total bytes 768000
dwFrameBufferPhysical=0x14c00780 m_dwFrameBufferVirtual=0x57e00000 dwFrameBufSize=0xbb800
Most people here could probably not help with the hardcore kernel dev stuff, but I guess if you need memory locations or so (be it for opengl/sound etc) I think there a a LOT of people that are willing to run some apps that dump a txt file with debugging info & mem locations to their SD-card and send you that
I would love to help with developing, even if it means that I have to boot into winmo and android all night long and gather certain information, memory-adresses, try different versions of programs with all kinds of parameters etc.
Star-Lite said:
Most people here could probably not help with the hardcore kernel dev stuff, but I guess if you need memory locations or so (be it for opengl/sound etc) I think there a a LOT of people that are willing to run some apps that dump a txt file with debugging info & mem locations to their SD-card and send you that
I would love to help with developing, even if it means that I have to boot into winmo and android all night long and gather certain information, memory-adresses, try different versions of programs with all kinds of parameters etc.
Click to expand...
Click to collapse
We need more devs in general. I ran a trace on a basic app that runs 3d. So there is still a lot of crap to examine.
I'm willing to kill my touch pro 2 and remove the CPU to trace the JTAG locations but I only have the datasheet from the MSM7200/7500, not sure if it will be the same locations. I bet if I hooked up my Segger I could see exactly what is failing on the OpenGL and sound side since alot of hardware debugging is done this way...just sucks I dont know for sure if the pinouts are the same. I'm done it on quite a few different phones and boards over the years so its not a big deal. Omap3430 was simple to trace and the OMAP3530 had the exact pinouts.
BinaryDroid said:
I'm willing to kill my touch pro 2 and remove the CPU to trace the JTAG locations but I only have the datasheet from the MSM7200/7500, not sure if it will be the same locations. I bet if I hooked up my Segger I could see exactly what is failing on the OpenGL and sound side since alot of hardware debugging is done this way...just sucks I dont know for sure if the pinouts are the same. I'm done it on quite a few different phones and boards over the years so its not a big deal. Omap3430 was simple to trace and the OMAP3530 had the exact pinouts.
Click to expand...
Click to collapse
Sounds crazy.. i love it.
I was messing around today and made a small app to load the libgles_qcom.so directly to see if i can replicate my winmo success. Most of the ahi functions are included in the android driver as well except for AhiDispSurfGet which made it impossible for me to draw anything on screen.
The chip did pump out the same info as i posted before and it matches so thats a step in the right direction. Means we can recognize the chip with no problems and all 15.25 memory is reporting as well. If i had more documentation on those functions exported im sure i can get the chip to try to display something directly.
Interesting bit of info I read and perhaps someone can clarify this here. The Sprint Touch Pro 2 uses the Qualcomm MSM7600 processor. The AT&T Tilt2 (GSM phone) uses the MSM7201A processor. The "A" refers to the smaller 65nm die size (I believe).
From what I've read, some changes occurred on the MSM7200 -> MSM7201 due to patent infringements. The next question is, is the MSM7201A and MSM7600 essentially the same chip, just different hardware for CDMA/GSM?
I guess the "libgles_qcom.so" library is used in many other HTC Android phones, but for some reason it's failing on the touchpro2/tilt2, and we're not sure why (although logically it sounds like the library should work as it's used by other android phones with the same chipset)? I'm no kernel dev (I write .NET/c# apps which are much easier than kernel stuff), but am somewhat familiar w/ linux and perhaps can assist in development..
NewbTrader said:
Interesting bit of info I read and perhaps someone can clarify this here. The Sprint Touch Pro 2 uses the Qualcomm MSM7600 processor. The AT&T Tilt2 (GSM phone) uses the MSM7201A processor. The "A" refers to the smaller 65nm die size (I believe).
From what I've read, some changes occurred on the MSM7200 -> MSM7201 due to patent infringements. The next question is, is the MSM7201A and MSM7600 essentially the same chip, just different hardware for CDMA/GSM?
I guess the "libgles_qcom.so" library is used in many other HTC Android phones, but for some reason it's failing on the touchpro2/tilt2, and we're not sure why (although logically it sounds like the library should work as it's used by other android phones with the same chipset)? I'm no kernel dev (I write .NET/c# apps which are much easier than kernel stuff), but am somewhat familiar w/ linux and perhaps can assist in development..
Click to expand...
Click to collapse
learn haret/haretconsole and take a look a the kernel. good place to start. Feel free to come into the irc board if you have any questions
Hi there,
right now I am researching for a possibility to emulate a smartcard with a smartphone. As we all know, the standard os and api won't let us do this. What I want to achieve is create a way to use the smartphone for physical access without the need to change the existing infrastructure. o achieve that, the smart phones gets a localy and time limited informationtoken it should present to the reader. In other words, I actually dont realy need access to the secure element, as any data would be temporary.
Right now I am a bit confused about this. Is there a way to use card emulation, without the need of a secure element? I have searched for different ways to acchieve this, but on many ends, I can't seem to find a definitv answer.
For example I stumbled on OpenNFC. They praise that they can acchieve card emulation. Yet, they don't provide any examples on this and fail to actualy deliver some sort of information on the requirements of this. As I understand it, it seems like this method only works when the smartphone uses Inside Secures Chips MicroRead or SecuRead. Anyone knows more about this?
I'm realy open to ideas on this one, as it seems theres little to no documentation or examples to go on.
I'd realy be happy to read about what you guys found out on this issue as of yet.
I've been looking into it too. This is what I have found:
EddieLeeDefcon20.pdf
nfcproxy
(Google them, I can't post links)
So, yeah, it can be done, but you have to modify android to be able to.
I ended up to OpenNFC too, but no sample code!
I have a good background on Mifare Classic 1K and 4K programming using RFM130 under linux and win.
Sent from my HTC One X using Tapatalk 2
Ok, so after browsing the mailinglist like a maniac I found this answer from one of OpenNFCs developers:
Hello,
The OpenNFC stack porting on Android complies to the Google API, as far as the applications are concerned.
Since these API do not allow an APK to do card emulation, it is not possible to use this mode on the Nexus,
nor on any Android phone, with or without OpenNFC.
However, OpenNFC provides card emulation feature for other porting (Win32, linux), depending on the hardware capabilities.
Kind regards,
Stephane
Click to expand...
Click to collapse
Source is on their mailing list on sourceforge, cant post link....
So seems we can forget this one... Only option would be using the Cyanogenmod patch that is used by NFCProxy.
When this message has been posted? I think things has changed (not sure)
Anyway, I posted a message yesterday to have more informations about their projects on Android
The Message is from March 29th, 2012.
Again as I said, if that has changed, they really have to work on their communication to the outside. There seems to be noone but the devs that can say anything about this. And that means quite a lot.
When there is no API for something, we can use native code and directly communicate to NFC hardware. Agree?
Sent from my HTC One X using Tapatalk 2
Well, the way I understand it is, that we could take a build of android and tinker with it to get it to work. We would have to change the NFC softwarestack and its interaction with the rest of the system in order to make software emulation possible. That is quite some pile of nontrivial work to do if you ask me.
Sorry for doing a new reply instead of editing the old one, but I think this is interesting enoug to not get overread.
I got an answer from the OpenNFC Developerteam regarding my question. Part of my question was also if it was possible to emulate for example a Mifare Tag through their NFC Stack. Here is the answer:
Hello XXXXX,
The Open NFC stack is designed to be largely hardware-independent, with a small adaptation module (NAL) for each hardware chipset. However, currently we only provide the NAL module for the MicroRead / Securead chipsets; therefore out of the box we are only compatible with these chipsets.
It is possible to emulate ISO 14443-4A and -4B cards and Type 4 tags from the Open NFC stack; for emulation of MiFare Tag, you’d indeed need to use a Secure Element.
Best regards,
Sebastien.
Click to expand...
Click to collapse
Hope this clears some questions regarding OpenNFC.
Google released some weeks ago Android Auto.
http://www.android.com/auto/
An app on your Lollipop device that can connect to cars head units.
So using your phone with the biger display in your car, with apps specially designed for that.
The problem is that you need a new car or a after market head unit that supports Android Auto.
That sounds really expensive!!
BUT what if we could replace that expensive head unit with a raspberry pi?!
Have no idea yet if that would work, that's why I started this topic, for brain storming about this. [emoji1]
Would be nice to have a multimedia central with Waze running... Hope it gets popular fast
that would be awesome and i am totally into that.
as far as i know, some guy made an lolipop port for the pi2. maybe we can use that as a base.
jackcaos said:
that would be awesome and i am totally into that.
as far as i know, some guy made an lolipop port for the pi2. maybe we can use that as a base.
Click to expand...
Click to collapse
Try my Headunit app of course; see sig...
But it requires Android 4.1+, a decently fast H.264 decoder, at least at 800x480 resolution, and USB Host Mode support, or in future WiFi Direct.
mikereidis said:
Try my Headunit app of course; see sig...
But it requires Android 4.1+, a decently fast H.264 decoder, at least at 800x480 resolution, and USB Host Mode support, or in future WiFi Direct.
Click to expand...
Click to collapse
Hi Mike, my apologies for cold outreach. Interested in your technology, please PM me so we can talk.
Thank you
thundpa said:
Hi Mike, my apologies for cold outreach. Interested in your technology, please PM me so we can talk.
Thank you
Click to expand...
Click to collapse
Anyone can email me anytime at [email protected] .
Is this already built? Or are you just suggesting an idea? I'd love to have it in my car. Do post here if when it is ready. (I mean the PI version)
mathewparet said:
Is this already built? Or are you just suggesting an idea? I'd love to have it in my car. Do post here if when it is ready. (I mean the PI version)
Click to expand...
Click to collapse
Quote from OP:
Have no idea yet if that would work, that's why I started this topic, for brain storming about this.
Click to expand...
Click to collapse
I will be/have released my Headunit app as open source, so someone with the skills could do this.
But I likely won't be doing it myself.
If there is someone with skills to compile your head unit app would be great.
Where can we find the code for your app?
Sent from my Nexus 7 using Tapatalk
luci84tm said:
If there is someone with skills to compile your head unit app would be great.
Where can we find the code for your app?
Sent from my Nexus 7 using Tapatalk
Click to expand...
Click to collapse
https://github.com/mikereidis/headunit
I might re-consider and do it myself, but my time is limited. I could also just to try help someone to port it.
I would rather have it working well on Android alone than having it half working on multiple platforms.
Hi,
I started to work on it. but I started from scratch for 2 reasons :
1/ I want to understand how the protocol works, it's important because there is no documentation available.
2/ The dev approach is very different : it's mainly based on libusb only and I try to implement the AA protocol without dependency with the underlying transport.
I plan to open code but now it's just too early. Sharing knowledge is a good start.
The Android headunit source code is very helpful to understand the protocol. Thanks for sharing the code.
So far what is done :
-100% asynchronous processing of usb transport so the thing is fully event based. It seems that the code becomes less messy this way and asynchronous programming model fits well with libusb.
-switch to accessory mode works
-ssl handshake is ok so the init phase of the protocol is working
Now I just got my first encrypted message from the phone. Encryption is not a big deal. I think I will be able to capture the first h264 buffers end of this week.
I imagine RaspberryAuto (codename for now) could run on a very lightweight JEOS style Linux with readonly flash filesystem. I will take look at the Openelec project which leverages this kind of system. I never developed UI for RPI, that's the main pain for me.
As it is a 100% C program it won't need a lot of RAM so the cheapest Raspberry model could be enough. H264 is not a problem as RPI supports hardware decoding. I'm a little bit more worried about the cost of the SSL processing (I don't know if the PI processor is good enough for that.
So why a PI ? Simply because it's open and documented, it's fast for h264 decoding, it supports composite output so it can be connected to the factory head unit of a car. Another interesting point is the my code is working on Ubuntu Intel too so there will be probably more choices for the target device at the end of the story. But PI is just enough for this project.
marcjero said:
Hi,
I started to work on it. but I started from scratch for 2 reasons :
1/ I want to understand how the protocol works, it's important because there is no documentation available.
2/ The dev approach is very different : it's mainly based on libusb only and I try to implement the AA protocol without dependency with the underlying transport.
I plan to open code but now it's just too early. Sharing knowledge is a good start.
The Android headunit source code is very helpful to understand the protocol. Thanks for sharing the code.
So far what is done :
-100% asynchronous processing of usb transport so the thing is fully event based. It seems that the code becomes less messy this way and asynchronous programming model fits well with libusb.
-switch to accessory mode works
-ssl handshake is ok so the init phase of the protocol is working
Now I just got my first encrypted message from the phone. Encryption is not a big deal. I think I will be able to capture the first h264 buffers end of this week.
I imagine RaspberryAuto (codename for now) could run on a very lightweight JEOS style Linux with readonly flash filesystem. I will take look at the Openelec project which leverages this kind of system. I never developed UI for RPI, that's the main pain for me.
As it is a 100% C program it won't need a lot of RAM so the cheapest Raspberry model could be enough. H264 is not a problem as RPI supports hardware decoding. I'm a little bit more worried about the cost of the SSL processing (I don't know if the PI processor is good enough for that.
So why a PI ? Simply because it's open and documented, it's fast for h264 decoding, it supports composite output so it can be connected to the factory head unit of a car. Another interesting point is the my code is working on Ubuntu Intel too so there will be probably more choices for the target device at the end of the story. But PI is just enough for this project.
Click to expand...
Click to collapse
Great work, keep us updated I've just ordered a car with android auto but it would be great to have something affordable for my wife's car.
Juicie said:
Great work, keep us updated I've just ordered a car with android auto but it would be great to have something affordable for my wife's car.
Click to expand...
Click to collapse
Hello Juicie,
Yes my new car will come with AA support as well so I have lost some motivation to complete this work these last few days. I can share my code with anyone that would like to continue.
I will do my best to release an alpha version that will work on Ubuntu but there will be more work to do to use the h264 hardware decoding of PI.
wow! that sounds great!
This could get really interesting now that RPi Foundation have announced a touchscreen....
Hi,
I have good news. I have a prototype fully working on Ubuntu (screenshots attached). The rendering is very good and smooth. Nav is fully working.
Now we just need to port the code on the PI itself. I only used libraries available on the PI so it should be straightforward except for the rendering. For rendering I use gstreamer because gstreamer is portable and supports omx (hardware accelerated h264 rendering on the PI). I think I just need to set the PI omx decoder and sink into the gstreamer code to make it work. The tricky part could be to capture the touch events if the sink doesn't provide them itself.
Problem is I don't have a spare PI to complete the job.
hi,
That's really great news didn't expect such good progress!!
I do have a rpi and can test if you give me the app.
The problem at the moment is that I don't have an android device running lollipop..but I can try to find one
Sent from my GT-I9300 using Tapatalk
I'm going to follow this !
If you need someone to test feel free to ask !
Hi
I will try to build an image pour the PI asap then.But I will have to disable the touch events at beginning because the purpose is to port the code and use the omx decoder engine.. That's a first step.
marcjero said:
Hi
I will try to build an image pour the PI asap then.But I will have to disable the touch events at beginning because the purpose is to port the code and use the omx decoder engine.. That's a first step.
Click to expand...
Click to collapse
Where are you currently hosting your code?
Hi,
Sorry, I had already posted this on another section but I think this one is more appropriate and can't delete other post.
I have a Joying JY-NL124 android car radio, which does not have an accelerometer. I bought the Yocto 3d V2 http://www.yoctopuce.com/EN/products/usb-position-sensors/yocto-3d-v2 to see if I could get it to work with torque and other android apps for the track but although android sees the device the apps do not. I am not a programmer, but is there a way to get the apps to recognize an external accelerometer like some do for an external GPS?
Very interesting. I would like to know as well. It might also be usefull in navigation to get a faster direction orientation.
I was reading up on this again and this bit means someone with the know how would probably need to code something
The main advantage of this solution is that you don't need to install a driver to communicate with a Yoctopuce module, as the HID layer is always present. You only need to add our library, that we provide in source form, to your driving software for it to be able to directly talk to Yoctopuce modules.
Click to expand...
Click to collapse
Have you tried contacting them directly and asking if they can do this for you?
sinnedone said:
I was reading up on this again and this bit means someone with the know how would probably need to code something
Have you tried contacting them directly and asking if they can do this for you?
Click to expand...
Click to collapse
Uff, sorry for the late reply. Life has a way of getting in the way of interesting projects. I'm about to restart this project since I'm using the car a lot on the track. It's weird that the units don't come witha compass, gyroscope, accelerometer, etc, considering they are meant to be used in moving vehicles.
Definitely post up if you figure it out.
It would be nice to get it to work with Android as a whole. If that's the case you might need to talk to one of the ROM developers to see if it's something they can do ROM wise or even a custom kernel.(the kernel bit might be a little harder)
Did anybody get this right. It would be cool if these usb accelerometer could work in the apps
flash_xx said:
Hi,
Sorry, I had already posted this on another section but I think this one is more appropriate and can't delete other post.
I have a Joying JY-NL124 android car radio, which does not have an accelerometer. I bought the Yocto 3d V2 http://www.yoctopuce.com/EN/products/usb-position-sensors/yocto-3d-v2 to see if I could get it to work with torque and other android apps for the track but although android sees the device the apps do not. I am not a programmer, but is there a way to get the apps to recognize an external accelerometer like some do for an external GPS?
Click to expand...
Click to collapse
I'm very interested to understand whether this is possible as I am thinking about a similar setup. You tried the three Bluetooth tips in the roll up thread?
https://forum.xda-developers.com/an...roll-joying-2gb-sofia-mtcb-mtcd-tips-t3555249
"Bluetooth Tethering & BT Settings", "Difficult to pair BT devices" and "Modified stock bluetooth app to allow connection to all devices"
Have you tried external GPS for higher refresh rates or is the Head Unit gps refresh good enough for the track?
Bob
MX5DrIver said:
I'm very interested to understand whether this is possible as I am thinking about a similar setup. You tried the three Bluetooth tips in the roll up thread?
https://forum.xda-developers.com/an...roll-joying-2gb-sofia-mtcb-mtcd-tips-t3555249
"Bluetooth Tethering & BT Settings", "Difficult to pair BT devices" and "Modified stock bluetooth app to allow connection to all devices"
Have you tried external GPS for higher refresh rates or is the Head Unit gps refresh good enough for the track?
Bob
Click to expand...
Click to collapse
Sorry....USB not Bluetooth... Also discouraging. I was hoping USB would be an alternative to BT for track add-ons...
I too have an Android head unit and do track days, and have the exact same interest as you. I use Harry's Lap Timer. I have the Pumpkin AE0273B head unit. It too lacks the compass and accelerometer. I too found this to be a very unfortunate omission.
I have developed apps actually so I do know Android program to some degree (although I am sortof a hack, not a pro). I have apps on the Play Store (since I can't post links just search Play Store for developer JimRoal). I saw the Yocto stuff. When I get some time I will look into this some more.
Any update on this? Would also like to add a compass / accelerometer to my joying.
Also interested. But on a newer 10.0 unit. Something I am going to look into.
nFiniti said:
Also interested. But on a newer 10.0 unit. Something I am going to look into.
Click to expand...
Click to collapse
Sad that over 4 years after I first posted this we still don't have a unit with these features. I finally gave up and bought an AIM Solo 2 DL.
I'm looking for a newer radio though, since mine is older than this thread
Still waiting as well.
Looking forward for solution, we have also WIMOTION sensors in the market with sample android apk but I'm not a developser so, put things together is hard for me !
I think the hard job is try to mock the sensors in Android AS IF external accelerometer was factory embeeded (allowing apps to recognize it)
Nothing new about this project / idea ???
?? dead ???
mariodantas said:
?? dead ???
Click to expand...
Click to collapse
Once you've figured out how to modify the kernel, you should be good to go!
Another option could be sensor to serial over USB, via a compatible adapter, write an app and there you go. Of course it won't be standard Android though.
Drivers are here
https://elixir.bootlin.com/linux/v4.14.133/source/drivers/iio/imu/st_lsm6dsx
The problem is adding them to kernel !
You dont need to add them to the kernel. You will need to implement an Android HAL that can read the values of these sensors. Its not a trivial task but also not very hard if you have access to the source code
Hi Guys,
This was previously posted in the assist forum but was recommended I try here.. I build custom automotive interiors and have in the past 5 years integrated dozens of android and ios systems into cars. I'm trying to figure out a way to skip all the fabrication of dash bezels by directly integrating into the existing factory lcd touch screens.
I would like to use the existing touch screen in my Ford Edge to interface with an android tablet.
Ideally I'd like to take an existing tablet or phone that I own (Galaxy tab 2 10.1 or Galaxy s4 phone) and send the touch and video information to my stock Ford Screen
CarPerformance .se has a kit that includes an android system with a board that switches the source being sent to the screen with the push of a button allowing you to switch between the Ford information screen, android computer with touchsceen interfacing and video inputs
below is a link to the install instructions and a video of its operation
carperformance.se/wp-content/uploads/2016/05/My-ford-touch-Android-install-manual.pdf
carperformance.se/?product=2001-2014-ford-edge-android-system
(links are broken because I'm too new to post links)
I would like to know if there is a prebuilt video switcher similar to the one above that would allow me to switch between sources and woulld allow me to connect one of my android devices
The reason I want to do this on my own instead of ordering the above product is that it runs older android software and does not have cellular capability.
if someone could point me to the right information I would greatly appreciate it as I'm sure these screens are fairly universal however I don't know what exactly to search.
Hello, I am looking for the same!
Have you been successful in your search of integrating Android into Ford? I have Lincoln MKX with older Sync 2 unit and really disappointed when found out that I won't be able to update to Sync 3 with Android Auto. Please let me know if you found anything good in this matter.
Thanks brother