Da herrscht Stillschweigen, weil Dein AdapterView höher in der Hierarchie hängt und entsprechend mehr abfängt.
Eigentlich sind für solche Sachen ja auch eher die PagerAdapter gedacht.
Ich weiß nur gerade nicht, wie so eins in Deine UI Gestaltung passen könnte.
Oh, okay.
Dann musst Du das auf ein anderes View packen. Beispielsweise das View der Activity/des Fragments.
Dein Bedienkonzept scheint mir ein wenig an der Realität vorbei. Du wischt auf einem Eintrag herum, tauscht aber alle Inhalte aus.
(Normalerweise würde ICH denken: wische auf Eintrag nach links -> wird abgebrochen; wische auf Eintrag nach rechts -> wird auf morgen verschoben.)
Wie dem auch sei, Du kannst eigentlich jedem View einen OnClickListener mitgeben.
Wenn Du Deine Logik also nicht in die onItemClick–Callbackmethode des AdapterView packst (denn wie Du selbst festgestellt hast, wird die aufgerufen, wenn ein Item angeklickt wird) sondern in die onClick–Callbackmethode des AdapterView, sollte das passen.
Es kann dann im Nachhinein natürlich wichtig sein, dass Du die Touchevents an die darunterliegenden klickbaren Items weiterreichst.
Naja, ich sehe an dem Punkt nicht, wo mContext gesetzt wird, insofern wird das Problem da zu finden sein.
Erbt Deine Klasse von Context? Dann brauchst Du die Membervariable nicht.
Ansonsten musst Du den Context irgendwo an einer passenden Stelle übergeben.
Gute Frage.
Was soll eigentlich Columns.COL_ID + " = ?" bedeuten?
Naja, Du solltest schon das Layout rein laden, dass Du sehen möchtest.
Wenn layoutResID die falsche ID ist, musst Du die korrekte ID finden.
Gar nicht.
Das ist nicht der Weg, wie es funktioniert.
Das ist, mit Verlaub, sogar totaler Blödsinn.
Und zwar aus mehreren Gründen:
Ja, es mag kompliziert sein.
Zumindest bis man es verstanden hat.
Wenn man es nicht verstehen will, dann sollte man sich seine App lieber programmieren lassen.
Nuja, so richtig genau sind so RFID Dinger ja nun leider nicht.
Meinst Du nicht eher dieses Bluetooth LE Gespiele, von Cupertino als 'iBeacon' bezeichnet? Aber auch die Dinger sind so genau leider nicht.
Du müsstest es also zunächst einmal auf die Reihe bekommen, eine entsprechend gute Ausleuchtung mit den Chips realisiert zu bekommen: für eine verlässliche Triangulation brauchst Du (gemäß des Namens) immer drei Chips in Reichweite.
Ein Hauptproblem ist allerdings, dass Google Maps und Navigationssysteme Dich nicht einfach so direkt auf die Karte pappen. Karten bestehen (wie beispielsweise bei OpenStreetMap) immer aus zwei Teilen: grafische Darstellung und logische Informationen. Letztere wären die Weginformationen, sprich: wo befindet sich ein entsprechend nutzbarer Weg.
(Lieblingsspruch eines günstigen Navigationssystems mit veralteten Karten: "Sie befinden sich außerhalb des kartographierten Bereichs.")
Es reicht also nicht, den Grundriss der Wohnung mit PhotoShop zusammenzuklicken und in die App zu packen. Du musst auch Wege vermessen und anlegen.
Und dann musst Du zusehen, dass Du die Triangulationswerte irgendwie mit Annäherung an die Wege bringen musst.
Alles in Allem: trivial geht anders. 
Ich sehe nicht, wo Du aufteilen() aufrufst.
Davon ausgehend dass Du Dich für die onTouch Events registriert hast, ist das eigentlich ziemlich simpel.
Im MotionEvent Objekt steht alles Notwendige drin: Anzahl der Finger, mit denen berührt wurde, Art der Berührung (Antippen, ziehen, loslassen…), Position je Finger, Druck je Finger…
Die Berechnungen ('alten' Punkt merken, Richtung und Entfernung zum neuen Punkt, Umwandeln von Punkten in Millimeter oder was sonst noch gewünscht ist) musst Du natürlich selbst durchführen.
Gern.
Irgendwann steht der Rechenaufwand aber vermutlich in keinem Verhältnis mehr zum Resultat.
Ausgezeichnet, da läuft also irgendwas schief. =)
Offenbar hat die Doku irgendwo gelogen. Es sieht für mich so aus, als würde Deine Eingabe nicht von oben links nach unten rechts aufgelöst, sondern total willkürlich.
Snippet 1 geht von topLeft -> topMid -> midLeft;
Snippet 2 geht von topMid -> topRight ->midLeft;
Alle Weiteren werden stumpf ignoriert.
Zurück zur Dokumentation:
Zitatverts Array of x,y pairs, specifying where the mesh should be drawn. There must be at least (meshWidth+1) * (meshHeight+1) * 2 + vertOffset values in the array
Das ist gegeben. Also weiter im Text.
ZitatmeshWidth The number of columns in the mesh. Nothing is drawn if this is 0
meshHeight The number of rows in the mesh. Nothing is drawn if this is 0
Das bedeutet wohl, Du musst die Angaben in Breiten und Höhe gemäß Deiner Koordinaten anpassen.
// also statt
canvas.drawBitmapMesh(screenshot, 1, 1, mPoints, 0, null, 0, null);
// Bedeutet: erzeuge mir eine Zeile und eine Spalte; also ein einziges Feld.
// lieber
canvas.drawBitmapMesh(screenshot, 2, 2, mPoints, 0, null, 0, null);
// Bedeutet: erzeuge mir zwei Zeilen und zwei Spalten; also vier Felder.
Je detaillierter Du das Bild darstellen willst, desto mehr Zeilen und Spalten musst Du auch zusätzlich zu den Punkten definieren.
Sieht auf jeden Fall richtig aus.
Nun mal die Hälften probieren: obere Hälfte, untere Hälfte, linke Hälfte, rechte Hälfte, aber mit den jeweils 6 Koordinaten.
Also für die obere Hälfte:
topLeftX, topLeftY;
topMidX, topMidY;
topRightX, topRightY;
midLeftX, midLeftY;
midMidX, midMidY;
midRightX, midRightY;
Hängt von der Fehlermeldung ab.
Im Zweifel wird zu viel RAM verbraten.
Die Annahme über die ImageViews kann ich so nicht teilen. Liegen die Bilder denn auch nur in einer einzigen Auflösung bereit? Bist Du sicher, dass die nicht automatisch hochskaliert werden? Wie sieht der Code zum Laden der Images aus?
Hast Du Dich beim GalaxyTab S vertippt, oder braucht das echt fast 8,5GB? 
Davon ausgehend, dass oben links 0,0 ist, sieht das zumindest richtig aus…
Ich würde jetzt einmal nur einzelne Viertel anzeigen, also zuerst topLeftX,topLeftY;topMidX,topMidY;midLeftX,mitLeftY;midMidX,midMidY;
Dann mal gucken, was daraus gemacht wird.
Dann das Viertel topMid->topRight->midMid->midRight und so weiter.
Die Anordnung scheint gemäß Dokumentation (von oben links nach unten rechts) richtig.
Interessant müssten die Werte sein.
Okay, wenn ich mir das Resultat in Verbindung mit der Dokumentation so ansehe, dann sieht das 'richtig' aus…
Zitat von "Canvas.drawBitmapMesh(…)"A more general version of this method is drawVertices().
Zitat von "Canvas.drawVertices(…)"Draw the array of vertices, interpreted as triangles (based on mode).
Du nimmst ein 2D Bild von sagen wir 5,68cm Höhe und 3,20cm Breite.
Jetzt möchtest Du das auf sagen wir 4,75cm Höhe (links), 2,78cm Breite (oben), 5,32cm Höhe (rechts) und 3,02cm Breite (unten) skalieren.
Dein Ansatz macht Folgendes: aus den vier Punktpaaren schnibbelt es sich zwei Rechtecke und skaliert sie entsprechend.
Stumpf gesagt hast Du jetzt ein Dreieck mit spitzem 72° Winkel und einer Schenkellänge von 2,78cm x 5,32cm.
Sowie ein Dreieck mit einem stumpfen 98° Winkel und einer Schenkellänge von 3,02cm x 4,75cm.
Auf diese Dreiecke werden jetzt die ausgeschnittenen Dreiecke projiziert: 3,20 x 5,68 mit 90° auf 2,78 x 5,32 mit 72°; 3,20 x 5,68 mit 90° auf 3,02 x 4,75 mit 98°
Daher hast Du diesen Knick, der bei Linien stark auffallend sichtbar ist. (Andererseits hat eine solche Transformation bei reinen Farben wenig Sinn…)
Die von Dir benutzte Methode teilt Dein Mesh in flächenmäßig ungefähr gleich große Dreiecke und projiziert über jedes Dreieck einen Ausschnitt Deines Ursprungsbildes.
Das ist so eine Art simuliertes 3D, bei dem ja auch einzelne Texturen auf einzelne Dreiecksflächen gepackt werden. Und wie bei 3D gilt: je mehr und dadurch kleiner die Dreiecke, desto besser das Ergebnis.
Du könntest also dem Canvas einfach statt 4 Ecken (oben links, oben rechts, unten links, unten rechts) auch 9 Ecken geben (oben links, oben mitte, oben rechts, mitte links, mitte, mitte rechts, unten links, unten mitte, unten rechts). Du kannst das meinetwegen auch auf 64 Ecken aufblähen. Die Qualität wird immer besser, die Berechnungszeit immer höher.
Eine Alternative wäre natürlich, direkt ein OpenGL View mit einer entsprechend vorbereiteten Szene bereit zu stellen, auf der Du dann jeweils die Textur darstellst.
Fakt ist: einfach mal so lässt sich das nicht umsetzen.
Naja, ohne das Phone drum rum wäre ein bisschen schöner.
Der Knick scheint von oben links (topLeftX/topLeftY) nach unten rechts (bottomRightX/bottomRightY) zu gehen.
Kannst Du das Ganze mal mit einer vernünftigen Dummy-Grafik machen?
Beispielsweise von so einer Art Karopapier.
Erst einmal quadratisch und dann vielleicht noch in einem Rechteck.
Da lassen sich sicherlich bessere Annahmen zur Fehlerursache treffen.