I have a lot of years in the embedded software industry, now work as independent consultant / developer, and have experience with practically everything on your list. While there are short courses you can take to help jump-start your transition, ultimately experience is what you need, and there's nothing here you can't learn and gain experience with on your own if you have the time and dedication to do so. Three things to note:
I think embedded software is a very rewarding field, but like all software engineering specialties, it can be extremely frustrating when you are initially ramping up on specific skills. I think more than anything else, tenacity is a key attribute for success. And Google like crazy.
The embedded software industry is obviously vast, there are many specialties within it, and your proposed skill list actually spans many specialties. You need to narrow this down significantly by deciding what specialties you want to focus on, based on interest, employability, and learning curve. Linux and Android are hot areas, but they are also very complex and may not give you the fundamentals you need.
There has been a significant change in the embedded software industry, especially in the last five years, in which silicon vendors are now offering much more full-featured processor support packages, which speeds up product development and reduces the amount of low-level software that needs to be written.
For instance, you can have a great career in the embedded software industry that is focused entirely on app-level embedded software -- C++, GUI frameworks, databases, communication protocols, etc -- without every getting into the nitty gritty of working with bootloaders, bringing up an OS on a SoC, or creating drivers for external bus devices. And if you look at initiatives like Android Things -- which targets IoT devices based on the Linux kernel -- the goal is to move pretty much all of the board-specific code into the app layer.
But the vast majority of embedded projects still run on hardware too resource-constrained to run Linux or Android, and rely on traditional RTOS's or no RTOS whatsoever. And I'd argue that, coming from the hardware side, this may offer a more relevant and simpler learning curve than diving into framework-based app development and Linux. While I develop Linux- & Android-based systems, a lot of projects I work on are based on more limited MCUs or boards.
If this latter sounds like more your cup of tea, here's what I'd recommend focusing on:
ARM. Most of the new designs I work on these days use ARM Cortex-A or Cortex-M cores. There are obviously lots of other MCU architectures out there -- I'm in the middle of a project based on an FTDI MCU -- but ARM experience is invaluable. I recommend starting with a dev kit based on an ARM Cortex-M MCU, which is a simpler ARM architecture; since you have other Arduino gear, maybe consider the Arduino Due.
FreeRTOS. Get FreeRTOS up and running on your ARM dev kit and start and choose a project that lets you interface iwth GPIO, I2C, SPI, UART, and/or CAN peripherals using multiple tasks and interrupts. Use the features of FreeRTOS and whatever board support package your processor vendor offers, but stick as close the hardware as is reasonable (i.e. don't use off-the-shelf libraries or drivers for interfacing with these peripherals, write your own peripheral-specific drivers).
Write a peripheral controller driver. While your ev kit BSP may come with drivers for all of your SoCs peripheral controllers, choose a relatively easy one -- UARTS, I2C, and SPI are usually relatively easy -- to write from scratch, stripping out the one that comes with the BSP. While we tend to have to do this less and less as BSPs improve, this exercise will dramatically flesh out your understanding of the MMIO software interfaces provided by modern SoCs, working with clocks and interrupts, creating good software interfaces for hardware, etc.
Setup a git repo for your projects in BitBucket or GitHub and use it like crazy; commit and push your changes frequently, create new branches when debugging issues or testing new code, merge branches, etc. In other words, simulate how you'll be using git. Your goal should be to have source code for all of your projects up here in a form that your prospective employers can look at.