Der Beispielcode zu Taking Photos Simply enthält eine hübsche Lösung für das Problem mit getExternalStorageDir - wichtig sind hier auch die SDK-Einstellugen im Manifest.
<uses-sdk android:minSdkVersion="4" android:targetSdkVersion="12" />Welche SDK-Version hast du in der Manifest-Datei definiert?
In deinem Code ist die main.xml leider unvollständig - da könnte noch was versteckt sein, glaub ich aber eher nicht.
Ich hab noch nicht mit TableLayout gearbeitet, darum kann ich dir konkret auch nix sagen.
Du hast dort aber (wohl für den TableLayout) android:layout_height="fill_parent" stehen - das kann manchmal andere Elemente vom Bildschirm vertreiben. Versuch es bei der Höhe am besten immer mit wrap_content. Um ein Element dann doch noch so groß wie möglich zu machen, hilft ein android:layout_weight="1"
Vielleicht verteilst du mal ein paar Hintergrundfarben, dann findest du die Elemente hoffentlich wieder...
Wenn du was spezielles machen willst, dann musst du den String dann selber zusammenbasteln - Tagnamen kannst du dir ja auch in 'nem Array speichern und darauf zugreifen.
In dem Fall ist Calendar eine hübsche Klasse, die dir ein Datum in seinen Einzelteilen bereitstellt.
Zitates wird ein Array Enemies[] geben, die alle als Rechtecke definiert sind (alle 4 Seitenkoordinaten inkl. Länge und Breite)
alle vier Koordinaten und noch Länge und Breite? Brauchst du die alle??
Gerade am Anfang speichert man sich oft zu viele Sachen, die man besser bei Bedarf (der ist nämlich eher selten) schnell mal berechnen kann. Wenn die Enemies alle gleich groß sind, dann genügt bei denen wirklich nur ein Punkt als x- und y-Koordinate (am besten in der Mitte). Die Fläche interessiert dann nur in der Kollisionsberechnung (z.B. x+3, x-3...).
Dasselbe gilt wahrscheinlich auch für deine Rechtecke. Du brauchst sie, um den Canvas neu zeichnen zu können, für die Kollision reicht aber das Rechteck des freien Platzes - es müssen ja alle Enemies innerhalb sein. Und wenn der User ein neues Rechteck abspaltet, den Teil in die ArrayList der Rechtecke einhängen, der Rest bleibt frei als freier Platz.
Für die Rechtecke gibt's auch was von Android: RectF - das brauchst du sowieso für den Canvas.
pobierst du mal .setTextColor(Color.WHITE); bei deinen Texten aus? Wird das dann besser??
Sinnvollerweise trennst du Berechnung, Daten und Ausgabe.
Die Daten werden wohl eine ArrrayList mit den Bots sein, die alle einen Punkt als Koordinaten haben - oder haben sie auch eine Fläche??
Und die Rechtecke - auch in einer ArrayList - haben zwei gegenüberliegende Ecken.
Eine Methode für die Prüfung if (bot.innerhalb(rechteck))... überlasse ich deiner Phantasie - das wird der einfachste Teil der Arbeit. 
Für die Ausgabe brauchst du einen Canvas, auf dem du die Elemente nacheinander draufmalst - übrigens immer wieder, wenn sich ein Bot bewegt hat. Dazu gibt's genug Beispiele in den API-Demos der Android-Doku.
Bei der Grafik solltest du auch an unterschiedliche Bildschirmauflösungen denken - auf einem Tablet solltest du nicht die volle Auflösung nutzen.
Interessant wird es, wenn du viele Rechtecke und Bots rumlaufen hast - dann wird das Timing spannend... *g*
Ich mag lieber den SAX-Parser, aber ich gebe zu, dass der für Anfänger sehr gewöhnungsbedürftig ist. Man muss sich erst mal mit der Idee anfreunden, dass der SAX einem ständig Aufrufe startElement(), characters() und endElement() schickt und man selber hofft, dass das XML fehlerfrei ist - naja, sonst gibt's sowieso eine Exception um die Ohren gehauen.
Aber eigentlich ist es das gleiche wie beim XMLPullParser, nur dass man nicht selber pull aufrufen muss und das Ergebnis auswerten - das ist bei SAX der Aufruf der entsprechenden Methoden.
In beiden Fällen musst du deine Datenstruktur gut im Griff haben und immer an den richtigen Stellen die neuen Elemente eintragen. Dazu nehme ich gerne eine Variable vom Typ Object und wenn ich Daten zum eintragen hab, schaue ich erst mal mit aktuellesElement.getClass() nach, was ich eigentlich gerade in der Hand hab und entscheide dann, wo ich das eintrage. Und einen kleinen Stack mit den geöffneten Tags kann man sich manchmal auch gönnen.
Die große Alternative dazu heißt DOM - da bekommst du das Document als Standard-Datenstruktur. Wenn du schon mal mit JavaScript im HTML rumgefummelt hast, dann war das DOM. Typische Aufrufe dort heißen getElementById oder getFirstChild - ja, so läuft auch der Zugriff in die XML-Dateien bei Android.
DOM ist aber normalerweise nur sinnvoll, wenn man die Document-Struktur verändern oder speichern will - wenn man die Daten nur einmal lesen und in eine eigene Datenstruktur eintragen will, dann ist XMLPullParser oder SAX wesentlich einfacher.
Man kann sich einen Parser aber auch selber bauen - das ist aber nur was für Liebhaber, denn einen Parser richtig gut zu bauen dauert dann doch wesentlich länger.
Der Aufruf von onDestroy ist nur etwas für abschließendes Aufräumen, nachdem schon alles zu Ende ist. Das kann manchmal viel später passieren, nachdem die Activity schon weg ist.
Vor onDestroy kommt immer noch onPause - da solltest du die Sachen besser reinpacken. Das ist nämlich der Zeitpunkt, bevor die Activity von der Anzeige verschwindet - und mit ihr alle View-Elemente.
Und die entsprechenden Aufbauarbeiten (Listener und Service binden) in onResume, dann sollte es zusammen passen...
Die Kommandozeile wirst du hier vergeblich suchen - die ganze Sache läuft komplett in der Dalvik Virtual Machine, also eine Ebene höher.
Wenn du nur Musik abspielen willst, dann ist der MediaPlayer die Klasse für dich.
Entsprechend gibt es auch andere API-Zugriffe auf andere Teile des Systems.
Aber wenn es um den Start anderer Apps / Activities/Services geht (oder deine App von woanders gestartet wird), dann ist der Weg immer folgendermaßen:
Der Punkt am Anfang der HomeActivity ist schon ganz ok, aber warum hast du die "Module_overview" in einem andern Paket?
Normalerweise sind die beide in demselben Paket und im Manifest müsste nur stehen:
<activity android:name="Module_overview"></activity>achja - noch eins: oben im Editorfenster gibt's einen kleinen Button für Java-Code-Formatierung (die Tasse) - damit wird Code vernünftig formatiert dargestellt. Bei so langen Codeausschnitten können wir das dann besser lesen. 
Die Stelle bei autoincrement hab ich auch gefunden. 
Einen weiteren Fehler solltest du noch korrigieren in der Zeile
public static final String KEY_PREISLITER = "Preis/Liter";Weil dieser String in der Datenbank-Erzeugung benutzt wird, ist der "/" ein Problem. Schreib lieber "PreisProLiter".
genau - erstmal mit while (sendeListe.size() > 0) anfangen und zuerst den Eintrag markieren als "Sendeversuch", dann eine kleine Methode zum Senden aufrufen (kann ein eigener Thread sein). Später dann nachschauen, ob das Senden geklappt hat (der Sender kann ja "gesendet" eintragen) und dann löschen.
Und wenn der Eintrag nach einer gewissen Zeit (gleich mit eintragen) nicht gesendet wurde, kannst du dir was überlegen - entweder längere Zeit warten (bis wieder Netzwerkverbindung besteht) oder den Benutzer informieren.
Ist zu dem Zeitpunkt, zu dem von woanders der Update aufgerufen wird, der TextView schon fertig da oder passiert das schon vorher?
Genauer gefragt, wann wird newMessage aufgerufen??
Hast du zwischendurch die Layout-XML-Datei geändert und irgendwelche IDs dazugeschrieben?
Dann einmal die Manifest-Datei neu speichern, damit die IDs neu durchgerechnet werden.
Der Teil mit den Android-Kontakten wird wahrscheinlich der einfachere: siehe Android-Doku ContactManager.
Für den Teil CSV musst du einmal den Benutzer eine Datei wählen lassen und diese Datei dann öffnen und in die richtigen Felder für einen neuen Kontakt reinbasteln. Aber schau dir erst mal den ContactManager an...
Vielleicht möchtest du die Nachricht erst mal nur in eine Warteschlange (ArrayList o.ä.) eintragen, dann kommt der Aufruf sofort zurück.
Dann musst du regelmäßig nachschauen, ob was zum senden vorliegt und dann einen Sendeversuch starten. Wenn der Versand erfolgreich war, kannst du den Eintrag aus der Warteschlange entfernen.
Wenn du mehrere Sende-Threads parallel laufen lassen möchtest (das ist ja das reizvolle bei Threads), dann aufpassen, dass du einen Eintrag nicht mehrfach verschickst. Stichwort [wikipedia]Threadsicherheit[/wikipedia].
Eine neue Klasse anlegen und dort folgenden Code eintragen:
public class GlobalDataPool {
public static int myInt = 0;
}
Wichtig ist hier das static, damit der Inhalt der Variable im Programmablauf erhalten bleibt.
Zugriff ist dann mit x = GlobalDataPool.myInt möglich.
Du kannst die static-Variable auch in einer anderen Klasse (z.B. die MainActivity) unterbringen.
Bei mir hilft seit ein paar Tagen in solchen Fällen folgende Zeile in "onResume()":
getWindow().setSoftInputMode(WindowManager.LayoutParams.SOFT_INPUT_STATE_HIDDEN);