La clave es limpiar el buffer sólo cuando sabes que no está vacío. ¿Cómo puedes saber esto? Depende, pero de forma muy general, cuando lees, por ejemplo, enteros y flotantes, scanf siempre deja el '\n' en el buffer, por lo que necesitas limpiarlo si la siguiente instrucción de entrada lee caracteres o cadenas. La función gets quita el '\n', así que no tienes que limpiarlo después de llamarla. Si lo haces, se producirá  el mismo problema de tener que introducir dos veces el salto de línea. Si usas fgets, la cosa cambia, pero eso lo puedes consultar en la documentación de esa función en cualquier manual.

P.D. La razón por la que te mencioné que no te aconsejaba la solución con fseek es que, por ejemplo, no funciona en Linux. Esto no es falla del SO, sino que en realidad los "streams", cuando no están asociados a un archivo real, no tienen por qué admitir búsquedas. La entrada estándar del teclado no es un archivo normal, así que puede o no admitirlas. En Windows funciona (por ahora) pero no es seguro saber si siempre lo hará. Esto no es meramente teórico; la propia fflush(stdin) funcionaba antes en Visual C++, y de hecho, la documentación oficial de Microsoft así lo especificaba, y sin embargo, hace unos años eliminaron esa funcionalidad y ya no funciona ni se menciona en la documentación actual. Así que la solución del fseek perfectamente podría dejar de funcionar en la siguiente actualización (o no, quién sabe) sin previo aviso. De cualquier manera, puesto que la manera estándar (como tu función) es tan simple, portable, y su funcionamiento está garantizado, no le veo sentido a usar una que no cumple con estas ventajas. En todo caso, si de todas maneras la quieres usar, deberías considerarla como a gets (algo temporal que igual vale para ejercicios de práctica, pero nada más). Y recomiendo checar esto: https://blog.codinghorror.com/the-works-on-my-machine-certification-program/

Algunas referencias sobre las búsquedas en stdin, por si te interesa.Para mi gusto las explicaciones están algo incompletas, y hay aún más razones para evitarlo, pero no están mal (en particular, la respuesta aceptada del primer linky sus comentarios):

https://stackoverflow.com/questions/16672672/can-fseekstdin-1-seek-set-or-rewindstdin-be-used-to-flush-the-input-buffer-i
https://stackoverflow.com/questions/4917801/using-fseek-with-a-file-pointer-that-points-to-stdin

Las formas estándar y portables de hacerlo son sólo variaciones de la que has puesto. En C++ puedes usar cin.ignore:

cin.ignore(tam, '\n');

que lee y descarta hasta "tam" caracteres o hasta encontrar un '\n'. Puedes usar un número muy grande para tam, o bien, numeric_limits<streamsize>::max(), que es el tamaño máximo de un stream:

#include <limits>
...
cin.ignore(numeric_limits<streamsize>::max(), '\n');

que básicamente significa que limpie todo lo que haya, hasta que encuentre el caracter de línea nueva. Hay alguna otra manera pero a final de cuentas, como te dije, son variaciones de esto.

Eso sí, evita fflush(stdin), que es directamente erróneo aunque a veces funcione. Otra solución que a veces se lee es mediante fseek, pera tampoco deberías usarla. Entre otras cosas no es portable y no hay ni siquiera garantía de que siga funcionando en las plataformas donde actualmente lo hace.

Lo del doble Enter no debería ser necesario. Creo que sé dónde está tu error, pero sería mejor su pusieras un código de ejemplo donde pase.

No soy ningún experto en el tema, pero sí lo he hecho, con una tablet y varios teléfonos. No vas a encontrar una guía universal de cómo hacerlo, ya que el procedimiento varia según el modelo, pero a grandes rasgos,  lo típico es instalar en tu PC drivers adecuados para el dispositivo y herramientas como adb (o según el celular, puede haber programas que te automaticen el proceso y te evitan teclear comandos), y con esto, desbloquear el bootloader, posiblemente flashear uno nuevo, y luego flashear la ROM.

Lo importante es que todo lo que descargues sea para tu modelo específico (incluso el número de revisión puede ser importante). Probablemente el mejor sitio para encontrar las guías y herramientas necesarias es https://forum.xda-developers.com/. Hay subforos para todas las marcas.

Y aunque es cierto que es preferible restaurar de fábrica, no siempre es solución. Si tienes un dispositivo que se quedó en una versión vieja de Android, pero por lo demás está en perfecto estado, puedes meterle una ROM no oficial más reciente y darle nueva vida. Sí se corre el riesgo de dañarlo, pero no es tan fácil. Incluso si le instalas algo incorrecto, muchas veces se puede arreglar vía software, y aún cuando no, la solución suele ser relativamente simple, aunque puede necesitarse alguna herramienta física. En todo caso, suele ser barato, ya sea que lo haga uno mismo o lo lleve a un taller. Con esto no quiero decir que sea imposible causar un daño más severo; siempre hay que ser cuidadosos, pero tampoco es para tener miedo si alguna vez necesitas hacerlo. Simplemente hay que leer y seguir bien las guías.

Por lo que dices, probablemente sea cosa de tu ISP. Muchas veces estas cosas pasan por problemas de DNS, pero no me parece que sea tu caso. Imagino que habrás probado hacer ping a otras URLs e incluso direcciones IP ¿no? Por ejemplo, ¿puedes hacer ping a 8.8.8.8? Si te da el mismo error, seguramente sea un problema específico del ping, lo cual también explicaría lo del WoW, pues muchos juegos en línea lo requieren. Si es así, seguro es un problema temporal; quizás tu ISP siga con problemas técnicos, o haya deshabilitado momentáneamente el tráfico ICMP por seguridad o algo por el estilo. En todo caso, si dura más de un día, yo los llamaría a ellos.

Trata de no mezclar los términos, o vas a ocasionar confusión. 5G y 5 GHz son cosas completamente diferentes. Si hablas de wifi, las bandas son 2.4 GHz y 5 GHz. En este caso, lo único que necesitas es verificar si admite la de 5 GHz (si tiene wifi, se da por sentado que soporta la de 2.4 GHz). La forma de comprobar esto varía según la versión de Android, pero una manera sencilla es simplemente ver si detecta redes de 5 GHz. O puedes instalar alguna app, como DevCheck, que en el apartado de red te da esa información.

Esas extensiones no tienen nada de especial, simplemente hay quienes las usan para hacer explícitas ciertas cosas.

Como sabrás, en C++ es común poner las declaraciones de funciones (y las "interfaces" de clases) en archivos de cabecera .h, y las implementaciones o definiciones en .cpp. Las cabeceras se incluyen con directivas #include , y los .cpp se compilan individualmente, y los archivos compilados resultantes se enlazan para formar el archivo final, por ejemplo .exe. Con las plantillas no se puede hacer eso, sino que también las definiciones se deben incluir en los archivos fuente como si se tratara de cabeceras (esto no es totalmente cierto, y en realidad es más complejo, pero es "correcto" de forma general). La opción más obvia sería poner las definiciones directamente en las cabeceras, pero normalmente es preferible hacer la separación de interfaz e implementación, aunque sea sólo por legibilidad. Otra forma de hacerlo es seguir separando el código con plantillas en cabeceras y  archivos .cpp, pero incluir los propios .cpp con directivas #include, justo como con los .h. Sin embargo, esto podría prestarse a confusiones. Un programador que reciba archivos .cpp y .h, podría suponer que los .cpp se deben compilar por separado, como es lo normal, pero dado que estamos hablando de plantillas, eso sería incorrecto. Si, en cambio, se usa otra convención, es posible evitar esas ambigüedades. En este caso, se supone que si el programador ve archivos .inl, sabe que no debe incluirlos para compilarse en el proyecto, sino simplemente usar las cabeceras que desee (las cuales a su vez se encargan de incluir las implementaciones, dado que son .hpp), y ya está.

Esto no es algo generalizado, y no todos lo usan, ni lo conocen. Al final da igual la convención que se use, siempre que todos los que vayan trabajar en un proyecto la conozcan y se apeguen a ella, así que no le veo mucho sentido a recomendar o no su uso. Es simplemente una opción.

Es normal lo que pasa, dado que el GetAsyncKeyState únicamente se llama al inicio de cada iteración del bucle. Una vez que entras a él, todo lo que está dentro del bloque se ejecuta, y después se hace la comprobación.

La forma en que estás usando esta función (verificando el bit menos significativo) no está mal, pero puede dar problemas y no se recomienda mucho su uso. Mira aquí (en concreto lo de "Although the least significant bit..."): https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getasynckeystate#remarks

Para ejercicios de prueba lo puedes usar, pero lo recomendable es limitarse a probar el bit más significativo (GetAsyncKeyState(codigo) & 0x8000), aunque no hace lo mismo, y en este caso probablemente no te sirva. De todas formas, tu código tiene un problema de fondo, y es que funciones como GetAsyncKeyState no se llevan muy bien con los mecanismos de entrada estándar de C++, como cin, getchar, etc, y es mejor evitar mezclarlos así. Mejor haz algo como lo que te puso  Locura_23, aunque en ese caso, deberías limpiar el buffer antes del cin.get, o leerá el '\n' dejado por el cin anterior. No sé si sepas hacerlo, pero por si no, una forma con cin.ignore:

#include <limits>
...
while (...) {
	...
	cin.ignore(numeric_limits<streamsize>::max(), '\n');
	cin.get(controlUsuario);
}
 

Aunque hay otras igualmente válidas. Simplemente hay que evitar las que involucran fflush o fseek. Obviamente, a diferencia de GetAsyncKey, con cin.get, el usuario deberá presionar Enter después de la 's', pero no me parece que eso sea un problema.

No vi eso. Lo que te puse aplica sólo para Windows. No sé cómo sea la terminal de Android que uses, pero se usa UTF-8 igual que en Linux, por lo que quizás algo así te pudiera funcionar:

setlocale(LC_ALL, "es-ES.UTF-8")
wcin.imbue(locale("es-ES.UTF-8"));
wcout.imbue(locale("es-ES.UTF-8"));

Y usarías las funciones y tipos "wide" para manejar texto. En lugar de cout, cin, string y char, usarías wcout, wcin, wstring, wchar_t, etc. Pero yo nunca trabajo de esta manera en la terminal, así que no sé si te sirva.

Pensándolo mejor, aunque usar las funciones wide hace más explícito el hecho de que en Unicode los caracteres pueden ocupar varios bytes (lo cual pensé que te podría evitar errores), creo que al final podría ser más confuso, por lo que igual puedes aplicar el imbue a cin y cout y seguir usándolos sin tener que lidiar con wcout y demás. De cualquier forma, no deberás usar variables char simples sino arreglos char o directamente string, aún si únicamente quieres leer un solo caracter.

Siempre es un dolor de cabeza trabajar con localización, sobre todo en Windows. No está mal como lo estabas haciendo, pero debes asegurarte de que la consola use la misma codificación. Cuando usas "Spanish" o "es-ES" para el locale, en realidad es como si pusieras "Spanish_Spain.1252". O sea estás configurando el código de página ANSI 1252, pero, si no recuerdo mal, la consola usa una codificación OEM, por lo que eñes y acentos no van a salir bien. Necesitas cambiar también la consola:

setlocale(LC_ALL, "es-ES");
/* O bien
setlocale(LC_ALL, "Spanish_Spain");
o
setlocale(LC_ALL, "Spanish_Spain.1252");
*/
 
// Cambia la salida
SetConsoleOutputCP(1252);
 
// Y la entrada
SetConsoleCP(1252);
 

Sin embargo, aunque ahora mismo no tengo donde probarlo, estoy casi seguro de que la fuente que usaba por defecto la consola en Windows 7 no tenía eñes ni acentos para esa codificación, por lo que si quieres que funcione en esa versión o anteriores debes asegurarte de cambiarla.

Alternativamente, puedes poner el locale a OEM:

// O "Spanish_Mexico.850", "Spanish_Argentina.850", etc
setlocale(LC_ALL, "Spanish_Spain.850");
// Es buena idea asegurarse de que la consola esté igual
SetConsoleOutputCP(850);
SetConsoleCP(850);
 

esto me parece que no tiene el problema de las fuentes en versiones anteriores de Windows, pero es más recomendable la forma anterior.

Esto aplica para los valores que se muestran y leen en la consola, pero no significa que los caracteres especiales que escribas en tu código se muestren correctamente. Eso depende de la codificación que use el editor con el que lo escribes, por lo que es muy mala idea usar este tipo de caracteres en el código (si lo abres en otro editor, o en el mismo editor pero en otra máquina o sesión, te lo va a descomponer). Una forma más portable es usar sus valores numéricos:

//Para ANSI 1252
cout << "Ingrese la Letra 'E""\xF1""E'" << endl;
//Para OEM 850
cout << "Ingrese la Letra 'E""\xA4""E'" << endl;
 

hay formas mucho mejores de manejar la localización, pero también son más complicadas. Para cosas simples yo creo que con esto basta.

Pues esa es la forma tradicional de hacerlo, pero justamente implica lanzar un nuevo proceso, que pensé que era algo que no querías, así que supuse que ya la conocías pero buscabas otra manera. Imaginé que necesitarías comunicación hacia y desde la parte privilegiada, y de ahí lo que mencioné de IPC.

La alternativa del componente COM, aunque tiene sus inconvenientes, como todo, tiene la gran ventaja de que, aunque técnicamente el componente se ejecutaría en un proceso subrogado (por defecto, dllhost), COM se encarga de los detalles de la comunicación, por lo que uno se limita a llamar funciones, pasar parámetros y recibir resultados prácticamente de la misma manera en que lo haría con cualquier programa normal.

Pero sí, cuando sólo se necesita cosas más sencillas como ejecutar tareas más o menos independientes, la forma en que lo hiciste es la más simple y recomendable