Das klingt für mich ganz so, als würde Deine Grafikkarte OpenGL ES nicht unterstützen.
Für Android Apps ist das aber leider eine Grundvoraussetzung.
Ich würde also in dem Fall auch die GPU deaktivieren und alles über die CPU machen lassen.
Dauert natürlich entsprechend länger.
Woran erkennst Du, dass das VD überhaupt nicht hoch fährt und nicht einfach nur 'nichts anzeigt'?
Wenn Du 'zu viele' Elemente auf "always" setzt, als das sie auf die Actionbar passen könnten, dann passiert was?
Das "always" wird ignoriert, die Icons landen trotzdem nicht auf der ersten Ebene in der Actionbar.
Oder hat sich da seit 5.0 etwas Gravierendes verändert?
Was ist an der Antwort 'DU bekommst da nicht mehr Einträge rein' sachlich falsch?
Klar, 'Je nach Einstellungen und verfügbarem Platz regelt das System für Dich, wie viele Einträge da oben landen. Du selbst hast keinen allzu großen Einfluss drauf.' wäre vollständig erklärt.
Die Grundaussage 'DU bekommst da nicht mehr Einträge rein' bleibt allerdings dennoch bestehen.
Ja, klar. Auf dem Nexus 10" im Landscape kann man da sicherlich die ganze Breite mit Icons vollkloppen. 
Da es sich um eine Anfängerfrage handelt und ich sie so interpretiere, dass gewünscht wird, die im Standardfall angezeigten Symbole der Aktionbar mengenmäßig zu erweitern, antworte ich halt anfängertauglich auf den Standardfall bezogen.
Soweit ich die Frage richtig verstanden habe, lautet die Antwort 'gar nicht'.
Du hast im Allgemeinen die beiden wichtigsten Aktionen in Deiner ActionBar und dann noch eine Dritte, die ein Menü mit weiteren Aktionen darstellt.
Indem Du den Service nicht bindest sondern startest und beendest.
Anfänger bei einer Programmiersprache zu sein ist ja etwas Gutes.
Anfänger bei Problembeschreibungen zu sein ist eher etwas Schlechtes.
Kommunikation ist alles. 
Wieso solltest Du keinen Zugriff auf den Speicher haben?
Du kannst über die Content Provider in den relevanten Medien stöbern und darauf zugreifen.
Ich verstehe die Frage nicht.
Wenn Du mit Upload der App das Spielen der .apk auf das Gerät meinst: das machst Du doch bereits über den 'Run' Button.
Eventuell willst Du aber auch ein fertiges .apk zur Weitergabe generieren. Dazu musst Du ein signiertes Paket erstellen lassen.
0) Klar gibt es den Status 'Offline' noch. 
1) Wie in einem anderen Thread schon angesprochen ist die Übergabe von Referenzen nicht möglich. Übergib lieber eine ID, an Hand derer Du den gewünschten Eintrag eindeutig identifizieren kannst.
2) In Android geht alles via SQLite.
Exakt.
Meist eine Instanzvariable Deiner Activity.
1) Nein.
2) Gar nicht.
Android/Java arbeitet an dieser Stelle nicht mit Referenzen sondern mit Kopien.
Die HashMap oder deren Inhalte zu kopieren wäre ein systematischer Selbstmord.
Statt die HashMap im Speicher zu halten gehört die lokal gespeichert (beispielsweise in eine SQLite Datenbank) und dann in den betreffenden Activities/Fragments ausgelesen.
Zu diesem Zweck kannst du via Intent.putExtra() Deine ID des gewählten Eintrags an die zweite Activity übergeben, welche diese ID zum gefilterten Laden der Daten verwendet.
Über einen Server.
Automatische Informationen über Änderungen kannst Du entweder pollen (sprich: jeden Morgen um 7:00 Uhr den Server fragen) oder pushen. (sprich: Notification ans Gerät, woraufhin der User dann den Server fragt)
Totaler Automatismus wäre Push Notification und die App fragt den Server selbständig ab. So machen das die Chatprogramme im Allgemeinen.
Wie sinnvoll das ist weiß ich nicht. Wird der Vertretungsplan quasi minütlich aktualisiert, hast Du ganz schön Traffic auf der Leitung und solltest die User entscheiden lassen, ob sie die Änderungen ziehen wollen.
Lies Dich mal in die Google Cloud Messaging ein:
https://developer.android.com/google/gcm/index.html
Callbacks. (onServiceDidFinishSending(), onServiceDidFinishReceiving(), onServiceSentData(), onServiceReceivedData(), onServiceWillReceiveDataAmount(), onServiceWillSendDataAmount()…)
Gepaart mit einem ContentProvider, der im Falle des passenden Callbacks die dazugehörigen Daten abrufen kann. (getReceivedFile() oder Ähnliches)
Ich denke mal, das sollte über die Transparenz des Icons geregelt sein.
Die Pixel, die quasi die ersten nicht-transparenten Pixel sind, werden für die Umrandung genutzt bzw. wenn gerade nicht-transparente Pixel aktuell waren werden dann die ersten transparenten Pixel für die Umrandung genutzt.
Wenn Dein App Icon also ein PNG mit Alpha-Kanal ist, solltest Du diesen Effekt gratis bekommen.
Wo zeichnet denn bitte die Musik irgendwas hin? 
Audio ist was völlig Anderes, die ist nicht an einen Context gebunden.
Aber auch da geht nicht alles. Wenn Du beispielsweise eine Telefonieapp baust und neben dem Telefonieren Musik hörst, kannst Du unmöglich die Musik auf den externen Lautsprecher und die Telefonie auf den internen Lautsprecher oben lenken.
Geht dann plötzlich beides über dieselbe Audioroute.
Ich bilde mir ein, dass das bei mir lief.
Hast Du mal den Activity Lifecycle mitloggen lassen um zu sehen was aufgerufen wird, wenn Du via Zurück-Button die App verlässt?
Nein, das heißt nicht, dass der Fehler bei Intent i = new(this, my_service.class); liegt.
Wie Du so einen Intent erzeugst ist ja völlig egal.
Der Fehler liegt in Deinem Service: dieser verlässt sich auf die Existenz eines Context im Intent.
Dieser liegt aber maximal in einem von drei Konstruktoren vor und kann auch zur Laufzeit wieder verschwinden.
(Genau genommen in zwei von sechs, was am Verhältnis nichts ändert.)
Du brauchst aber einen Context um zu zeichnen.
Die logische Schlussfolgerung: Du kannst aus einem Thread heraus nicht zuverlässig auf die UI zugreifen, wenn Du keine App mitlieferst, die ein dafür vorgesehenes UI hat.
Du hast im Grunde genommen folgende drei Möglichkeiten:
1) Pack einfach eine App drum rum.
2) Wenn Du ein Widget bauen willst, dann lies Dir die Dokumentationen zum Bau von Widgets durch.
3) Wenn Du ähnlich wie in den Entwickleroptionen über sämtliche Views im Vordergrund irgendwas zeichnen willst, lass es sein.
Ich denke aber, dass eine App sich erheblich schneller verbreitet, als eine Web-App, oder?
Erheblich schneller?
Bei einer gefühlten Million an mehr oder minder sinnvollen Apps musst Du Dir echt was einfallen lassen, den durchschnittlichen Smartphone-Benutzer auf Deine App aufmerksam zu machen.
(Tatsächlich sind es wohl allein im Google Play Store 1.391.247 Apps.[1])
Und das kann nur funktionieren, wenn die App neben einem wirklich sinnvollen Mehrwert auch ein endgerätenahes Look'n'Feel bietet.
Das ist beiApps, wie sie PhoneGap und Co. produzieren allerdings nie der Fall.
Wenn Du es wirklich 'richtig' machen willst, dann ist Dein Vorhaben zumindest ambitioniert.
1) Für das iPhone brauchst Du neben einen jährlich zu bezahlenden Entwickleraccount (das letzte Mal 79€) auf jeden Fall einen Mac.
Dann hast Du die Wahl zwischen Xcode von Apple und AppCode von IntelliJ.
Und mittlerweile kannst Du zwischen Objective-C oder Swift als Programmiersprache wählen. Auf jeden Fall eine komplett neu zu lernende Sprache.
(C/C++ lass ich hier mal außen vor, das geht zu sehr in die Tiefe.)
2) Android ist da ein bisschen kulanter. Für den Entwickleraccount zahlst Du einmalig eine Schutzgebühr (als ich das gemacht habe 25€).
Hier kannst Du zwischen allem Möglichen wählen. Googles Android Studio, IntelliJs IDE, das gute alte Netbeans, Eclipse… Sie alle können für Android bauen.
Die Android Entwicklung beschränkt sich auf Java. Wieder eine komplett neu zu lernende Sprache.
(Auch hier lasse ich C/C++, python und Co. außen vor.)
3) Windows Phone… Ich habe keine Ahnung wie der Prozess zur Erstellung eines Entwickleraccounts da abläuft.
Als IDE gibt es dort sicherlich nur Visual Studio von Microsoft und ganz eventuell geht das Ganze auch mit #Develop.
Hier bist Du vollständig auf C# oder Visual Basic und das .Net Framework angewiesen. Wieder eine neu zu lernende Sprache.
Wenn Du mitgezählt hast, sind wir jetzt bei 3 neu zu erlernenden Sprachen.
Dazu kommen 3 neu zu erlernende Frameworks. (Cocoa, Android und .Net funktionieren unglaublich unterschiedlich.)
Passenderweise bedeutet das auch: 3 mal komplett unterschiedliche Konzepte für dasselbe Problem überlegen.
Natürlich musst Du Dich dann auch noch 3 mal um Visuelle Gestaltung (Graphiken, UI Design), betriebssystemnahe Bedienbarkeit, Verteilung etc.pp. kümmern.
Und wenn Du dann noch BlackBerry dazu nimmst, welche zumindest seit Blackberry OS 10 in C++ mit einer Eclipsevariante programmiert werden, kannst Du aus jeder 3 eine 4 machen.
Nun könnte man einwenden, dass Projekte wie Mono[2] eine Alternative sind. Einmal alles in C# geschrieben, auf einen Knopf gedrückt und fertig.
Ja, das mag stimmen. Allerdings werden in dem Zusammenhang die visuelle Gestaltung und die betriebssystemnahe Bedienbarkeit stark vernachlässigt.
Weiterhin können die Besonderheiten der einzelnen Plattformen nicht im Speziellen genutzt werden.
Wie dem auch sei.
Meiner Einschätzung nach ist die Konkurrenz in den App Stores groß, der Verwaltungsaufwand enorm und die Verteilung gering.
Für Deine App werben musst Du nämlich so oder so. Das machst Du dann am Besten im Internet und auf Deiner Homepage.
Bei der die Nutzer dann feststellen, dass die App auch nix anderes macht als Deine Website.
Ich würde es an Deiner Stelle sein lassen.*
[1] http://www.appbrain.com/stats/number-of-android-apps
[2] http://www.mono-project.com
//Nachtrag_
* Bezieht sich auf den Hintergrund, dass Du offenbar unbedingt überall eine App im Store haben willst. Wenn Du aber totales Interesse an einem iPhone/Android hast und unbedingt dafür entwickeln willst – leg los!
Und zwar nur dafür.
Du kannst 'den UI Thread' nicht 'manipulieren'.
Der Sinn von Threading ist, dass der eine Thread vom anderen Thread unabhängig ist. Er muss nicht einmal wissen, dass da ein anderer Thread existiert.
Logisches Resultat: der eine Thread weiß überhaupt nicht, ob da ein anderer Thread existiert. Noch weniger kann er da irgend etwas manipulieren.
Wie Du mit der UI interagieren kannst hängt in erster Linie davon ab, welche Art von Service Du implementierst.
Wird der Service an die UI gebunden (beispielsweise bei einem Chat, einer Datenübertragung, einem Spiel, einer Fernsteuerung…), dann hat Dein Service gewisse Informationen über die UI und Du kannst die Mittel und Wege zur Interaktion bereit stellen.
Läuft Dein Service hingegen ohne UI (Indoor-Navigation mit iBeacon oder WLAN, Profilwechsel via NFC, Loggen von WiFi/Bluetooth Qualität zur späteren Analyse), dann wird Dein Service unabhängig des UI gestartet und nach Beendigung seiner Arbeit gestoppt. Hier hat er absolut keine Informationen über irgendwelche UI-Elemente die irgendwas von ihm wollen und Du musst probate Mittel zur Kommunikation anbieten.
Eine Mischung aus Callbacks zum Registrieren und ContentProvider zum Abfragen von Änderungen habe ich für einen solchen Fall als Ansatz gewählt.
