Database Develop

Kali OS for our Raspberry

What you guys think about it?
I gonna try it - this night I want to download an .img file for raspberry and also .iso for normal computers
Website: http://kali.org/
Download: http://www.kali.org/downloads/ (you need to chose armel architecture and then Raspberry PI version)
About (docs): http://www.kali.org/official-documentation/

Yeah I saw this also, it will be fun to use but it will not be good for cracking passwords fast because of the raspberry pi's hardware. Might test it out on mine soon

Informations from me (will be keep updated):
Didn't try the special applications yet, but I feel it boots much slower than Raspbian. Reading package lists is slower too, but it's prolly because of more apps on list, so it's possible to fix.
Use Thunar file manager - it's much faster than the second one.
Midori is shutting down without any reason.
3.8GB of SD card used after writing it (checked in file manager).
Chromium doesn't work at all.
Already decided to stop using it, just need to test tools now...

I installed it , but how do I connect to the internet? I dont see any wifi scanner to find a network.
Also i went to the command prompt and is not readying my usb wifi adapter... doesnt find wlan0
Sent from my SPH-L900 using xda app-developers app

I connected it with ethernet cable so I didn't have such a problem.
It's strange that kali doesn't see a wificard - it has many built-in drivers. Maybe you are searching wlan0, when it's for example wlan1? Did u use ifconfig and iwconfig?

From my understanding the rPi does better with hf than it does el, so it seems that if Kali OS could be compiled for the rPi using armhf instead that the performance might be better overall than running an armel version. On that note, you won't see the same speeds as a Raspbian distro merely because it is using armel compared to Raspbian which uses armhf.

[Q]Possibility of Playing Other Media Types

So, got a question...
How hard would it be/would it be possible to cross-compile a media player for the cc (something that can be run from CLI like vlc), put it on an external storage device (if cc recognizes a connected USB device while the rom is running - maybe eureka rom, bhiga?), mount a samba share, and play a wider variety of movie formats.
So the solution would look something like this...
1. Put vlc binary on flash drive connected to cc via powered OTG cable
2. Ssh in to cc
3. Mount network samba share containing videos
4. Play whatever videos from vlc operated by cli over samba, replacing dial
Not really a programmer, and have absolutely no idea how a cc works... But it seems to me that a solution like this, while unwieldy, would allow one to bypass the limitations of cc's implementation of dial.
What do y'all think?
Sent from my SCH-I535 using XDA Premium 4 mobile app

And what about other binaries? Something like apache, php... Maybe turn the cc into a cheap webserver?
Sent from my SCH-I535 using XDA Premium 4 mobile app

I think one of the Team Eureka folks said the USB storage isn't available at normal runtime, but I could be mistaken.
Webserver is definitely possible, as that's what the Eureka Web Panel is, but general-purpose webserver use would be limited by both wireless bandwidth and moreso by the lack of storage (unless USB actually does work),
An important thing to keep in mind here... Unlike Android phones, tablets and TV sticks, Chromecast is much more scaled down and limited in design. I consider phones, tablets and TV sticks as Android-powered devices with the qualification that they are meant to be interacted with, apps installed, expanded, etc.
Think of Chromecast it more of an "accessory," black box or dumb terminal. Chromecast is more of an "extension" to those user-configurable devices.
Remember the ViewSonic AirPanel? Technically it is a computer, but a very limited (embedded) one. While it mirrored the primary screen of the computer, rather than being a second screen, it's a similar model. The AirPanel has some intelligence to accelerate the user experience but the core processing is done on the computer it's attached to.
Neither AirPanel nor Chromecast are meant to be interacted with directly at the device level, or loaded down with a lot of background processes. Chromecast doesn't have an interactive UI of its own, nor does it have external input (keyboard, mouse, touchscreen, etc) like your typical Android device does.
I wouldn't surprised if a number of "standard" libraries that your typical Android platform has simply aren't there.
I'm not saying getting VLC on it is impossible - I really don't know, but I do think it's improbable and would require a great deal of effort.
Without hardware acceleration or SDK/API support, you're relying purely on the software processing, and I haven't found much in the way of detailed specs on the platform itself. I have seen mention of the platform supporting other compression formats that Google isn't supporting yet, like MPEG-2, so it remains to be seen what Google's long-term plans are.
Not trying to be a downer here, just trying to keep things in perspective. After all, Google didn't sell us a $35 PS4 equivalent.

bhiga said:
I think one of the Team Eureka folks said the USB storage isn't available at normal runtime, but I could be mistaken.
Click to expand...
Click to collapse
So, if I'm understanding correctly, this sounds like a software limitation...Clearly the hardware is compatible - Flashcast relies on it. I don't know much about the intricacies of programming for mobile devices, but conceptually it would seem possible to make usb accessible during normal operation if it's accessible to something like Flashcast. I would love to read up on Flashcast more...it's just that normally things like flashcast which are very specific to certain hardware and require exploitation of particular holes/flaws in the software residing on that device are not normally very well documented.
How is it that Flashcast "unlocks" the functionality of USB OTG, and what limits its use when the device is booted normally? Is it something in the bootloader? Does Flashcast "hijack" the bootloader and use a different one?
EDIT: Or even how about something like this: Create an image like the recovery image that's flashed to a USB Drive, except make the "recovery image" a full ROM. That way, ROM gets access to USB device, we have much more room to put other features/binaries, etc, and then there's built in storage...Would something like that work?

tomg09 said:
How is it that Flashcast "unlocks" the functionality of USB OTG, and what limits its use when the device is booted normally? Is it something in the bootloader? Does Flashcast "hijack" the bootloader and use a different one?
EDIT: Or even how about something like this: Create an image like the recovery image that's flashed to a USB Drive, except make the "recovery image" a full ROM. That way, ROM gets access to USB device, we have much more room to put other features/binaries, etc, and then there's built in storage...Would something like that work?
Click to expand...
Click to collapse
As I understand things, FlashCast runs in recovery mode, which uses its own bootloader - which is what allows access to OTG.
If that code isn't in the normal mode bootloader, then OTG won't be accessible. It might be loadable via a kernel module, but it seems the current Android direction is to disallow loading of kernel modules (probably because it's a potential security hole).
There's more information about how and why FlashCast works in the FlashCast thread.

[Android 4.1+] Headunit for Android Auto - 160117 - Self Mode+ other fixes, x86, 720p

"Headunit": The First, Best, and Only Headunit app for Android Auto, Now Open Source & Free !
Turn an Android tablet into an Android Auto compatible Headunit ! (With several limitations at this early time of course...)
Android N developer preview: http://forum.xda-developers.com/showpost.php?p=65749262&postcount=1165
If you purchased Headunit on Play before Google removed it: http://forum.xda-developers.com/gen...droid-auto-t3125252/post65015637#post65015637
160117 January 17: New Self mode & Car mode fix: http://forum.xda-developers.com/gen...droid-auto-t3125252/post64844560#post64844560
151224 December 24: 1280x720 and X86 support: http://forum.xda-developers.com/showpost.php?p=64466237&postcount=943
151128 November 28: Voice Input + Audio Output: http://forum.xda-developers.com/showpost.php?p=64045807&postcount=903
August 28 & 5 Voice Input etc: http://forum.xda-developers.com/showpost.php?p=62548380&postcount=724
USB OTG Y cables I've had success with: http://forum.xda-developers.com/showpost.php?p=62745966&postcount=792
Comments welcome: Proposal for a Private Website / Forum for the Headunit app and Automotive Android: http://forum.xda-developers.com/showpost.php?p=62207324&postcount=587
July 24 APK Immersive mode: http://forum.xda-developers.com/showpost.php?p=62014837&postcount=519
July 14b APK Standalone mode: http://forum.xda-developers.com/gen...oid-4-1-headunit-android-auto-t3125252/page43
July 11 APK: http://forum.xda-developers.com/gen...oid-4-1-headunit-android-auto-t3125252/page39
Quick summary of Google Play bans and final responses; I fixed each time & Google gave a different excuse each time: http://forum.xda-developers.com/gen...droid-auto-t3125252/post61632463#post61632463
Nexus 9 OTG charging w/ M developer preview & Nexus 7 2013 w/ Timur kernel/mods: http://forum.xda-developers.com/showpost.php?p=61632651&postcount=312
Nexus 7 2013 OTG charging while running Headunit w/ ElementalX kernel: http://forum.xda-developers.com/showpost.php?p=61593874&postcount=290
Now Open Source and Free ! http://forum.xda-developers.com/gen...droid-auto-t3125252/post61440441#post61440441
June 16 Release #5 APK: http://forum.xda-developers.com/showpost.php?p=61422602&postcount=163
Release #2 APK and instructions: http://forum.xda-developers.com/showpost.php?p=60894402&postcount=94
Thank you "All About Android" for covering the Headunit app in episode 218 ! http://forum.xda-developers.com/showpost.php?p=61412309&postcount=152
Android Auto over WiFi Direct is coming: http://forum.xda-developers.com/gen...oid-4-1-headunit-android-auto-t3125252/page16
June 16 APK: http://forum.xda-developers.com/gen...oid-4-1-headunit-android-auto-t3125252/page15
June 12 APK Auto-Start: http://forum.xda-developers.com/showpost.php?p=61321219&postcount=107
June 11 APK: http://forum.xda-developers.com/gen...unit-android-auto-t3125252/page8#post61287292
June 9 APK: http://forum.xda-developers.com/gen...roid-4-1-headunit-android-auto-t3125252/page5
Android Auto is Google's latest and greatest effort to provide automotive navigation, music, phone and other features in an environment that minimizes distraction.
The Headunit app is intended for 7 inch /17 cm or larger tablets.
A $100-200 Nexus 7 tablet mounted in the car is MUCH cheaper than $700-$1400 Pioneer devices.
A $300+ 10 inch/25+ cm tablet provides a much larger & nicer screen than 6 inch double-din units.
Original XDA Thread: http://forum.xda-developers.com/android-auto/android-auto-general/developer-mode-aa-t3059481
These are early, experimental releases. They should only be used for testing at this time.
Please note that Google has NOT released Android Auto specifications required to build a Headunit app such as this, except to headunit and auto OEMs who have paid fees and signed NDAs.
This app required over 500 hundred hours of painstaking reverse engineering (and many more to come), and another 500 or so as of mid July to build and test the app so far.
If you wish for apps like this that are professionally engineered, supported and updated, your financial support via Paypal donations is required, especially since Google will not allow Headunit apps on Play.
Help keep an independent developer working full-time++ on this cool new stuff.
Thanks for your support !
Mike.
What the heck is Android Auto, and why would I want it ?: http://forum.xda-developers.com/showpost.php?p=61114397&postcount=2
What devices and ROMs are supported ?: http://forum.xda-developers.com/showpost.php?p=61114397&postcount=3
How do I use the Headunit app?: http://forum.xda-developers.com/showpost.php?p=61114419&postcount=4
Troubleshooting: http://forum.xda-developers.com/showpost.php?p=61114437&postcount=5
Supported Phones running Android Auto: http://forum.xda-developers.com/showpost.php?p=61114468&postcount=6
Business Issues: Open Source & Pricing: http://forum.xda-developers.com/showpost.php?p=61114482&postcount=7
Feature Requests: http://forum.xda-developers.com/showpost.php?p=61114494&postcount=8
Coming Features: http://forum.xda-developers.com/showpost.php?p=61114500&postcount=9
Future of Android Auto: http://forum.xda-developers.com/showpost.php?p=61114532&postcount=10

What the heck is Android Auto, and why would I want it ?
Introduction / Different approaches:
There are many different approaches to running apps in a car, and they each have advantages and disadvantages.
Many people are happy to just install an Android tablet or Android based headunit and run apps much like they do outside of the car.
Others may mount their phone on the dash and use Android as they always do. They may plug it in to charge and might pair the phone's Bluetooth with their existing in-car audio system.
If you are using approaches like these, and you are happy with them, that's great ! I'm not a mission to convince you otherwise if you have decided these methods are best for you.
Android Auto:
Android Auto (AA) is Google's latest and greatest effort to provide automotive navigation, music, phone and other features in an environment that minimizes distraction.
AA was announced in 2014, and it's "app" first publicly released March 19, 2015, after Pioneer starting selling their AA compatible 4100/7100/8100-NEX headunits. Google did not seem ready to launch AA at that point, but Pioneer's early release of headunits seems to have forced this.
Apple has it's own rough equivalent to AA called Apple Car Play. Many who have seen both prefer AA, but iOS users also appreciate having more or less the same iOS UI they already know in their car.
How AA works (basic):
AA is not a mirroring solution like MirrorLink, Miracast or Apple Airplay. Mirroring solutions simply send phone screen video to an external, larger screen and return touch events. Thus the in-car screen is simply a blown-up version of the phone screen.
Mirroring solutions generally work with all existing apps. AA on the other hand, requires Android apps to have special AA compatible extensions added. Clearly this can be a disadvantage of AA. Few music and messaging apps can be used with AA, and the only mapping/navigation app supported is Google's.
With AA, Google mostly controls the User Interface (UI) as implemented in their AA "companion app". AA compatible apps CAN modify some of the color scheme and some related minor UI features, but the look and feel are largely Google designed and controlled.
Google has done this to minimize distraction. Although many of us will not be happy with Google's decisions. we should consider that the last things Google wants are: (1) laws against Android Auto, (2) bad publicity from distracted driving incidents, and (3) expensive lawsuits. Note that Google, Apple and the auto OEMs are reportedly negotiating who takes how much responsibility for the inevitable lawsuits, particularly in the US where multi-million dollar settlements regularly occur.
Google AA supports two types of AA compatible apps at present, with more (eg maps/navigation ?) coming in future: (1) Audio/music and (2) messaging. For the most part, audio/music AA extensions provide functions for starting/stopping/nexting/etc of the audio as well as functions to determine the music navigation hierarchy. Messaging AA extensions include sending a message to AA to be converted to speech as well as handling spoken replies.
Video and gaming apps will likely never be supported for the drivers position, at least while driving, for obvious reasons.
Many app developers are hesitating at this time to add AA extensions. At this time, there is very little revenue to be made by supporting AA (and the same has been seen for watch and TV apps). This should improve as more cars have AA installed, via OEM systems or aftermarket headunits.
So why would I want AA ?:
If you need access to ANY Android app, and not just the limited selection of AA compatible apps, then mirroring solutions will work better for you.
AA is more for people who want a solution that "just works" (although there are still many wrinkles to iron out), is well integrated, and has a common Google specified UI.
Less technically minded people will appreciate AA or Apple CarPlay, while Android power users may be happier with mounting a tablet or using an Android based (usually Chinese) HU.
An Android based HU which can run my Headunit app, may offer the best of both worlds. You can run any Android app when you need to, or run my HU app to get AA features. (At present nobody has reported success running my Headunit app on an Android based HU. I hope/presume I'll figure that out.)
I am personally convinced that AA will be very important for Google going forward. Controlling and getting the treasure-trove of data from connected cars is important to Google. We may not be far from the day when Google will get a commission when it successfully convinces us to pull over for specific fast food or auto maintenance. Want fries with your oil change ?
Because AA is important to Google, I feel confident it will not be abandoned, and will only get better as the years tick by, bugs are fixed, apps are AA enabled, etc.
Getting AA working:
Please, always do your best to drive responsibly and with a safe minimum of distraction. You assume all liability for following any of these or any other instructions.
First, your phone (or tablet) needs the AA companion app installed. US residents can install the Android Auto app from Play: https://play.google.com/store/apps/details?id=com.google.android.projection.gearhead and those outside the US can find APKs here: http://www.apkmirror.com/apk/google-inc/android-auto/ .
Next, you need an AA compatible aftermarket or auto OEM headunit. Auto OEM AA headunits (HUs) are just starting to come out for a limited selection of 2016 models. Aftermarket HUs like the Pioneer 4100/7100/8100-NEX devices are a good alternative. If a $500-700 HU is too expensive for you, that's where my Headunit app for tablets comes in, but there are some inherent disadvantages to such an app and a tablet is just one of the costs. More on this further below.
Ensure that your mobile device running the Google AA companion app is setup with a Google account. Make sure the Google apps are up-to-date, including the AA app, Google Play Services, Google Maps, and Google Play Music.
Now plug your mobile device USB into the HU. If all goes well you should see a series of prompts and screens on the HU and mobile device. If something complains that it's not safe to configure at this time, ensure your car is in the Park gear (or neutral for manual), that the emergency/parking brake is fully engaged, and press down on the brake pedal. My 4100-NEX is setup for testing, outside of a car, and I simply connect the green wire to ground or 12 volt negative line. I'm not sure that this will work well if your HU is installed such that the green wire is connected to other things.
Hopefully you will now see the main AA Intro/Google Now Screen. Select functions from the "rail" at bottom of screen: In order: Maps/navigation, Phone, Google Now, Music, and "Other/OEM".
Your mobile device should show a mostly black AA screen indicating the device is in AA/car mode. You CAN escape this and run other apps, but it is not recommended.
While your mobile device is connected via USB, it should charge. Turn the device screen off to maximize charging and minimize heat build up. Using Maps/Navigation will use the device GPS (unless the HU provides it) and this contributes to heating of the device and minimizes charging.
How AA works (technical):
Basically, the AA app creates a special environment in which it draws to a virtual screen instead of the real screen. The resulting video is encoded as an H.264 stream and sent via USB to the HU. The HU responds with touch-screen events which the AA app interprets similarly to normal Android app operation.
AA compatible audio apps contain AA audio extensions, which can provide control of audio app playback and provide information about which audio streams or files can be played. The audio app uses it's normal Android audio APIs, which the AA "app" hooks in order to send the audio to the HU, over USB or Bluetooth. I refer to the AA "app" with parentheses, because it has many hooks into Android internals which normal apps do not have access to. Thus, much of the AA "app" is really system level code, though there is a minor UI for some basic configuration and to provide access to AA developer mode functions.
The AA USB protocol also includes functions for accessing sensors, including parking brake status, gear position, fuel tank level, road speed, engine speed and many more. Only a few sensor functions are fully implemented at this time however, such as parking brake status to determine if it is safe to do configuration.
Google has referred to AA HU's as "dumb terminals". But IMO a true "dumb terminal" would simply be a touchscreen with a DVI/HDMI like interface. AA HUs DO need to have some "smarts", such as H.264 video decoding, Bluetooth and sensor signal processing.
Hardware HUs also generally provide many other functions that work standalone with no mobile device, such as AM/FM/HD radio, CD player and vendor specific apps that run on the HU.
Why would I want your Headunit app ?:
- For the customization opportunities.
I haven't seen any 10 inch / 25 cm screens on auto OEM or aftermarket HUs. Large tablets however are readily available with many choices for screens and other hardware.
- To use or experiment with Android Auto without buying a new car or a $500+ hardware headunit.
Note however that besides the tablet, you may also need a USB OTG Y cable and a powered USB hub in order to properly charge the mobile device, and tablet, without running down the tablet battery.
Some devices (for tablets, mostly non-Samsung) may need special kernels in order to charge while acting as a USB host.
Why can't we just run our phone in an AA standalone mode, without tablet or Headunit ?:
Mostly because Google does not want that. They consider screens under 7 inches / 17 cm to be distracting. Google seems to eventually want "Android in the car", so Google may be working on something like a standalone mode (for what would essentially be an Android tablet in the car), but this is nothing but rumours so far.
I know a LOT of people would REALLY like a standalone mode, so I am likely to explore the feasibility of this in the near future. I am sure that Google would disapprove of this and would eventually take measures to sabotage such a thing, so it's a tricky prospect.
I think an AA standalone mode "app" (more like system mods than an app, same as AA "app" itself) would require a rooted device. It likely would also require Xposed (or similar) to hook and modify various system functions.
Add it all up and it turns into a very difficult venture with limited returns on time invested.
A Headunit app running on a 2nd device/tablet is more feasible as Google can not just change the AA protocol overnight, and it does not require root on the tablet (except for charging of non-Samsung tablets, sigh...)
Are there any other AA compatible Headunit apps ?
At this time no, my Headunit app is the first and only of it's kind.
Google has not publicly released documentation or code to build a Headunit app, and may never do so.
It has so far taken me over 600 hours of work to reverse engineer the AA protocol and build this app. With open docs/code it might have taken only 100-200 hours at most.
I've read a report that Google must certify AA HU implementations before they are "allowed". This is likely part of the agreement and NDAs that auto and HU OEMs must sign to join Googles "Open Auto" alliance, beyond whatever fees are charged.
GENIVI appears to have plans to "open source" an AA client implementation. But AFAICT, GENIVI "open source" is not entirely public and open. I suspect Google would want to ensure that any users of such source code adhere to their requirements.
Pioneer HUs run Android. Their AA client implementation is a binary, so it's somewhat similar to an HU app. But it's specific to their hardware and will not work on general purpose Android tablets or phones.
There may be other Headunit apps to come, but I have not heard of any, beyond one persons desire to create an open source app in the long term.

What devices and ROMs are supported ?
Root is NOT required. (But root and a custom kernel may be needed on non-Samsung tablets in order to allow the tablet to charge while it's in USB host mode.)
Most Android 4.1+ ROMs should be able to work.
ICS 4.0 and earlier devices/ROMs do not have the needed video decoder and can never work. (Except by building my own decoder with FFMPeg or whatever, which is way too much work for too little return.)
A working H.264 video decoder is required, but most quality Android 4.1+ devices should have this. (Chinese/budget devices may use slow and/or buggy implementations.)
Only devices that support USB host mode are physically capable of working. Many or most tablets released in the last 2 years should support USB host mode.
Full, official support is limited to devices I own. With sufficient demand for a new device, I may purchase that device and add official support, if possible.
These are the tablets that I own and test:
Nexus 7 2012 stock.
Nexus 7 2013 stock.
Nexus 9 2014 stock.
Xperia Z2 Tablet stock. CM12 tested OK too.
Many other devices will work and I will do my best to support them.
Phones can work as a headunit, but tablets of 7 inches/17 cm or greater are recommended. Smaller screens are more distracting and can risk your safety.

How do I use the Headunit app?
At this time I can't recommend this for use while driving. It's ONLY for testing within the safety of a home or office... If you can't understand that this Headunit app is still VERY experimental and potentially very distracting while driving, then please don't run it. It's not my fault in any respect or measure if you hit a tree or kill people; it's ALL on you... You assume all responsibility for collisions, injury or the advent of Skynet...
App requires Android 4.1 ICS or higher, but I've mostly tested on Android 4.4 KK, 5.0 and 5.1 Lollipop..
I tested successfully on these, for the Headunit/Tablet side running my app:
Tablets are recommended for a decent size screen in a vehicle:
Xperia Z2 Tablet - CM12 - This 10" screen is wonderful compared to the 7 inch/17 cm 800x480 Pioneer 4100-NEX screen, despite that the video is still only 800x480 at this time.
Nexus 9 - stock - This looks pretty nice too and the CPU power helps make it look good and pretty lag free.
Nexus 7 2013 - stock
Nexus 7 2012 - stock
Phones can also work, but small screens are less safe so I can only recommend these for testing:
HTC One M8 - stock
HTC One M7 - CM12
HTC One XL - CM12
Xperia Z - Lollipop
Xperia Z1 - CM12/FXP
Moto G - CM12
GT-N7100 Note 2 - CM11, but with some video issues.
These phones have major issues or did not work for me:
GT-I9300 GS3 - CM12 unofficial
GT-N7000 Note1 - CM11
GT-I9100 - Android 5.1 ROM
GT-I9000 - Android 5.1 ROM
Note that Headunit/Tablet side issues are largely separate from Phone/Mobile Device side issues. Phones that do not work with Pioneer or other AA head units will not work with this app either, and only Google and the phone OEMs can fix that. This includes MANY very popular Samsung devices. I note that my older Samsung devices also have issues on the Headunit side, and this may be related to general USB issues on Samsungs. (?)
The Headunit/Tablet side running the Headunit app needs to connect to the phone running AA with a USB OTG cable. The OTG cable small micro-USB side needs to plug into the Headunit side.
Many devices can do USB Host for the Headunit side, but can't supply any power to the phone. For these devices a powered USB hub is required, and is recommended for all devices anyway, or the Tablet/Headunit device will quickly lose power to running the phone device.
The phone running AA plugs into the USB hub output side, and should be the only device so plugged in (or the device my app connects to will be random-ish, with HTCs having highest priority.)
When they are all plugged, be patient and wait at least 6 seconds after plugging the USB before starting my app. Most likely the Gallery app will open on the Headunit side. This is annoying, but at least it confirms the connection is good. You may have to wait, then hit Back to exit Gallery. If you get any popups, hit Back or Cancel; you might get several.
Latest AA companion apps to run on the phone side are here: http://www.apkmirror.com/apk/google-inc/android-auto/ This requires Android 5.0 Lollipop+ on the phone side as per Googles' decision, and also requires Google Mobile/Play services to be installed and an account set up.
Now you can start the Headunit. You should be prompted to allow access to USB twice. Select OK both times. Don't bother to check the "Remember" box because it never works and it's a silly Google thing. Better solutions are possible, especially if rooted.
If you have never connected the phone with AA to a headunit before, you will be prompted to do a bunch of stuff on the phone side. If you are outside the US you must manually update to the latest AA app from APKMirror etc. You may have to download Maps and Play Music if you don't have yet, and say Yes or "Standard" etc, to various prompts.
After all this, hopefully you will see video on the Headunit screen. You will likely see a safety warning prompt etc. Read it and understand it, and select OK if you dare.
Hopefully you will now come to the main/home/Overview/Now screen of AA. On some devices, video may be imperfect. Select different functions on the "rail" at bottom to help clear it up.
Touch works, but not Multi-touch yet.
Audio output was through the phone last I looked, but microphone does not work.
If you hit Back while in the app, it should exit and the AA connection is broken.
To open a new AA connection/restart the app you MUST disconnect and reconnect the USB, at any point in the chain.
It generally seems possible to turn the screen off and return to it after powering it back on, but if the orientation changes from landscape this may not work. Same for leaving the app with the Home or Recents button; if it switches to portrait, you can't get the video back and must stop the app, reconnect USB and restart the app.
I'm finding that quite a few of my phones running custom ROMs will not run AA on the phone side properly. In some cases a custom DPI really messes up the video dimensions and you can't even select the startup OK button. I see this on my One M7 with CM12 and many people see the same on other phones w/ custom ROMs, whether using a Pioneer headunit or this app.
Enjoy responsibly.

Troubleshooting:
Nothing more disheartening than trying a cool new app, and.... it doesn't work.
Public Enemy #1: Cheap/Bad USB OTG cables.
I got 3 cheap OTG cables and 2 straight and 2 right angle adapters a few months ago. The cables seemed OK in the beginning and now they're all flaky. The adapters didn't last as long and some were flaky new. 7 cables and adapters and they're all garbage.
I've been happy for a few weeks at least with these $10 Y cables that can power/charge both devices. I'll see if they're still good in the next few months: http://www.amazon.com/Micro-Cable-Power-Samsung-AtomicMarket/dp/B009YPYORM
But even with the best cables, your phone and tablet micro-USB ports can be a factor too. Car mounting, with constant vibrations and bumps adds to the challenge.
When I get Android Auto over Wifi working better, I hope USB will just become a backup connection. But wifi has it's own issues too.
Cheap or Chinese devices and hardware HUs are a "crap-shoot": So far I don't think I've had a single success report for Chinese devices. The ROMs and video decoding are often bad or VERY slow and USB is questionable. Some devices do not support USB Host mode or have a bad software implementation.
I recommend Nexus or good quality tablets from Sony or maybe Samsung. All tablets that I own work and are officially supported, including: Nexus 7 2012, Nexus 7 2013, Nexus 9 and Sony Xperia Z2 tablet.
July 24 or later releases recommended for testing: http://forum.xda-developers.com/showpost.php?p=62014837&postcount=519http://forum.xda-developers.com/gen...oid-4-1-headunit-android-auto-t3125252/page39
July 24 has a bottom "Test" button to test H.264 video decoder (some phone/ROM decoders are bad or VERY slow.)
Also has a bottom "SUsb" button for devices with USB Host Mode supporting kernels even without Android support.
Also allows manual USB device selection when automatic doesn't work.
MANY possible fixes:
- You must have 2 devices for the Headunit app, so try reversing them to see if that works. This requires the Android Auto app and Google app, Google Play Music, Google Now and Google Maps to be installed on both devices of course.
- You usually need 2 cables: The micro-USB side of an OTG cable to the Headunit app device/tablet, and the full-size USB connection to a "normal" phone/USB cable connected to the Android Auto device/phone.
At least one person reversed the cables, without reversing HU and AA devices and it worked. USB can be funny; there are MANY possible jumper, resistors, wires etc combinations, especially with specialty high current charging cables.
- With some devices, an OTG Y cable MUST be powered, with others it MUST NOT be powered, and for some it doesn't matter and power can even be stopped and started with no effect.
- "Fast Charge" should be disabled if it's a kernel setting. Saw this with Elemental-X kernel on Nexus 7 2013. This kernel also has a setting to allow charging in USB Host mode.
- Sometimes enabling USB Debugging helps, sometimes disabling, sometimes turning it off, then back on. Do this at both ends: Headunit app device and Android Auto device.
- Unplug and replug cables, at both ends and in between. Ensure they are firmly pushed together. July 11 release allows you to see devices disappearing and re-appearing if cable connections are flaky and moved.
- Before starting Headunit app, plug all cables together. If Camera Importer or Gallery, or other apps pop up, hit Cancel or Back to deal with them first. Then after a few seconds of no more popups, NOW start the Headunit app. Plugging/unplugging while the app is running may work but is less successful than starting the app after plugging.
- Some devices/ROMs have various USB settings to try, such as "Charge Only", MTP, etc.
- Use the Exit button or Back key to terminate the Headunit app and try again. It kills it's own process for an extra fresh start next time.
- Use Recents button to return to the Headunit app if Android Auto covers it.
- Avoid screen switching to Portrait mode for best chances of success. Home-screens that force portrait mode can create problems, as can lock-screens.
- Self or SUsb modes require SU/root access. Sometimes the SU prompt is covered and not visible. In such cases manual SU configuration, or setting SU default to "Grant" can help.

Supported Phones running Android Auto:
Any phone that works with hardware headunits, such as Pioneer 4100/7100/8100-NEX, should also work with this Headunit app.
Note: This list is for devices running Android Auto. It is NOT for connected devices running the Headunit app, except for Self standalone mode where one device runs both.
Devices that I tested OK:
Galaxy S3 GT-I9300 CM12.
HTC One M7 stock & CM12.
HTC One M8 stock & CM12.
Xperia Z stock & CM11.
Xperia Z1 stock & CM11.
Xperia Z2 stock & CM11.
Moto G stock & CM12.

EDIT: I wrote this page before Google banned Headunit from Play and before I made it free and open source, but please feel free to read my thoughts written before that below.
Soliciting donations sucks. Thanks much to those that have and those that will. But VERY few people do. At some point I will likely have to return to a commercial model.
Those who donated, or bought Headunit on Play before the ban will become most honoured customers retroactively.
Business Issues:
Yes, I am (attempting) to run a business here. I hope I don't have to explain or apologize for trying to make a minimal income to help support my wife, kids, cats, pay for a house, cars, and all the usual basic accoutrements of life like food, electric, fuel, etc, etc...
I have been working 60-70 hour weeks for over 4 years now on my apps, mostly the Spirit FM apps: Spirit1, Spirit2, Spirit Transmit. I have no other income except my apps.
I am somewhat disappointed that I've been making a small fraction of what I made for decades doing contract or salaried work for a plethora of tech companies.
I have seen my Spirit FM income dropping for the last few years, and have entered into the connected car apps space in an effort to make a better income.
I hope to serve your app desires and appreciate the financial support of everyone who can afford at least roughly the price of a meal at McDonalds, or there-abouts.
Open Source:
Yes, I know EVERYONE wants free and open source software... I LOVE open source; my career has been built mostly on Linux (and Android) since 1997.
But NONE of the 20-odd companies I've done contract or salaried work for in those 18 years has open sourced their code.
Very, VERY few companies turn a profit with open source. How many app devs can you show me that make a decent living exclusively or primarily with open source ? Over 99.9% are based on closed source.
Kickstarter / IndieGogo etc ? LOL. Show me a lone app dev who has done well with that route.
If someone were to sponsor me with a decent income I'd be happy to open source everything. But that's not too likely and I'm not seeking that.
Google is keeping their AA code secret and unpublished, and they do the same with their premium apps like GMail, while the AOSP apps like EMail languish.
Pricing:
Pricing software is a funny thing. If no technical support or packaging are provided (and there are no advertising costs), the incremental cost of 1 more copy of an app is zero.
And yet if you hire people (or yourself) and pay a decent, competitive rate, the R&D costs for the 1st copy can be in the $millions for many modern apps.
There is no such thing as a "fair price"* for an app. Many think apps must be $0.99 for something simpler, or up to $10 for something more complex, and in rarer cases, $20-40-100 or much more.
(*Fair Price: If we talk about technical support, a "fair price" becomes more feasible. If my time is worth $60 per hour (and it should be much more in this field for very short term work), then 10 minutes of total time spent to support someone is worth $10. But that ignores ALL the time it takes to build and test apps.)
The number of people who will buy an app at some given price are a major determinant for a developer trying to make a decent living.
A popular non-root app for "Joe Average" that millions of people might use might be $0.99 or free with ads.
An app only for Android enthusiasts who root, ROM and install Xposed on the other hand will have a very limited market, and price must be high for a chance to make a decent living.
I've noted that there are several examples of specialist Automotive apps that sell in the $20-40 range. Then there are apps like Torque that may sell for $3-5 but have a much bigger market, and the income allows people to be hired, above and beyond supporting a single independent developer.
At this time, I've put this Headunit app for sale at less than $9 US or 8 Euro (after 20% VAT Euro prices are under 10 Euro, but I get none of that).
Note that Google takes 30% (42% markup !) so I only get about $6 US per app. That hardly buys a Big Mac these days...
My desire is to license this Headunit app on a per device basis, though Google doesn't provide any easy method to do so. So if you use this app in 2 cars, but with only one Play store purchase, I'd appreciate consideration via Paypal. There is NO DRM in this app and I REALLY hope not to use any form of copy protection. DRM is mostly trouble.
I reserve the right to change price at any time. As the app becomes more fully featured, I may raise the price as needed to get sufficient income to work on this full time.
Without sufficient financial support, I'll just have to spend more time on other app opportunities. So if you use and like this app (or just want to support such) please support me so I can support you.
And please help spread the word about this app. I'd rather spend time working on wonderful new features and fixing bugs (LOL) than spending time doing marketing stuff, or spending/wasting money on advertising.
Thanks !
Mike.

Feature Requests:
I'm always happy to hear what you want.... Speak up !

Coming Features:
(Originally written in June. Amended August.)
Features I guarantee I will try to added in the relatively short term of 1-3 months:
- Automatic start at plugin.
- Bypass USB permissions with root. (July 24 "SUsb" button)
- Multitouch support (pinch zoom GMaps)
- Resolution increase & switching, if possible. 800x480 at present, 1280x720, 1920x1080. (July 24 still does not seem possible. No hardware HUs higher than 800x480 so Google hasn't enabled ?)

Future of Android Auto:
Built-in, Brought in, Beamed in.
Android in the car
Self driving cars
Flying cars
Skynet^H^H^H^H^H^H

"Headunit" - Build an AA Headunit with a $165 tablet...
As I posted on the original thread:
240 downloads of the Free APK now... http://forum.xda-developers.com/showpost.php?p=60894402&postcount=94
"Headunit" is the app name I've settled on. Short & sweet.
Want to see this Headunit app fixed and improved on a regular basis ?
Then I need your help...
First need is some IMO well deserved publicity. There is no other app like this and I think there is a need...
I saw LOTS of excitement on Android enthusiast sites about Android Auto. And a LOT of excitement dissipated hearing that a $700 Headunit or new car was required.
So wouldn't turning a $165 Nexus 7 2013 tablet into a basic AA Headunit with an app restore some excitement ?
I've been busy on the tech side, but to keep this project moving, people need to find out about it.
I've started a new thread here for all further discussion about my Headunit app: http://forum.xda-developers.com/general/paid-software/android-4-1-headunit-android-auto-t3125252
If it seems worthy to you, please consider clicking on "Submit Thread as News Tip" at top right of that thread.
Most Android news and discussion sites have similar functions to submit news tips. If it comes from people like you, I'd think it has more weight than me trying to promote my new app.
XDA is kinda, sorta, not supposed to be used to SELL things (and that's kinda vague & fuzzy, and there IS a section for paid apps, where my new thread is), and I understand and respect that...
But truth is that my second, and perhaps most important need, in order to support YOU, is for some "little bits" of support from you... See my new thread or sig for the new paid APK on Play.
There are other, Android Auto/Connected Car app ideas I have, should this one garner insufficient support. Feel free to comment:
- Use any media player (or messenging) with AA, where it does not have AA extensions.
- App to connect sensors, + via ODB and maybe Torque like functionality.
- Standalone mode for AA running on a phone. Will likely require root and Xposed and LOTS of work and workaround when Google sabotages it.
- Customization of Android Auto via root/Xposed app; Change anything from backgrounds to color to rules that AA imposes in the name of safety and anything else that needs a mod.
Thanks !
Mike ( [email protected] )

Hi!
I've just purchased your headunit app. I've attempted to connect it, but am unable to get it working. I'm really excited to see something like this, and can probably help you debug it if needed.
My devices:
- Nexus 7 (2012 Wifi), running stock Android 5.1.1, stock recovery, rooted with Nexus Root Toolkit
- Nexus 4, running stock Android 5.1.1, custom recovery, rooted with Nexus Root Toolkit
Cables:
- USB OTG cable, purchased some time ago, but known to be functional -- I've used it on my Nexus 4 to connect a microSD reader.
- Micro USB (male) connector from USB OTG cable plugged into Nexus 7.
- Charging cable plugged into micro USB connector (female) on USB OTG cable.
- Standard micro USB connected from Nexus 4 to USB A (female) port on USB OTG cable.
- Both devices show as charging.
Problem:
- When starting Headunit app, the screen stays black (with only standard on-screen controls, and never prompts me on either device for anything).
- I have also tested this in reverse, by sideloading the Headunit APK onto my Nexus 4 (Google Play Store said incompatible, but what do they know? ), and sideloading the Android Auto app onto my Nexus 7. I reversed the cabling, so that the USB OTG cable is plugged into the Nexus 4 as the host device. Same results.
- I've tried various combinations of unplugging and replugging, force closing and restarting apps, etc.
What's the next step in debugging this setup?

jpreston84 said:
Hi!
I've just purchased your headunit app. I've attempted to connect it, but am unable to get it working. I'm really excited to see something like this, and can probably help you debug it if needed.
My devices:
- Nexus 7 (2012 Wifi), running stock Android 5.1.1, stock recovery, rooted with Nexus Root Toolkit
- Nexus 4, running stock Android 5.1.1, custom recovery, rooted with Nexus Root Toolkit
Cables:
- USB OTG cable, purchased some time ago, but known to be functional -- I've used it on my Nexus 4 to connect a microSD reader.
- Micro USB (male) connector from USB OTG cable plugged into Nexus 7.
- Charging cable plugged into micro USB connector (female) on USB OTG cable.
- Standard micro USB connected from Nexus 4 to USB A (female) port on USB OTG cable.
- Both devices show as charging.
Problem:
- When starting Headunit app, the screen stays black (with only standard on-screen controls, and never prompts me on either device for anything).
- I have also tested this in reverse, by sideloading the Headunit APK onto my Nexus 4 (Google Play Store said incompatible, but what do they know? ), and sideloading the Android Auto app onto my Nexus 7. I reversed the cabling, so that the USB OTG cable is plugged into the Nexus 4 as the host device. Same results.
- I've tried various combinations of unplugging and replugging, force closing and restarting apps, etc.
What's the next step in debugging this setup?
Click to expand...
Click to collapse
Hi, Thanks for your support.
Send me an email at [email protected] and I'll send you a debug release. Or I'll PM you a link when I get one built in a few hours. Are you able to capture a logcat or should I add an easy "Send logcat" button ?
Some quick googling tells me the stock Nexus 4 does not support USB OTG (ie running the headunit app). But some kernels enable this and this is the first thread I saw about that: http://forum.xda-developers.com/nex...g-externally-powered-usb-otg-t2181820/page154
The app specifies that USB OTG is required, and I thought that was a great way to prevent people from purchasing on incompatible devices. But now that I see Nexus 4 (and I'm sure many other devices) can do OTG with a custom kernel, I guess I should remove that as a hard requirement. A popup warning would be better.
I have that same Nexus 7 2012 with the latest Android 5.1.1 (unrooted even) and pretty much stock, and all released versions of the Headunit app work on it. So I feel confident that the hardware and software work OK together.
And AFAIK, Android Auto runs fine on stock Nexus 4.
If you aren't getting prompted for USB permissions on the Headunit app side, that seems to indicate a connection problem.
Can you stop charging the Nexus 7 and reboot it to see if that helps ? My understanding is that Nexus devices can't do USB host mode and charge at the same time. Custom kernels are needed to allow this.
If you have a plain OTG cable without a charging connection please try that also. Ensure that the regular USB cable supports data tranfer. Some are for charging only.
My test setup is:
- 1 regular USB cable: large male (plugged into OTG large female) to micro-USB male (plugged into Android Auto phone).
- 1 OTG cable: large femaie (plugged into regular large male) to micro-USB male (plugged into Headunit device).
Sometimes between the 2 cables I insert a powered USB hub, but a straight connection seems to work for both Nexus 7's, Nexus 9 and Xperia Z2 tablet, though it does drain the Headunit device battery to charge the Android Auto device.
A good sign that the cabling is working is seeing the Gallery app opening on the Headunit device when they are plugged. Android Auto device pictures and videos are shown via USB MTP I guess.
I'm going to add a startup screen that shows connected USB devices and that can be used for trouble-shooting.

This thread needs to be woken up...
If you have ANY questions or comments, please post !
I'm encouraged to see the Headunit app on Play has had 2 confirmed sales in the last 2 days; there are also 9 cancels (boo !) and 3 unconfirmed....
Pretty Good I think for the first few days of a new app.... Could be more if I remove the strict USB host requirement, but probably more disappointed cancellers too.
I appreciate Google Play reviews from anyone who has purchased and/or cancelled.
Right now I have two 1 star reviews on Play to deal with; thankfully Google lets us reply to reviews now.
Here's what I just added to the Play Store description:
No risk/full refund within 90 days. Just email 15 digit order ID or email of purchase to [email protected] . But "be warned" that I WILL do my best to get this app working for you and make you happy, or at least explain why your device may be incompatible...
Click to expand...
Click to collapse

Message to app reviewers on Play:
The Reviews section of Google Play has a 350 letter maximum. It is impossible to provide good technical support with that limit.
Please email me [email protected] for private support.
But I prefer to discuss publicly for everyone's benefit if you are registered or don't mind registering at XDA Developers Forum. Headunit Thread: http://forum.xda-developers.com/general/paid-software/android-4-1-headunit-android-auto-t3125252
If Headunit is working well for you, Great !
For problems, please read on:
I updated the Play Store description with this:
NOTE: Requires 2 devices ! Needs an Android 4.1+ tablet (that supports USB Host mode) running this Headunit app connected to an Android 5.0+ phone running Android Auto. Connection requires 1 standard phone USB cable and a special USB OTG cable connected to the Headunit app device.
No risk/full refund within 90 days. Just email 15 digit order ID or email of purchase to [email protected] . But "be warned" that I WILL do my best to get this app working for you and make you happy, or at least explain why your device may be incompatible...
Click to expand...
Click to collapse
I hope you understand this is the first release of a new type of app, and that I'm still calling it "experimental".
I will do my best to support as many devices as I can. But some devices will never work, particularly those that can not support "USB Host Mode".
The most common problem will be USB cable connection problems. Generally, you will need at least 2 cables:
1 USB OTG cable connected to tablet or other device running the Headunit app.
1 Regular USB cable connected to phone running Android Auto.
The cables are connected together of course, directly or though a hub. Sometimes you may need to insert a powered USB hub between the cables, with the powered side going to the Android Auto phone.
Sometimes connections may be loose. Ensure that (at least) all 3 connections are securely made. Gently try to push the plugs in just a little deeper to see if it goes farther. This has fixed it for me more than once.
I will put some better debugging and logging options in the next release of this app.
There is a LOT more information about how to get the Headunit app working, and some trouble-shooting hints in the First 10 posts of thread: http://forum.xda-developers.com/general/paid-software/android-4-1-headunit-android-auto-t3125252

Hi, good work on getting this started. For me the deal breaker feature down the line would be car integration, namely:
Bluetooth calls take place over car mic and speakers
Steering wheel controls (volume, answer, next track, etc.)
I imagine some support for the pioneer adapter that allows this would be feasible.
Any plans or knowledge about that?

ok, seems to be working ok (although slowly) on a nexus 7 2012 (as headunit). does not work at all on a nexus 7 2013 (as headunit), just a black screen without any notices.

I would really like to try this, but the USB port of my N7 2012 is broken, and I still haven't fixed it :/
Sent using my nexus⁴ running Euphoria 1.1 with Xposed and hells-Core B78

Maxr1998 said:
I would really like to try this, but the USB port of my N7 2012 is broken, and I still haven't fixed it :/
Click to expand...
Click to collapse
I really hope that Google can enable Android Auto over WiFi soon. If not, I will consider mods that would allow this. But it would require root on both sides; an AA standalone mode (that only needs one rooted device) may be desirable to more people.
Android Auto over Wifi would solve USB specific connection problems, like the need for USB Host mode on the Headunit and the associated "charging while in USB host mode" problems that usually requite a custom kernel.

ldti said:
ok, seems to be working ok (although slowly) on a nexus 7 2012 (as headunit). does not work at all on a nexus 7 2013 (as headunit), just a black screen without any notices.
Click to expand...
Click to collapse
Good start...
My N7 2012 seems to have good video speed, but I only use it for testing so I have very few apps and they aren't doing many background tasks.
Does the video have defects or does it look accurate ? I have seen slowness and defects together, but mostly on my older, slower phones.
The release I'm working on now has better debbuging capabilities. I'll try to post a new version within the next 12 hours.
Can I presume both Nexus 7's are stock ? Root and recovery shouldn't matter, but a custom kernel (or ROM) could make a big difference.

[KERNEL] (Patch) USB OTG (host mode) + simultaneous charging!

(I really struggled with where to post this. Although much work and effort went into debugging unique Z5-specific issues, this is based on prior work so I put it here instead of in "original"; also, I would be very surprised if this didn't apply cleanly and work across the entire Z5 family, not just the Compact, but it might not apply beyond the Z5 so it doesn't make sense to put it in the cross-platform forum, which means I had to pick ONE Z5 family forum to post in. I've only tested on Compact, so I guess it goes here for now.)
I am attaching a set of kernel patches that will allow Z5 users to put their phone's USB port into host mode while simultaneously also allowing the phone to take a charge. In this scenario, the USB device(s) connected to the phone are not getting power from the phone like they normally would in a standard "OTG" scenario, but are sharing with the phone whatever power source is being used to charge the phone.
Acknowledgements:
HUGE thanks...
...to @ziddey for his original patch that he developed for the Nexus 4 which was the inspiration behind all of this,
...to @sollapse for being the first to successfully implement ACA support in the DWC3 driver,
...and to @Phoenix Wright for further refining that code
The patches presented here are based largely off of Phoenix Wright's work.
Background:
I used a Nexus 4 for a long time, and grew accustomed to being able to do this with my Nexus thanks to @ziddey's extremely clever hack. (My personal use-case is a phone dock in my car which both charges the phone and connects it to a USB sound card, which in turn is fed into the auxiliary input of my car's stereo head unit.) In fact, the modification ziddey came up with was both so effective and minimally-invasive that the changes were -- until relatively recently -- easy to apply to just about any Snapdragon-based device (even ones with fully-functioning OTG support, which the Nexus 4 didn'thave), since many of them shared a common USB core, and thus also shared drivers.
I was disappointed to discover upon receiving my Z5 Compact that although for some odd reason that venerable old Snapdragon USB driver was enabled in Sony's kernel's build .config, it wasn't actually being used by the hardware...I patched up the kernel, compiled it, flashed it, and the behavior of the USB port didn't change. Turns out all of the more recent Snapdragons use a new USB 3/SuperSpeed-capable core by Synopsys, part of their DesignWare series, and this core uses an entirely different driver called DWC3. And unlike the older driver, this new one does not implement support for so-called USB "accessory charging adapters" or ACAs (typically vendor-proprietary powered USB hubs that do exactly what we want: charge the phone while putting it in host mode), so in-built support for ACAs couldn't be exploited in the DWC3 driver the way that it had been in the old driver.
Fortunately, @sollapse rose to meet the challenge and whipped up some basic ACA support for the DWC3 driver included in the kernel source tree for the OnePlus One. I took what was largely a re-write of this, done by @Phoenix Wright, and essentially ported that version over to the Z5 kernel while also making some other changes and additions along the way.
Use:
Disclaimer: I cannot be held responsible if any harm should come to you or your phone on account of using these software modifications.
This was developed and tested against the Sony copyleft sources for the kernel that shipped with the last release of Lollipop for the Z5 series (32.0.A.6.200). I plan to also work on versions for the Marshmallow and Nougat kernel releases as well, but wanted to start with something as close to what I was porting from as possible and just deal with one variable at a time. Chances are good that very little changed in the USB drivers in later Z5 kernels anyway. I have also to-date only tried to apply this to an otherwise stock Sony source tree, and running on the stock Sony Lollipop ROM.
This isn't how ACAs are strictly meant to work on a device that officially supports them, but when it comes to this patch, to enable or disable "ACA mode", you need to either pass a certain parameter (aca_enable, should be set to 'Y') to the driver (dwc3) at initialization (during boot / on the kernel command line, so 'dwc3.aca_enable=Y'), or toggle the parameter after boot using sysfs (e.g. 'echo N > /sys/module/dwc3/parameters/aca_enable'). For write access to sysfs, you have to be root, so keep that in mind if you have a requirement to be able to toggle this on and off without a reboot.
Enabling ACA mode merely changes the behavior of the driver when the ID pin/pin 5 on the micro-USB cable is grounded (OTG cable), which indicates to the phone that it should switch to host mode. With ACA mode enabled, it basically doesn't engage the USB host voltage bus regulator and instead activates the battery charging circuitry; however, just like "normal" USB host mode, it still requires an actual OTG cable to work, UNLIKE ziddey's original patch. What this means is that if you want to plug, say, a thumb drive into your phone without having to also supply an external power source, you need to set 'aca_enable' back to 'N' first before this will work again.
Sometimes it is not possible to use an OTG cable in certain situations; for example, there is no way I am going to first cut out and then cut open the non-OTG micro-USB plug from my $80 Proclip car mount in order to turn it into a proper OTG cable. For these situations, ziddey's ingenious idea -- borne out of necessity by the broken ID_GND detection on the Nexus 4 -- of triggering host mode based on the type of charging adapter detected by the phone is extremely useful, and so I implemented a similar feature: by additionally setting 'prop_chg_aca_enable' to 'Y', the driver will switch to USB host mode if a so-called "proprietary" charging source is detected (which is apparently what the phone interprets the voltage injected with a USB Y-cable as).
'prop_chg_aca_enable' will have no effect if 'aca_enable' is not also toggled on. I split it out into a separate option, though, because for reasons I haven't had the time to hunt down yet, the charger detection toggle seems (based on extremely limited testing) to make the use of an OTG cable less reliable...sometimes it works, sometimes it engages the host mode but not the battery charger, sometimes it does neither. So if you already use an OTG cable with your particular set-up, I recommend you leave 'prop_chg_aca_enable' off.
Finally, as most of you surely know, the Z5 series (and the Z3+/Z4 before it) introduced a new coverless micro-USB port along with a new requirement that you the user must manually initiate a scan for attached USB gadgets in order for the port to switch over to host mode; presumably they did this so that they could keep the IP68 water ingress protection rating despite the change to a coverless port. Miraculously, when aca_enable is on, because the phone is accepting a charge instead of delivering power in this scenario, there is (in theory) no additional risk from water exposure in this mode and yet you also do NOT need to hit "Detect USB Device" on your phone before you can use the USB device...as long as both external power and a USB device are present on the cable at the moment you plug it in. If you don't have a USB device plugged into your Y-cable, only power, then the device will not be detected later. If you have a need to work around this, you can set 'no_device_timeout_enable' to 'N', which will keep the host controller on-line and engaged for as long as you have a powered OTG cable plugged in.
If you want to *really* live life on the edge, you can also set the 'force_id_polling_on' parameter of the 'qpnp_smbcharger_extension' driver to 'Y' in order to completely disable the need for tapping on "Detect USB Devices" for "normal" OTG mode.
Oh, one more thing I forgot: if you are supplying power through an OTG cable (with ID pin grounded), then you need to set 'dwc3_msm.force_float_on_bsv=N' in order to work around a change Sony made to the driver that causes it to treat powered OTG cables as if they are non-OTG. I don't know why they did this (perhaps just to further reduce the risk of water damage on account of the open port under certain circumstances?), but I added a toggle that bypasses their change.
In summary, here are all of the various driver/module options I have decided to supply to my own kernel at boot time; at a minimum #1 and #4 are mandatory when using a OTG cable and #4 and #5 are mandatory when using a non-OTG cable:
dwc3_msm.force_float_on_bsv=N
(disables Sony "innovation" that prevents a powered OTG cable from switching controller into host mode)
qpnp_smbcharger_extension.force_id_polling_on=Y
(disables the need for "Detect USB Devices" under normal OTG use -- NOTE this could reduce the integrity of the water protection!! Use with caution!)
dwc3.no_device_timeout_enable=N
(disables host mode timeout in the event controller does not detect a device)
dwc3.aca_enable=Y
(enables the new "ACA mode" which allows for the exclusive use of powered OTG cables at the expense of normal OTG use)
dwc3.prop_chg_aca_enable=Y
(additionally allows USB host mode to be triggered by a non-OTG powered Y-cable that also has a USB device attached)
I hope others find this useful, while at the same time I also hope that our USB-C future will eventually end the need for us to dabble in such hackery.
-- Nathan

Nice work! Just to let you know, I made some final changes to the patch before submitting it to SultanXDA there: https://forum.xda-developers.com/showpost.php?p=64784909&postcount=8403 (I think there was an issue with kernel panics in certain circumstances which was fixed by a msleep(), maybe something else too).

Phoenix Wright said:
Nice work! Just to let you know, I made some final changes to the patch before submitting it to SultanXDA there:
Click to expand...
Click to collapse
Thanks! My version of the patch was based off of the final post you made to sollapse's thread, which I'll call your patch #1. I just downloaded the version of the patch you linked to (#2), and diff'd a copy of the Sultan dwc3_otg.c patched with #1 against a copy patched with #2, and this is the only difference I found:
Code:
@@ -1048,6 +1044,11 @@
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
+ /* If B_SESS_VLD went off already, proceed to enable host */
+ if (test_bit(B_SESS_VLD, &dotg->inputs)) {
+ work = 1;
+ break;
+ }
/* Ensure there's no charger before suspending */
msleep(200);
if (!dotg->ext_xceiv->bsv)
pm_runtime_put_sync(phy->dev);
} else {
...and I had actually added a single line to that 'if' block already that set work=1 indiscriminately (which you can see in my patch). (As I recall, more often than not after hitting the A_IDLE case, there would be no additional external event to trigger the workqueue again after state was set to A_HOST, which meant that OTG_STATE_A_HOST case block would never actually get executed.) It probably would be more correct for me to test for BSV before forcing another workqueue loop, so I'll try making that change and re-testing. I haven't experienced any ill effects in day-to-day use, though.
Is there a reason why you are checking BSV state twice and in two different ways here (checking the B_SESS_VLD bit in dotg.inputs, and also directly checking dotg.ext_xceiv.bsv)? Are you checking dotg.ext_xceiv.bsv directly because there is a chance that dwc3_ext_event_notify() hasn't been called by the transceiver driver yet for some reason to update the state machine inputs? What about simplifying things here down to a single test, like so?:
Code:
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
/* If B_SESS_VLD went off already, proceed to enable host */
if (test_bit(B_SESS_VLD, &dotg->inputs)) {
work = 1;
break;
} else {
/* Ensure there's no charger before suspending */
msleep(200);
pm_runtime_put_sync(phy->dev);
}
} else {
(or substitute in "if (dotg->ext_xceiv->bsv)" for the call to test_bit() if you think that is more appropriate for some reason?)
Thanks again,
-- Nathan

nlra said:
Thanks! My version of the patch was based off of the final post you made to sollapse's thread, which I'll call your patch #1. I just downloaded the version of the patch you linked to (#2), and diff'd a copy of the Sultan dwc3_otg.c patched with #1 against a copy patched with #2, and this is the only difference I found:
Code:
@@ -1048,6 +1044,11 @@
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
+ /* If B_SESS_VLD went off already, proceed to enable host */
+ if (test_bit(B_SESS_VLD, &dotg->inputs)) {
+ work = 1;
+ break;
+ }
/* Ensure there's no charger before suspending */
msleep(200);
if (!dotg->ext_xceiv->bsv)
pm_runtime_put_sync(phy->dev);
} else {
...and I had actually added a single line to that 'if' block already that set work=1 indiscriminately (which you can see in my patch). (As I recall, more often than not after hitting the A_IDLE case, there would be no additional external event to trigger the workqueue again after state was set to A_HOST, which meant that OTG_STATE_A_HOST case block would never actually get executed.) It probably would be more correct for me to test for BSV before forcing another workqueue loop, so I'll try making that change and re-testing. I haven't experienced any ill effects in day-to-day use, though.
Is there a reason why you are checking BSV state twice and in two different ways here (checking the B_SESS_VLD bit in dotg.inputs, and also directly checking dotg.ext_xceiv.bsv)? Are you checking dotg.ext_xceiv.bsv directly because there is a chance that dwc3_ext_event_notify() hasn't been called by the transceiver driver yet for some reason to update the state machine inputs? What about simplifying things here down to a single test, like so?:
Code:
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
/* If B_SESS_VLD went off already, proceed to enable host */
if (test_bit(B_SESS_VLD, &dotg->inputs)) {
work = 1;
break;
} else {
/* Ensure there's no charger before suspending */
msleep(200);
pm_runtime_put_sync(phy->dev);
}
} else {
(or substitute in "if (dotg->ext_xceiv->bsv)" for the call to test_bit() if you think that is more appropriate for some reason?)
Thanks again,
-- Nathan
Click to expand...
Click to collapse
A lot of time has passed, but if I'm not mistaken, on the OPO, in some circumstances (II think if you removed the otg-y cable quickly or something like that), dwc3_ext_event_notify() would be called (to signal that power was removed) after the device was suspended leading to a kernel panic (I did a lot of tests with the "extreme" cases, like removing the cables quickly). So the msleep is to make sure that it didn't happen (in such cases, the device is then suspended by the next invocation of that state machine if I'm not mistaken, in the "case OTG_STATE_A_HOST:", in the part below the "/* Charger has been removed */" comment). So the changes you proposed wouldn't work, as the msleep + direct check are there to tell if the state machine is going to be called again just after that.

Phoenix Wright said:
[...] on the OPO, in some circumstances (II think if you removed the otg-y cable quickly or something like that), dwc3_ext_event_notify() would be called (to signal that power was removed) after the device was suspended leading to a kernel panic (I did a lot of tests with the "extreme" cases, like removing the cables quickly). So the msleep is to make sure that it didn't happen (in such cases, the device is then suspended by the next invocation of that state machine if I'm not mistaken, in the "case OTG_STATE_A_HOST:", in the part below the "/* Charger has been removed */" comment). So the changes you proposed wouldn't work, as the msleep + direct check are there to tell if the state machine is going to be called again just after that.
Click to expand...
Click to collapse
Gotcha, thanks; makes perfect sense. I'm not sure that the same thing is necessarily happening on the Z5...it uses a different battery charge controller than the 1+1 and in fact I ripped out a lot of the 1+1-specific workarounds when preparing my version of the patch. (I still need to do more testing, but in fact I'd say there are some instances where BSV is actually not being detected properly on this platform, which could explain my initial findings...there is a debugfs file exposed where you can check current BSV detection state, but even when phone is getting power it almost always shows "0".)
Nevertheless, I ran some tests:
1. With work=1 set explicitly every time (my addition to your code for my original version of the path), everything with a powered OTG cable and aca_enable=Y worked fine for me.
2. With that removed, it almost never engaged the battery charger, though host mode almost always kicked in.
3. After adding work=1 only if B_SESS_VLD bit was set, working functionality for powered OTG cables was restored (again, as long as my new prop_chg_aca_enable=N).
So I have updated the patch to check for that bit before forcing another workqueue loop, which I believe is "more correct".
Thanks again,
-- Nathan

Hm sorry I gonna sound like a total noob but everyone starts out somewhere. The *.diff file is for a ROM to be compiled? Its not supposed to be flashed with TWRP or such? Or is it just a file to be overwritten in the system files?
Just today I made myself an OTG cable with charging function and was scratching my head why it's not charging.

tarsonis666 said:
Hm sorry I gonna sound like a total noob but everyone starts out somewhere. The *.diff file is for a ROM to be compiled? Its not supposed to be flashed with TWRP or such? Or is it just a file to be overwritten in the system files?
Just today I made myself an OTG cable with charging function and was scratching my head why it's not charging.
Click to expand...
Click to collapse
You are correct, this file is used to patch the kernel (not the ROM) source and then compile the kernel binaries.
Files you flash in TWRP usually end in ".zip" or ".img".
// DevelLevel

Hey. Has anyone compiled a kernel with this patch applied? I'm a total noob when it comes to Linux and I'm really struggling with compiling a kernel, let alone applying patches to it . I would be really grateful if someone could attach a ready kernel image.

Adamell0 said:
Hey. Has anyone compiled a kernel with this patch applied? I'm a total noob when it comes to Linux and I'm really struggling with compiling a kernel, let alone applying patches to it . I would be really grateful if someone could attach a ready kernel image.
Click to expand...
Click to collapse
Sorry, haven't hung out around here in a while...
What specific phone model do you have, and what firmware version are you using? If it is something in the Z5 family (regular/Compact/Premium) and otherwise stock Sony firmware, let me know which model and f/w version and I can probably whip something up.
If it's some other phone model, no guarantees. If Z5 with third-party AOSP-based firmware, also no guarantees but more likely than not may be possible.

nlra said:
Sorry, haven't hung out around here in a while...
What specific phone model do you have, and what firmware version are you using? If it is something in the Z5 family (regular/Compact/Premium) and otherwise stock Sony firmware, let me know which model and f/w version and I can probably whip something up.
If it's some other phone model, no guarantees. If Z5 with third-party AOSP-based firmware, also no guarantees but more likely than not may be possible.
Click to expand...
Click to collapse
Thanks for your response. I have Sony Xperia Z5 Compact model E5823 with Android 7.1.1., kernel version is 3.10.84-perf-g99119bc.

Adamell0 said:
Thanks for your response. I have Sony Xperia Z5 Compact model E5823 with Android 7.1.1., kernel version is 3.10.84-perf-g99119bc.
Click to expand...
Click to collapse
Gotcha; I should be able to help with this, but what I need is the Sony ROM version, not the kernel version. Can I assume that you're running the latest (last) version of 7.1.1 released for the Z5c, 32.4.A.1.54? (At this point I'd be surprised if you were running anything older, but I'm going to be pulling the kernel sources direct from Sony for the firmware version that matches what you're running, which is why I need to be sure. In all likelihood, though, even if you are running slightly older ROM, since you're already on 7.1.1, the odds of a kernel built from the latest sources not working with your ROM are likely slim-to-none.)
And you already have the bootloader unlocked on your Z5c, yes?
EDIT: -g99119bc is what is shown as the suffix on the kernel version from 32.4.A.1.54 in screenshots of "About phone" all over the internet for the Z5 series, so I'm moving forward with this assumption.

nlra said:
Gotcha; I should be able to help with this, but what I need is the Sony ROM version, not the kernel version. Can I assume that you're running the latest (last) version of 7.1.1 released for the Z5c, 32.4.A.1.54? (At this point I'd be surprised if you were running anything older, but I'm going to be pulling the kernel sources direct from Sony for the firmware version that matches what you're running, which is why I need to be sure. In all likelihood, though, even if you are running slightly older ROM, since you're already on 7.1.1, the odds of a kernel built from the latest sources not working with your ROM are likely slim-to-none.)
And you already have the bootloader unlocked on your Z5c, yes?
EDIT: -g99119bc is what is shown as the suffix on the kernel version from 32.4.A.1.54 in screenshots of "About phone" all over the internet for the Z5 series, so I'm moving forward with this assumption.
Click to expand...
Click to collapse
I'm running exactly the version you mentioned: 32.4.A.1.54. As far as unlocking bootloader goes it is still on my "to do" list, but for that I assume that the tutorial on Sony website will suffice.

Adamell0 said:
I'm running exactly the version you mentioned: 32.4.A.1.54. As far as unlocking bootloader goes it is still on my "to do" list, but for that I assume that the tutorial on Sony website will suffice.
Click to expand...
Click to collapse
I would advise you to not just blindly unlock the bootloader on your Z5c if you haven't done so already. Doing so on the Z5c is irreversible and has permanent consequences unless you prepare in advance / take necessary precautions. (Side note: it's because of stuff like this that I've learned to always search and read up on any potential pitfalls when it comes to doing bootloader unlocks on specific models of phones before just jumping right in!!! Sony is not entirely forthcoming in their warnings on their site about what you lose when you unlock!)
The "necessary precautions" involve backing up what is called the TA partition of the phone before unlocking the bootloader. When you unlock the bootloader, the phone zeroes out all of the DRM keys stored in this sector that are unique to your particular phone (not phone model, your specific unit! if you lose them you can never get them back! and you can't take copies of keys from another Z5c and flash them to your phone unless you want a permanent brick that will never power back on again!). So best to back this up beforehand, both so that you have the option of returning to COMPLETE stock in the future if you so desire (re-lock bootloader, etc.), but also so that you can reflash the keys back to TA while retaining the unlocked bootloader, having the best of both worlds.
Unfortunately, this is a bit of a pain to do, admittedly, since TA partition is normally heavily guarded. It's supposed to be impossible to access, but a bug in older firmwares can be exploited to gain access to it even with a locked bootloader. So this means you have to actually downgrade back to Android 6.0 Marshmallow *just temporarily*, long enough to make a backup of the TA partition. After that, you can re-upgrade back to 7.1 Nougat and proceed with bootloader unlock.
If you decide not to go to the trouble, that's fine, but at least you will be making an informed decision in advance, rather than only finding out about what you lost after it's gone, robbing you of choice.
Link to TA backup utility: https://forum.xda-developers.com/t/universal-dirtycow-based-ta-backup-v2.3514236/
To downgrade, you'll need to get yourself a copy of Flashtool and a Sony Z5c Marshmallow ROM file; I can provide links to these in a PM if you want to go down this path. The firmware download is nearly 3 gigs, just FYI.

nlra said:
To downgrade, you'll need to get yourself a copy of Flashtool and a Sony Z5c Marshmallow ROM file; I can provide links to these in a PM if you want to go down this path. The firmware download is nearly 3 gigs, just FYI.
Click to expand...
Click to collapse
Please PM me those links if it's not a problem, while the phone is just one of many laying in my drawers having options is always a good thing .

Adamell0 said:
Please PM me those links if it's not a problem, while the phone is just one of many laying in my drawers having options is always a good thing .
Click to expand...
Click to collapse
Check your PM for links and general overview of how to accomplish downgrade/TA backup/upgrade.
Your kernel is also ready, tested, and attached.
Note that this is just the raw kernel with OTG patches included. If you end up backing your TA partition up, you will want to patch this kernel image with the latest version of rootkernel (which adds additional patches to restore functionality lost after bootloader unlock, but are not patches that require a kernel re-compile) and then flash that version.
Also, just in case it wasn't clear in the original post, these patches do not allow you to seamlessly use both traditional non-powered OTG as well as powered OTG...it's one or the other. Non-powered OTG will stop working, and OTG/host mode will only be possible if a power source is also applied. It is possible to disable the powered OTG mode and revert to regular non-powered mode, but it has to be done with a terminal command, and it will return back to powered-only OTG mode after the phone is rebooted.

[ROOT] Rooting the FireTV Cube and Pendant with FireFU

Today we’re excited to be bringing you something we’ve been working on for the last few months. Today, we’re introducing you to FireFU. FireFU is an exploit chain we’ve created to allow users to unlock (and root) their FireTV Cube and FireTV Pendant.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
https://blog.exploitee.rs/2018/rooting-the-firetv-cube-and-pendant-with-firefu/
Exploit package
This download is intended for users who are only seeking the binaries to perform the exploit.
https://download.exploitee.rs/file/amazon/FireFU/FireFU.tgz
Source Code
This is for the users who are needing to recompile the exploit or are just curious about the process.
https://gitlab.com/Exploiteers/FireFU_Exploit
https://gitlab.com/Exploiteers/amlogic_usb_mmc

This is nowhere near achievable for most XDA users though.

This is amazing. Thanks a lot.
I'm completely newbie but look forward testing this.
Can this exploit be eventually patched by Amazon so it's better to block updates if you don't use it immediately?
EDIT: I just read they can but I meant if they can patch with future updates so that the process is defeated and can't be used anymore.
Regards and congratulations.
Pino.

puppinoo said:
This is amazing. Thanks a lot.
I'm completely newbie but look forward testing this.
Can this exploit be eventually patched by Amazon so it's better to block updates if you don't use it immediately?
EDIT: I just read they can but I meant if they can patch with future updates so that the process is defeated and can't be used anymore.
Regards and congratulations.
Pino.
Click to expand...
Click to collapse
Yes the exploit is patchable. Amazon will probably patch it in the next firmware release. I'm not sure how long this exploit will last. Make sure to disable OTA update after you rooted it. This exploit also allow you to run custom roms too since it bypass the signature check in uboot SoC is similar to Odroid C2 board so you might able to run it image on the FireTV with little/no modifications.

xXhighpowerXx said:
Yes the exploit is patchable. Amazon will probably patch it in the next firmware release. I'm not sure how long this exploit will last. Make sure to disable OTA update after you rooted it. This exploit also allow you to run custom roms too since it bypass the signature check in uboot SoC is similar to Odroid C2 board so you might able to run it image on the FireTV with little/no modifications.
Click to expand...
Click to collapse
Thanks for precious info,
I already blocked URLs from Amazon on my LEDE router in dnsmasq.conf.
Really interesting. I have LibreElec installed on my Odroid C2 and the idea of installing a Linux distro on the pendant is also interesting.
BTW I stress my gratitude cause your work is amazing.
Pino.

xXhighpowerXx said:
.
Click to expand...
Click to collapse
Is the HDMI breakout adapter linked in the wiki the correct one that would be needed for this project?
https://www.amazon.com/Adapter-sign...rs-20&linkId=eca52d73a58d16cf24fb94f55bfd7ebe
From what I can tell from the pictures, that breakout board has a male adapter, but you would need a female adapter to plug the Fire TV into, correct?
Also, would it be possible to provide a little more detail on the command line steps needed? I'm a Linux novice so I'm having a little difficulty trying to figure out how to execute some of these steps. The exact commands for each step would be great. Thanks for your work!

AZImmortal said:
Is the HDMI breakout adapter linked in the wiki the correct one that would be needed for this project?
https://www.amazon.com/Adapter-sign...rs-20&linkId=eca52d73a58d16cf24fb94f55bfd7ebe
From what I can tell from the pictures, that breakout board has a male adapter, but you would need a female adapter to plug the Fire TV into, correct?
Click to expand...
Click to collapse
Correct. Something like this is what you need. This looks like the one used in the wiki.
IMO, putting the device into DFU mode is the bottleneck. You will have to set up the correct udev rules to get the Amlogic side recognized through the HDMI breakout.
(The Linux rooting commands are in the video.)

retyre said:
Correct. Something like this is what you need. This looks like the one used in the wiki.
IMO, putting the device into DFU mode is the bottleneck. You will have to set up the correct udev rules to get the Amlogic side recognized through the HDMI breakout.
(The Linux rooting commands are in the video.)
Click to expand...
Click to collapse
Thanks for confirming about the HDMI breakout. I found this on AliExpress for the cheapest option (but longest delivery time). Can you explain what you mean by the DFU mode bottleneck? I know that the Fire TV has to be put into DFU mode, but I wasn't sure if you meant that it's trickier than it seems (like maybe some computers don't have the right chipset or something along those lines). Also, I saw the video but it seems to start at step 7, which is basically where the easy parts of the process start, haha. I need more details on the earlier steps.

AZImmortal said:
Can you explain what you mean by the DFU mode bottleneck? I know that the Fire TV has to be put into DFU mode, but I wasn't sure if you meant that it's trickier than it seems (like maybe some computers don't have the right chipset or something along those lines).
Click to expand...
Click to collapse
There are so many variables here: genuine Arduino vs. counterfeit, quality of the HDMI breakout board, USB 3.0 vs. 2.0, Linux box with proper udev rules, ...
Take a look at something like this if you want to automate the last part (udev).

retyre said:
There are so many variables here: genuine Arduino vs. counterfeit, quality of the HDMI breakout board, USB 3.0 vs. 2.0, Linux box with proper udev rules, ...
Click to expand...
Click to collapse
I have an Arduino clone but I've never actually used it for real (other than flashing sketches to it to make sure that it works), but assuming that the clone is functional, then what kind of issues might prevent it from working for this project? I guess same question goes for the breakout board and USB 3.0 vs 2.0. Just trying to figure out what kind of obstacles I might encounter if I decide to try this.
retyre said:
Take a look at something like this if you want to automate the last part (udev).
Click to expand...
Click to collapse
This helps put things a little more together for me (at least I know which libusb I'd need to install). I'm still not sure that I understand how to execute step 1 or step 6 under the Rooting Process instructions though.
Thanks for the help so far.

AZImmortal said:
his helps put things a little more together for me (at least I know which libusb I'd need to install). I'm still not sure that I understand how to execute step 1 or step 6 under the Rooting Process instructions though.
Click to expand...
Click to collapse
Depending on the Linux distro, libusb may already be installed. Run dpkg -l libusb* to check.
Step 1: udev rules are set up in /etc/udev/rules.d/. You will have to create a file (e.g., 90-usb-serial.rules) with the information (usually, the subsystem, vendor-product attributes as mentioned in the wiki, name, symlink, etc.). Syntax varies by distro. You should test your rule with a less tricky device that's guaranteed to show up (e.g., a common peripheral) and see whether the name or symlink in the rule was picked up properly.
Step 6: In general, lsusb lists the USB devices connected to the Linux box. For example, if you connect just the Arduino and run lsusb, you should see the Due show up as, say, 2341:003d. If everything works as planned (i.e., the AFTV3 gets into DFU mode), you should see the correct device show up when you run lsusb (1b8e:c003). If it does not, you now have to check all the failure points: whether the sketch was flashed properly, whether the Arduino's or breakout's SCL and SDA pins are working properly, whether the USB port is the issue, whether the jumper wire or cable is the issue, and whether your udev rule was set up properly. In the event of an unsuccessful outcome (i.e., Amlogic doesn't show up in lsusb), isolating the issue can be a bear.
There's only one way to find out. Gather the paraphernalia, test it out, and post here!

retyre said:
Depending on the Linux distro, libusb may already be installed. Run dpkg -l libusb* to check.
Step 1: udev rules are set up in /etc/udev/rules.d/. You will have to create a file (e.g., 90-usb-serial.rules) with the information (usually, the subsystem, vendor-product attributes as mentioned in the wiki, name, symlink, etc.). Syntax varies by distro. You should test your rule with a less tricky device that's guaranteed to show up (e.g., a common peripheral) and see whether the name or symlink in the rule was picked up properly.
Step 6: In general, lsusb lists the USB devices connected to the Linux box. For example, if you connect just the Arduino and run lsusb, you should see the Due show up as, say, 2341:003d. If everything works as planned (i.e., the AFTV3 gets into DFU mode), you should see the correct device show up when you run lsusb (1b8e:c003). If it does not, you now have to check all the failure points: whether the sketch was flashed properly, whether the Arduino's or breakout's SCL and SDA pins are working properly, whether the USB port is the issue, whether the jumper wire or cable is the issue, and whether your udev rule was set up properly. In the event of an unsuccessful outcome (i.e., Amlogic doesn't show up in lsusb), isolating the issue can be a bear.
There's only one way to find out. Gather the paraphernalia, test it out, and post here!
Click to expand...
Click to collapse
Thanks, this helps a lot. I'll have to take a little time to experiment with my setup to see if I can figure out the syntax, but I'm definitely planning to buy the breakout board and finally put my Arduino clone to work. I'll probably have more questions when that time comes.

Finally got around to trying this. Works as described in the OP.
TBH, this is not nearly as complicated as the usual hardware root method for FTV devices. If you know your way around Linux and can connect jumper wires, you should have no trouble with this. Please post here if you have issues.

retyre said:
Finally got around to trying this. Works as described in the OP.
TBH, this is not nearly as complicated as the usual hardware root method for FTV devices. If you know your way around Linux and can connect jumper wires, you should have no trouble with this. Please post here if you have issues.
Click to expand...
Click to collapse
Great job. Waiting for my hdmi breakout to arrive so I can try. Can I ask you if you tried to downgrade or upgrade fw version? If not will it be easy to accomplish? I ask cause I blocked updates on my router since initial FW version and I don't want to risk now. But I'd like once rooted to upgrade to a version (possibly already rooted) with a feature added later to automatically switch framerate which my version actually lacks.
Regards.
Pino.

puppinoo said:
Can I ask you if you tried to downgrade or upgrade fw version? If not will it be easy to accomplish? I ask cause I blocked updates on my router since initial FW version and I don't want to risk now. But I'd like once rooted to upgrade to a version (possibly already rooted) with a feature added later to automatically switch framerate which my version actually lacks.
Click to expand...
Click to collapse
I updated to the latest version (6.2.5.5) before trying this. The wiki indicated it was tested on that version, so I saw no harm. If 6.2.5.5 has a feature not found in earlier versions, you should unblock the DNS on your router and let the device update to 6.2.5.5 before you try this. Without a public link to any of the update files for AFTV3, how are you planning to downgrade/upgrade or flash a prerooted image?

retyre said:
I updated to the latest version (6.2.5.5) before trying this. The wiki indicated it was tested on that version, so I saw no harm. If 6.2.5.5 has a feature not found in earlier versions, you should unblock the DNS on your router and let the device update to 6.2.5.5 before you try this. Without a public link to any of the update files for AFTV3, how are you planning to downgrade/upgrade or flash a prerooted image?
Click to expand...
Click to collapse
Glad it worked for you. Any chance you could show links to the board and Hdmi breakout? Thank you.
---------- Post added at 06:00 AM ---------- Previous post was at 05:56 AM ----------
Nevermind I found them in the Wiki.

retyre said:
Finally got around to trying this. Works as described in the OP.
TBH, this is not nearly as complicated as the usual hardware root method for FTV devices. If you know your way around Linux and can connect jumper wires, you should have no trouble with this. Please post here if you have issues.
Click to expand...
Click to collapse
I plan on trying this tonight. It's not clear in the instructions how to connect everything. Connect the arduino to a linux box via USB? Do I need to adb to enter the commands? I've got the breakout HDMI wired to the arduino, but then a standard HDMI cable from breakout to FireTV?

Let me clarify the first few steps in the OP (this is where I expect most of the challenge to be):
-- This is what you will need to begin: Arduino Due (this is what I have), HDMI breakout board (this is what I used because I have the pendant; if you have the cube, you will need a male HDMI as in the wiki; if you have the pendant, you can also use the male with a coupler), M/M jumper wire (this is what I used), and a Linux box (I have Ubuntu 16.04.5 LTS installed).
To install the Arduino IDE and upload the sketch, follow these steps in sequence:
1. Download the Arduino IDE. (If you use v1.6.1 or earlier, you don't have to install the Due board separately.) For Linux, download v1.6.1 from here. (Note: You don't have to do this in Linux. For Windows, use this.)
General note for Linux: It might just be easier to run everything as root (to sidestep permission issues): use sudo. As an example, sudo ./arduino to start the Arduino IDE instead of just ./arduino.
2. Connect the Due to your PC's USB port, install the Windows driver (located inside arduino-1.6.1-windows.zip; no driver needed for Linux), and choose the correct Board (Native or Programming depending on which is connected; I usually use the Programming port) and Port.
3. Download and extract the archive in the OP (FireFU.tgz).
4. Upload the sketch (hdmi_arduino.ino, from the archive) to the Due. To do this, open hdmi_arduino.ino from File and choose Upload from Sketch or just click the right-arrow. Pull up the separator at the bottom to make it easier to view the progress window.
6. Confirm that the upload and verification are successful.
You will need Linux from this point forward.
5. Check to see whether libusb is already installed:
Code:
dpkg -l libusb*
If not, install it:
Code:
sudo apt-get install libusb-1.0-0
6. Add the proper udev rules for Amlogic and fastboot as described in the OP's link. If you do not know how to manually add rules in /etc/udev/rules.d/, do the following:
-- To automate the udev rule for Amlogic (from here):
Code:
sudo apt-get install git
git clone https://github.com/khadas/utils
cd utils
./INSTALL
This will write the Amlogic rule (/etc/udev/rules.d/70-*). To add the fastboot rule, open the file (70-*) in an editor, copy-and-paste the line for Amlogic, and change the vendor and product id to match that for fastboot.
To manually add the udev rules, create a new file (say, 70-firetv3.rules) with the following in it:
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{idVendor}=="1b8e", ATTR{idProduct}=="c003", MODE:="0666"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{idVendor}=="18d1", ATTR{idProduct}=="0d02", MODE:="0666"
-- Install fastboot and adb:
Code:
sudo apt-get install android-tools-adb android-tools-fastboot
7. Reboot for the rules to take effect.
8. Connect the following in order:
-- jumper wire to SCL, SDA, and GND on the Due ... and to the breakout board (as described in the wiki)
-- AFTV3's male HDMI to the breakout board's female HDMI (or the cube's female HDMI to the breakout board's male HDMI)
-- power to the Due (I use external power, but connecting it to USB power should work just as well)
-- micro USB to the AFTV3
-- other end of the micro USB to the Linux box's USB port
9. Check whether Amlogic, Inc. shows up:
Code:
lsusb
10. If it does, you're more than halfway there. If it does not, disconnect everything but the jumper wire and repeat step 8.

retyre said:
I updated to the latest version (6.2.5.5) before trying this. The wiki indicated it was tested on that version, so I saw no harm. If 6.2.5.5 has a feature not found in earlier versions, you should unblock the DNS on your router and let the device update to 6.2.5.5 before you try this. Without a public link to any of the update files for AFTV3, how are you planning to downgrade/upgrade or flash a prerooted image?
Click to expand...
Click to collapse
Thanks for advices. I didn't know updates URLs were still unknown. I just enabled updates and let it do its things. Now I'm on Build NS6255/1612 (hoping it's the original one and not some stealth tricky version just uploaded ). BTW I noticed the updates are incremental so it processed all the major ones one at a time. So maybe you could let it do until it reaches the version you like and after that you stop the updates. It's not a safe method I think (for them).
BTW Thanks again for advice. Stuill waiting for HDMI Breakout.

Arduino Documentation
retyre said:
-- power to the Due (I use external power, but connecting it to USB power should work just as well)
Click to expand...
Click to collapse
Documentation on the Arduino website states;
"The Arduino Due can be powered via the USB connector or with an external power supply. The power source is selected automatically.
External (non-USB) power can come either from an AC-to-DC adapter (wall-wart) or battery. The adapter can be connected by plugging a 2.1mm center-positive plug into the board's power jack.
Leads from a battery can be inserted in the Gnd and Vin pin headers of the POWER connector.
The board can operate on an external supply of 6 to 20 volts. If supplied with less than 7V, however, the 5V pin may supply less than five volts and the board may be unstable.
If using more than 12V, the voltage regulator may overheat and damage the board. The recommended range is 7 to 12 volts"