Negates the need for a "CarPlay supported™" car, and runs the CarPlay UI directly on top of SpringBoard on an iOS device.
Works great for iPads mounted on the dash!
Note: This is primarily meant for an iPad, and iPhones aren't really supported (however you "can" use it with an iPhone 6 Plus if you really want to).
Also, I'll be sure to do a formal write-up on how it all works once all of this is finished and useable.
Vroom vroom.
To be honest a lot of this nonsense could be completely avoided if a secondary "fake" FBSDisplay could be created and then used. That way SBApplications could create / own proper carScenes and there'd be a lot less things that were broken...
Most of the CarPlay checking logic involves checking for both multiple UIScreens, the UIScreen interfaceIdiom, and FBSDisplay -> FBScene lookups. However, creating a fake FBSDisplay requires creating a fake CADisplay which isn't a lot of fun :P
Basically here's how it works (I think... some parts are probably wrong or off):
FrontBoard associates one FBSDisplay as the main display and has a bunch of FBScenes which are each SBApplication's mainScene. Once there's a second FBSDisplay available it can then generate a carScene for each SBApplication who's deemed capable. These carScenes would then be presented onto any externally connected screens (secondary FBSDisplay).
Originally, I had tried high-jacking a FBSDisplay whenever it was created and just duplicating that screen into a secondary FBSDisplay object with the same CADisplay object... and then shoving that FBSDisplay object into it's own lookup table to make it appear as if multiple screens were available. However. this causes UIScreen to freak out as it deems both those screens as the same. Also loads of the OS did not like this :P
What I'm doing is just making all UIScreens appear as CarPlay screens as well as forcing all applications to render in landscape (as CarPlay on external screens is forced to portrait). In addition this means that each SBApplication's carScene is the mainScene, which doesn't guarantee success.
Creating a local AirPlay server and then hacking touches to work on a view (who's contents are a secondary screen projected locally, using the device to AirPlay + mirroring) could be a neat solution to this, but I haven't tried it yet. That would grant us a legitimate second FBSDisplay to play with.
I used Theos for this. You'll need to install them and setup the appropriate environment variables etc as well as configuring. Info on that here.
ARM64 support is enabled by default and if you need help setting that up check here.
I'm using my own fork of theos, which is in-turn forked from @rpetrich's fork.
If you edit the Makefile you can specify your iOS device's ip and such to build and run using make package install. Otherwise you can simply make package to generate a .deb file and install that by any means.
Totally free! If you'd like to support my continuation of this project (and others!), feel free to donate! It'd be much appreciated :D
Pretty much the BSD license, just don't repackage it and call it your own please!
Also if you do make some changes, feel free to make a pull request and help make things more awesome!
Feel free to follow me on twitter: @b3ll!
Though I don't really like to handle support requests there...
Travis Beckham for the vectorized car image!
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent