Jeder Hinweis auf Geräte, auf denen die App nicht angezeigt oder unterstützt wird ist hilfreich, um das Problem einzugrenzen.
Du siehst direkt nach dem Hochladen des APK, welche Geräte unterstützt werden und welche nicht.
Es gibt da so ein schickes Feld mit einer Anzahl von unterstützten Geräten. Einmal auf 'Liste ansehen' klicken und Du bekommst genauere Informationen.
(Über die Geräte, nicht über die Ursache des Ausschlusses – leider.)
Ich glaube am Simpelsten ist es, Du prüfst in der onKeyDown, was genau da eigentlich ankommt.
So ein spezielles MDE Gerät muss sich nämlich nicht an die Tastenkeys halten, die das System da vor gibt.
In erster Linie ist es bei mir auf Deutsch. 
Ansonsten liegt halt genannter Link in genannter grauen Box.
Nur so am Rande: Du nutzt keine Funktionen des NDK?
Falls doch: schau mal, welche Prozessoren Du da unterstützt.
Der Screenshot ist schwer zu erkennen.
Insofern weiß ich nicht, ob das in den Java Buildpaths richtig ist oder lieber direkt mit dem Projekt verbunden gehört.
Also der Link steht sonst eigentlich immer dort.
Unter dem 'Opt-In' hab ich ein graues Textfeld mit einem Link.
Und die sind bei mir wie folgt aufgebaut:
https://play.google.com/apps/testing/<paketname>
Also zum Beispiel:
https://play.google.com/apps/testing/com.example.DemoApp
Ja, das läuft. 
<uses-permission android:name="android.permission.VIBRATE" />
Ich bin mir sicher, dass nicht alle Geräte einen Vibrator haben.
Vielleicht die JODB?
http://www.java-objects-database.com
Ansonsten sind Hibernate und greenDAO Optionen, allerdings soweit ich weiß via Mapping.
Window -> Android SDK Manager -> Extras -> [√] Google Play Services
Und dann installieren.
Also ich höre davon zum ersten Mal und bin zwiegespalten.
Einerseits eine supergeile Idee.
Genau die Dinge nerven mich nämlich an Java gewaltig.
Andererseits gibst Du damit die Kontrolle ab.
Es ist immer besser zu wissen, was man tut und wie Dinge funktionieren als dass man sich alles abnehmen lässt.
Das Swipe-Layout drum rum packen?
Ich würde auf jeden Fall auch auf PHP verzichten und eine andere Skriptsprache bevorzugen.
Vom Abgreifen mit Sockets rate ich ja immer wieder gern ab.
Das Internet besteht quasi aus asynchronen Verbindungen mit permanentem Auf- und Abbau.
Lieber kannst Du Dir in Ruby, Python oder Java einen eigenen kleinen 'Webserver' schreiben (der im Gegensatz zum richtigen WebServer dann halt kein HTTP/HTTPS kann), der Deine Daten pflegt und füttert und meinetwegen in HTML5 ein Web Backend dahinter schrauben.
Die wirkliche Herausforderung das Ganze professionell aufzuziehen, und da haben die Großen die besseren finanziellen Mittel, ist die Skalierbarkeit der Server sowie die Sicherheit der Verbindung.
Hochskalierbare Datenbanken werden übrigens auch von den genannten Betreibern nicht eingesetzt. Sie sind einfach sauteuer und recht kompliziert.
Noch größere Zugriffszeiten aus WhatsApp und Co haben die Lagerverwaltungssysteme großer Unternehmen – und da wird selten SQL eingesetzt.
Ich schließe mich der Meinung meiner Vorredner an:
1) Sehr spannendes Projekt. =)
2) Selber bauen wäre die bessere Option.
Zum Einen kann Tasker zwar offenbar eine ganze Menge, aber es nützt Dir nichts, wenn es den Task nicht in dem Moment ausführt, in dem Du es gern hättest.
Insofern müsstest Du also einen eigenen 'Tasker' schreiben. Vielleicht gibt es ja bestimmte Actions/Intents, auf die Tasker lauscht. Wenn dem so wäre, bräuchtest Du nur einen Broadcaser, der eben dieses Intent feuert, sobald der Akku leer oder voll genug ist.
Ansonsten lässt sich die App aus einigen Komponenten ziemlich einfach zusammenstricken:
1) Ein Broadcast/Service, der auf die Änderungen des Akkuzustandes lauscht. Wenn Akku > 80% und ladend, dann sende 'genug!', wenn Akku < 15% und entladend, dann sende 'brauche Strooooom!'
(80% weil Akkus ja auch gern mal nachlassen können. Irgendwann erreichen sie die 100% einfach nicht mehr und dann würde das Ding ewig versuchen zu laden.)
2) Einen Bluetooth Controller, der dem angeschlossenen Relais sagt 'Schalte EIN' und 'Schalte AUS'.
3) Eine Kontrollschicht, die den Broadcast des Services erhält und entsprechend den Bluetooth Controller steuert.
Ist also alles nicht allzu aufwändig.
Stimmt, beim Zitieren war der Copy'n'Paste Finger etwas zu schnell.
Was Axel Springer betrifft:
Sämtliche Fachzeitschriften, Wirtschaftspublikationen und Tageszeitungen sind allesamt auf dem Bild* Niveau.
Zumindest inhaltlich. Immerhin passt die Relation Bildergröße/Überschriftengröße bei allen Printmedien, die kein 'Bild' im Namen haben. 
Mit über 500 Millionen aktiven Nutzern kann man nicht sagen das WhatsApp unprofessionell ist.
Warum sollte man das nicht sagen können?
Nur weil es weit verbreitet ist und überall Anklang findet, heißt das ja noch lange nicht, dass es professionell und gut sein muss.
Beispiele aus der Realität gefällig?
– Microsoft Windows
– Christlich-Demokratische Union/Christlich-Soziale Union
– Axel Springer Verlag
– Casting Shows
– PHP Hypertext Preprocessor
Wie dem auch sei.
Zitat von AllesFAMDenn ich denke berühmte Apps wie Whatsapp, Tinder, Facebook etc. werden die Daten doch sicher nicht per Php abgreifen oder?
Facebook bietet eine PHP API an.
https://developers.facebook.com/docs/reference/php/4.0.0
Kein Wunder, ist die Online-Variante doch nahezu komplett in PHP erstellt.
https://www.facebook.com/notes…odebase/10150187460703920
Mittlerweile basteln die Jungs wohl an ihren eigenen Betriebssystemen herum, pimpen ihre PHP Compiler um schnelleren Code anzubieten und biegen auch an sonst jeder erdenklichen Stelle an ihrer Hardware, um Skalierbarkeit zu gewährleisten.
http://royal.pingdom.com/2010/…software-behind-facebook/
Nichts desto Trotz: sie greifen ihre Daten per (leicht modifiziertem/abgewandeltem) PHP ab. Da das ungefähr 1,5 Millionen Daten pro Sekunde oder mehr sein dürften (pro Sekunde werden durchschnittlich ungefähr 3000 Bilder hochgeladen), müssen sie halt mehr in die Skalierung und Verteilung ihrer Systeme investieren. Das Rad neu erfinden und was Anderes als PHP nutzen werden sie aber sicherlich nicht. 1.000 Module mal eben von PHP umschreiben – ich denke nicht.
Tinder Anmeldung ist gemäß Wikipedia ausschließlich via Facebook-Kontoanmeldung möglich. Facebook bietet eine PHP API an.
Für WhatsApp gibt es eine inoffizielle PHP API, mit der sich die Grundfunktionen von WhatsApp umsetzen lassen.
https://github.com/venomous0x/WhatsAPI
Ich stimme Dir in einem Punkt zu: PHP ist nicht das Gelbe vom Ei, was Skriptsprachen angeht.
Moin nach Bremen!
Ah, Du benutzt dort Views aus einem Third-Party Framework.
In dem Fall würde auch ich auf jeden Fall alles, was Du an Instanzvariablen (bzw. 'Membervariablen') in Deiner Activity hast, explizit auf NULL setzen.
Ansonsten kann es durchaus sein, dass da noch irgendwelche Referenzen gehalten werden und die Garbage Collection nicht vernünftig aufräumen kann.
Wenn die onDestroy() zuverlässig aufgerufen wird, solltest Du dort die Aufräumarbeiten durchführen.
was genau saugt den Akku so schnell leer bei einer ruhenden offenen Socket-Verbindung ?
Die bestehende Verbindung zum WLAN/Mobilen Internet sowie die permanente Prozessoraktivität. 'Ruhend' heißt ja nur, dass dort gerade weder Daten ankommen noch abgehen.
Dennoch wird auch bei einer ruhenden Verbindung permanent auf dem Socket gelauscht.
Es ist ja nun nicht so, dass ein Männchen mit Wimpel plötzlich aufspringt und dem System anzeigt, dass es jetzt auf dem Socket lauschen muss…
Welche Technik nutzt GCM um ad hoc Nachrichten auf das Gerät zu senden, wenn keine
Socket-Verbindungen bestehen ?
Wer sagt denn, dass keine Socket-Verbindung besteht? Ich spreche davon, dass man selbst keine Socket-Verbindung für diesen Anwendungsfall aufmachen soll.
Die Socket Verbindung für GCM wird durch das System offen gehalten und agiert in der Hauptsache mit dem Google Play Store (weshalb der auch zwingend benötigt wird – Android Market reicht nicht)
Es haben also Menschen aus Fehlern (G2DM) gelernt und etwas Funktionierendes geschaffen. Es wäre überheblich zu glauben, eine Eigenimplementierung liefe besser als Googles Ansatz.
Du könntest statt eigener Activities lieber Fragments verwenden, das erleichtert Dir später auch die Anpassung auf's Tablet.
Von irgend etwas auszugehen ist übrigens eine ganz schlechte Idee.
Nun, normalerweise sollte der GarbageCollector Deine Instanz wegräumen, wenn sie nicht mehr benötigt wird und es dürfte nie zu einem Speicherüberlauf kommen.
Du schreibst allerdings, dass Du in der onCreate Deiner Activity eine weitere Activity erstellst.
Nun kann ich nicht mit Bestimmtheit sagen, ob der Garbage Collector überhaupt eine Chance hat da irgendwas wegzuräumen.
Eventuell könntest Du (wenn Du unbedingt den eingeschlagenen Weg weiter verfolgen willst) Deinen Intent in eine Instanzvariable auslagern und auf diese zugreifen.
Da mir aber die Informationen fehlen, wann warum Du eine neue Activity aufrufst, kann ich hier nur raten.
