Beiträge von Desperate

Ich habe eine Frage zu meiner doch recht einfachen App, die ich wohl am ehesten in der Rubrik "Konzept" stelle. Meine App soll die Laufstärke des Smartphone-Lautsprechers (global mix) über die gegebene Grenze erhöhen (solche Apps gibts auch dutzendweise im Play Store unter "Volume Booster"). Meine App funktioniert recht gut, aber mein Gefühl sagt mir, dass ich nicht das optimale Konzept dafür gewählt habe und man es viel besser machen könnte. Was ich programmiert habe:

• Meine App besteht nur aus einer einzigen kurzen Activity.

• Diese erstellt bei der Erstausführung nur eine Custom Notification, siehe Bild unten.

• Damit die TV-App, deren Lautstärke ich hin und wieder verstärken will, parallel dazu überhaupt hörbar ist, muss ich meine App am Schluss von onResume mittels moveTaskToBack(true) noch in den Hintergrund bringen.

• Wenn ich jetzt einen Button meiner Custom Notification klicke, rufe ich mit einem Intent mit Flag Intent.FLAG_ACTIVITY_SINGLE_TOP wieder meine einzige Activity auf (die dann entsprechend einem Extra-Wert des Intents die Lautstärke verändert, am Schluss meine Custom Notification gleich wieder upgedatet anzeigt und unverzüglich wieder in den Hintergrund geht). (Anzeige aller Notifications mittels dieses Snippets).

Wie geschrieben, funktioniert meine App recht gut, hat aber zwei Schönheitsfehler:

• Jedesmal, nachdem ich in meiner Custom Notification einen Button klicke, flackern alle Notifications recht stark, wenn ich meine erneut upgedatet anzeige.

• Wenn Android nach langem Nichtgebrauch meine App aus dem Speicher wirft, entgleist meine App selbst bei Neustart: Der obige "Extra"-Wert ist immer so gross, wie er beim letzten Mal vor der Speicherbereinigung war (egal, welchen Button ich klicke). Ich muss tatsächlich das Smartphone herunterfahren und rebooten, erst dann funktioniert wieder alles.

Es muss aber einen Weg ohne diese beiden Nachteile geben, denn z.B. die sehr ähnliche Play-Store-App hier hat all diese Nachteile nicht. Ich habe auch schon einen Foreground-Service ausprobiert, aber darin kann ich keine Custom Notification erstellen, nur standardmässige. Jede Bemerkung von Eurer Seite ist herzlich willkommen...

Hallo Gerrit

Willkommen in der Community.
Tönt interessant, vor allem, dass sie garantiert kein Internet nutzt.

Zitat von Gerrit

ein Tool um eine Tastatur selbst zu entwerfen. So etwas ist meines Wissen noch nicht im Play Store vorhanden.

Kennst du die App "Bright Keyboard" von Philip Heyse? Ich habe mir damit vor 3 Jahren eine Tastatur ganz nach meinen Wünschen zusammenstellen können... Ich erinnere mich allerdings nicht mehr, ob ich Rechte fürs Internet geben musste ... Heute brauche ich diese Tastatur allerdings nicht mehr. Die Killerargumente sind die Rechtschreibekorrektur bzw. Vorschläge der Samsung-Tastatur. Und seit diese auch Doppelbelegung zulässt (z.B. "q" = "+" bei längerem drücken) muss ich auch nicht mehr zur Sonderzeichen-Tastatur wechseln, was damals der Beweggrund für die eigene Tastatur war.

Liebe Community

Ich brauche wieder mal eure Meinung. Ich mache meinem Nickname erneut alle Ehre und jage als Einzelkämpfer seit über 20 Stunden verzweifelt einem seltsamen Effekt hinterher - unterdessen denke ich, dass es ein Bug in Android ist. Aber schöne der Reihe nach: Ich programmiere eine Bildschirmlupe, um einzelne Pixels des Homescreens sichtbar zu machen. Soweit erfolgreich - bis auf ein kleines Detail. Das Fenster der Lupe ist in Breite und Höhe veränderbar, wenn ich nun dessen OBERE oder LINKE Kante jeweils nach INNEN ziehe, ruckelt - vor allem wenn ich schnell ziehe - mein Bild und ändert sogar seinen Massstab, obwohl es genau in das ImageView passt (siehe mein 10-Sekunden-Video hier; für die anderen sechs Kombinationen von Kanten und Ziehrichtungen funktioniert mein Code jedoch perfekt, was schon mal seltsam ist, denn mein Code unterscheidet Ziehrichtungen nicht). Der einzig zuständige Code (für festen Vergrösserungsfaktor 10 und für den Fall im Video) lautet:

Rect rect = new Rect(xOffset,yOffset - windowHeightSrc,xOffset + windowWidthSrc, yOffset);
    bitmapSrc = Bitmap.createBitmap(windowWidthSrc, windowHeightSrc, Bitmap.Config.ARGB_8888);
    PixelCopy.request(
        surface,
        rect,
        bitmapSrc,
        new PixelCopy.OnPixelCopyFinishedListener() {
          @Override public void onPixelCopyFinished(int resultCode) {
            imageViewMagnification.setImageBitmap(Bitmap.createScaledBitmap(bitmapSrc, 10*windowWidthSrc, 10*windowHeightSrc,false));
          }
        },
        new Handler()
    );

Auf der Suche nach der Ursache kam ich auf die Idee, bitmapSrc durch ein festes geladenes Bild pic auszutauschen (zusätzliche Zeile 9):

Rect rect = new Rect(xOffset,yOffset - windowHeightSrc,xOffset + windowWidthSrc, yOffset);
    bitmapSrc = Bitmap.createBitmap(windowWidthSrc, windowHeightSrc, Bitmap.Config.ARGB_8888);
    PixelCopy.request(
        surface,
        rect,
        bitmapSrc,
        new PixelCopy.OnPixelCopyFinishedListener() {
          @Override public void onPixelCopyFinished(int resultCode) {
            bitmapSrc = Bitmap.createBitmap(pic, 0, pic.getHeight() - windowHeightSrc, windowWidthSrc, windowHeightSrc);
            imageViewMagnification.setImageBitmap(Bitmap.createScaledBitmap(bitmapSrc, 10*windowWidthSrc, 10*windowHeightSrc,false));
          }
        },
        new Handler()
    );

Das ändert (ausser dem Bild natürlich) gar nichts, siehe Video hier. ABER: Wenn ich Zeilen 9 und 10, die ja vom Befehl PixelCopy.request() unabhängig sind, vor diesen Befehl ziehe, funktioniert überraschenderweise alles bestens (siehe mein drittes Video hier

Rect rect = new Rect(xOffset,yOffset - windowHeightSrc,xOffset + windowWidthSrc, yOffset);
    bitmapSrc = Bitmap.createBitmap(windowWidthSrc, windowHeightSrc, Bitmap.Config.ARGB_8888);
    bitmapSrc = Bitmap.createBitmap(pic, 0, pic.getHeight() - windowHeightSrc, windowWidthSrc, windowHeightSrc);
    imageViewMagnification.setImageBitmap(Bitmap.createScaledBitmap(bitmapSrc, 10*windowWidthSrc, 10*windowHeightSrc,false));
    PixelCopy.request(
        surface,
        rect,
        bitmapSrc,
        new PixelCopy.OnPixelCopyFinishedListener() {
          @Override public void onPixelCopyFinished(int resultCode) {
          }
        },
        new Handler()
    );

Das beweist meiner Meinung nach, dass mein übriger Code (der nichts mehr am Bild ändert) korrekt ist und der Fehler nicht dort liegen kann, dass aber PixelCopy.request() einen unerwarteten Einfluss auf imageViewMagnification.setImageBitmap() hat, obschon das nicht sein sollte. Mein Fragen:

1) Übersehe ich da was Fundamentales, oder ist der Unterschied von Version 2 und 3 nicht ein Android-Bug?
2) Wie könnte man den Fehler noch mehr eingrenzen?
3) Mit welchen Wordarounds kann ich meine App doch noch perfektionieren?

Jede Rückmeldung und Idee ist hochwillkommen ...

Hallo Profis

In meiner App kann der Benutzer die Fenstergrösse einer ImageView auf dem Bildschirm per Drag einer der vier Ränder selber verstellen. Das in der View gezeigte Bild soll dabei an Ort bleiben und nur an der entsprechenden Kante zu- oder abgedeckt werden. Beispiel: Die View misst original 100x100 Pixel. Der Benutzer zieht den linken Rand 10 Pixel nach innen. Das ursprünglich angezeigte Bild muss also ebenfalls am linken Rand um 10 Pixel abgeschnitten werden und kann jetzt wieder in der 90x100 View platzfüllend dargestellt werden. Meine App macht in diesem Beispiel direkt hintereinander folgendes:

1. Platzieren der auf 90x100 verkleinerten View mit einem 10px grösseren marginLeft.
2. Laden des neuen zugeschnittenen 90x100px-Bildes in die ImageView.

Leider kommt mir Android dabei in die Quere, denn es zeichnet sofort nach Schritt 1 das alte 100x100-Bild nochmals (bei scaleTyp CENTER auf 90x90 verkleinert, damit es in der durch Schritt 1 verkleinerten View Platz hat, um dann im Schritt 2 wieder auf 90x100 aufgeblasen zu werden; bei scaleTyp MATRIX um 10 Pixel nach rechts verschoben, um dann nach dem Schritt 2 wieder um 10 Pixel nach links zu springen; usw.). Dadurch zittert das Bild in der ImageView ganz gehörig (vor allem, wenn der Bildrand kontinuierlich verschoben und obiger Prozess entsprechend wiederholt wird).

Ich suche Ideen, wie ich dieses örtliche Zittern (zu unterscheiden von einem zeitlichen Flackern) verhindern kann. In .NET kann man z.B. als Workaround den Bildschirm-Update für die Dauer der Schritte 1 und 2 disabeln - ist das auch in Android möglich? Oder hilft ein eigenes ImageView, bei der OnDraw in dieser Situation unterdrückt wird? Oder gibts bessere/kürzere Lösungen?

Danke für jeden Tipp!

... und mein eingangs gestelltes Problem ist doch lösbar! Habe einen Workaround gefunden, der zumindest bei mir perfekt läuft. Für all diejenigen, die auf das gleiche Problem gestossen sind:

mMap.setOnMarkerDragListener(new GoogleMap.OnMarkerDragListener() {
  @Override public void onMarkerDragStart(Marker marker) {
    // Setze den HotSpot des Icons mit dem zweiten Parameter 40% der Iconhöhe UNTERHALB des Icons:
    marker.setAnchor(0.5f, 1.4f);
    VisibleRegion vR = mMap.getProjection().getVisibleRegion();
    View v = findViewById(R.id.map);
    offset = 80*(vR.latLngBounds.northeast.latitude - vR.latLngBounds.southwest.latitude)/v.getLayoutParams().height;
    // Ersetze nun bis Zeile 14 alle 'marker.getPosition()' durch 
    // 'new LatLng(marker.getPosition().latitude + offset, marker.getPosition().longitude)'.
    // Hier folgt allfälliger eigener Code
  }
  @Override public void onMarkerDrag(Marker marker) {
    // Eigener Code
  }
  @Override public void onMarkerDragEnd(Marker marker) {
    // Eigener Code
  }
});

Die Konstante 80 in Zeile 7 hängt von der Grösse des benutzten Icons, dessen HotSpot (und evtl auch vom Gerät bzw. dessen Auflösung) ab, aber nicht vom Ort oder Zoomfaktor. Da ich nur ein einziges Smartphone habe und meine App nur auf diesem laufen muss, habe ich eine allfällige Geräteabhängigkeit nicht weiter untersucht.

Hoffe, das hilft jemandem.

Hallo jogimuc

Habe nicht mehr mit einem Beitrag gerechnet und erst jetzt zufällig deine Frage entdeckt (leider wird man nicht - wie bei anderen Foren - mit einem Mail informiert, wenn ein neuer Beitrag eintrifft. Oder hab ich da eine Einstellung übersehen?). Nun, du musst den Marker nur draggable machen (Zeile 6):

Erzeugen eines Markers an der Stelle, wo man mit dem Finger auf die Karte tippt

mMap.setOnMapClickListener(new GoogleMap.OnMapClickListener() {
  @Override public void onMapClick(LatLng latLng) {
    marker = map.addMarker(new MarkerOptions()
        .title("Testmarker")
        .position(latLng)
        .draggable(true)
    );
  }
};

Dann lässt sich der Marker verschieben und springt beim lange Antippen nach oben. Um dann damit etwas Sinnvolles zu machen, verwendest du die folgenden Methoden, vor allem wohl die letzte:

mMap.setOnMarkerDragListener(new GoogleMap.OnMarkerDragListener() {
  @Override public void onMarkerDragStart(Marker marker) {
    //TODO
  }
  @Override public void onMarkerDrag(Marker marker) {
    //TODO
  }
  @Override public void onMarkerDragEnd(Marker marker) {
    //TODO
  }
});

Solltest du das austesten, würde mich echt interessieren, wie gross bei dir beim Bewegen der Abstand zwischen deinem oberen Fingerrand (Fingernagel) und der Spitze des Markers ist (und welches Smartphone du dazu benutzt). Im Video ist bei unbekanntem Handy der Abstand etwa 2mm, bei meinem Galaxy S9 ist der Abstand aber wie schon geschrieben cirka -1mm (d.h. den untersten entscheidenden Millimeter des Icons seh ich nicht), und beim Fragesteller aus Posting #6 ist der Abstand offensichtlich auch negativ. Hängt natürlich auch von der Dicke der eigenen Finger ab, aber ich behaupte jetzt mal, dass ich eher normale bis schlanke Hände habe.

Hoffe, das hilft.

Ich habe die Antwort auf meine Frage gefunden: Das Problem ist nicht lösbar. Siehe hier.

EDIT: Falsch, siehe Posting #10!

Hallo jogimuc

Dein (mir bis jetzt unbekannter) Hinweis, dass man mittels runOnUiThread doch von einem Nebenthread einen Toast auf den Homescreen ausgeben kann, war der Schlüssel zum Erfolg. Ich konnte die ganze zeitintensive Rechnerei in den Nebenthread auslagern, vor dessen Ausführung aber auch meinen Toast loswerden und nach der Rechnerei allfällige Fehler-Toasts - alles wie gewünscht. Danke ein weiteres Mal für deinen unschätzbaren Input.

Und danke auch an alle, die sich mit dem Problem befasst haben, auch wenn sie keine oder keine "billigere" Lösung wussten.

Zitat von jogimuc

Klar wird der Punkt unter deinem Finger gesetzt. Ist ja der Punkt wo du auch hinzeigst.

Sorry, da muss ich gegensprechen, dem ist nicht so. Wenn du dir das 40-Sekunden-Video im Posting #1 anschaust, siehst du ganz klar, dass der Finger beim Verschieben nicht der HotSpot ist (beim Erzeugen des Markers schon). Im Video springt das Icon beim Verschieben auch genügend hoch, so dass sich Finger und Icon nicht in die Quere kommen. Bei meinem Galaxy S9 sind es allerdings nur 4 mm (vielleicht sind es eine konstante Anzahl Pixels, und bei meiner hohen Auflösung deshalb nur 4mm). Drum immer noch die Frage: Kann man diese Sprunglänge ändern - falls ja, wie?

Hallo yogimuc

Hab deinen Vorschlag mit einem Thread t1 für die zeitintensive Rechnung realisiert, funktioniert aber auch nicht. Der Toast im Hauptthread findet während des Wartens des Hauptthreads auf das Ende des Nebenthreads t1 statt (genauso wie in Posting #1), und da der Homescreen ja erst am Ende updatet, sieht man das nicht mehr. Wenn ich in deinem Code die obere Grenze für i verkleinere, sehe ich tatsächlich noch die letzten Zehntelssekunden des Toasts.

Ganz abgesehen davon scheint mir, dass da mit Kanonen auf Spatzen geschossen werden. Gibt es tatsächlich keine (einfache) Lösung für das sicher nicht seltene Problem, einen User zu informieren, dass das Smartphone nicht abgestürzt, sondern am Rechnen ist, wenn es die nächsten paar Sekunden nicht reagiert?

Hallo Jogimuc

Danke für den Tipp. Das wäre Neuland für mich, und ich weiss nicht, ob Threads das Problem auch lösen würde. Drum noch ein paar Details: Der Toast ist eigentlich nur eine Bestätigung, dass man die zeitintensive Berechnung tatsächlich ausgelöst hat (Mitteilung "Bin jetzt am Rechnen..."). Wenn der Toast erst zusammen mit dem Rechenresultat angezeigt wird, ist er absolut sinnlos. Leider braucht es auch das Resultat, um im Programm weiterzufahren, d.h. der Main Thread müsste auf das Ende des Nebenthreads warten. Könnte man stattdessen nicht den Toast in den Nebenthread auslagern? Dann könnten beide Threads gleichzeitig (genau genommen im Time Sharing) ausgeführt werden? Kann dieser Toast aber im Hauptthread angezeigt werden (Context = ?) ?

Hallo jogimuc

Leider keine Lösung, der Marker verschiebt sich ungeachtet des Zoomfaktors stets 4mm nach oben. Der HotPoint (Spitze des auf dem Kopf stehenden Tropfens) landet so immer unter meinem Fingernagel - nicht gerade dienlich, um ihn präzise zu platzieren...

Guten Tag

In GoogleMap kann man Marker (auf dem Kopf stehende "Wassertropfen") nach einem LongClick per Drag&Drop verschieben (siehe z.B. das kurze Demovideo zuunterst auf dieser Website). Wenn ich auf den Marker lange tippe, springt das Icon des Markers nach einer Sekunde ca. 4mm nach oben, damit man den HotPoint des Markers (Spitze des Wassertropfens) sieht. Ich habe wohl dickere Finger als die Android-Entwickler, für mich wäre ein doppelt so weiter Sprung von 8mm optimal. Trotz 3h Recherche im Internet habe ich keine Antwort gefunden, ob und wie man die Sprungdistanz verstellen könnte. Weiss jemand eine Lösung?

Danke schon jetzt.

Hallo Profis

Wie ich ausgetestet habe, wird bei folgendem (Pseudo-)Code der Toast gar nicht angezeigt:

... onCreate ... {
    Toast
    10-sekündige Rechenaufgabe
}

Offensichtlich updatet Android den Bildschirm erst NACH dem vollständigen Abarbeiten der rechenintensiven dritten Zeile, und bis dann ist der Toast vorbei. Wie kann man den Toast doch anzeigen lassen? Gibt es (wie z.B. in VisualBasic Dot-Net mit DoEvents) einen Befehl, der die Ausführung einer Methode unterbricht und alle anstehenden Aktualisierungen des Homescreens vornimmt? Oder muss ein eigener Thread gestartet werden? Was ist der billigste Weg zum Ziel?

Danke für jeden Tipp.

Hallo liebe Forum-Mitglieder

Wenn ich das kurze Lernprojekt über Menüs von hier eins zu eins nachbaue, erhalte ich nicht wie dort im Bild zuunterst gezeigt vier Schaltflächen mit Icons zuunterst im Screen, sondern in der Action Bar zuoberst rechts ein mit drei Punkten angezeigtes ausklappbares Menü. Offensichtlich hängt die Darstellung von den APIs ab. Da ich nur drei Optionen und vertikal genügend Platz habe, ziehe ich die alte Lösung (so wie auf der obigen Website) vor. Android Studio erlaubt aber keine targetSdkVersion unter 26. Kann man mit nicht zu grossem Aufwand die alte Darstellung erreichen?

Danke für eure Meinungen.

Problem hat sich erledigt. Ich habe den südkoreanischen Entwickler von "Dateimanager +" angeschrieben, er hat mir innert 2 Stunden seine App so ausgebaut, dass ich damit mit dem gleichen Code wie für den "ES Datei Explorer" Ordner per Code öffnen kann. Wow, das ist Service...

Hallo

3 Jahre lang benutzte ich den mächtigen "ES Datei Explorer", bis er mir jetzt zu viele Bugs bekommen hat (z.B. 5 GB eigene Daten, auch nach Neuinstallation). Dank "ES Datei Explorer" konnte ich mir aber bis anhin per Code den Inhalt eines beliebigen Ordners direkt anzeigen lassen:

Uri uri = Uri.fromFile(new File("storage/emulated/0/.../"));
        Intent intent = new Intent(Intent.ACTION_VIEW);
        intent.setDataAndType(uri, "resource/folder");
        intent.setClassName("com.estrongs.android.pop.pro", "com.estrongs.android.pop.view.FileExplorerActivity");
        startActivity(intent);

Für meinen neuen Explorer ("Dateimanager +" von "Flashlight + Clock") funktioniert der entsprechende obige Code nicht mehr (der Dateimanager zeigt nur die Gesamtübersicht), obwohl die App auch direkte Verknüpfungen zum Ordnerinhalt auf dem Homescreen erzeugen kann. Wenn ich diese Verknüpfungen antippe, registriert das Logcat die Befehle

START u0 {act=com.alphainventor.filemanager.OPEN_SHORTCUT typ=null flg=0x10000000 cmp=ComponentInfo{com.alphainventor.filemanager/com.alphainventor.filemanager.activity.ShortcutActivity}}
START u0 {act=com.alphainventor.filemanager.OPEN_FILE typ=null flg=0x34000000 cmp=ComponentInfo{com.alphainventor.filemanager/com.alphainventor.filemanager.activity.MainActivity}}

Kann man mit dieser Information nicht einen Android-Code zusammenbasteln, der das Gleiche macht - nämlich direkt den Ordnerinhalt im Dateimanager anzuzeigen?

Danke fürs Mitdenken.

Hallo Grafikprofis

Ich möchte ein Bild ohne jegliche Interpolation "pixelig" vergrössern, so wie das Photoshop & Co. (natürlich nur in der Anzeige) beim Reinzoomen mit dem Bild machen, um die einzelnen Pixel zu sehen. In Android gibt's dafür den Befehl Bitmap.createScaledBitmap(bmpSource, 1000, 1000, false), der dank dem Parameter "false" in der Theorie genau mein Problem lösen sollte, in der Praxis aber ein Gemisch von Interpolation und pixeliger Vergrösserung macht. Für eine Vergrösserung ohne Anti-Aliasing braucht es den Interpolationsmodus "Nearest neighbor" (und nicht "bilinear" o.ä. wie bei Bitmap.createScaledBitmap). In VB.NET hab ich diesen Modus einst selber in einem Programm verwendet, von Java les' ich von dieser Möglichkeit vage im Internet, aber kann man das auch in Android bewerkstelligen? Wurde trotz 2 Stunden googlen nicht fündig ...

Danke für jeden Tipp

Good news von der Front: Ersetzt man das zweite Programmstück in Posting #3 durch den folgenden Code, so wird die erzeugte APK nicht nur so getauft wie das Projekt, sondern auch noch gleich auf den Desktop meines Win-PCs kopiert:

debug {
            android.applicationVariants.all { variant ->
                variant.outputs.all {output ->
                    outputFileName = new File(parent.name + ".apk")
                    def taskSuffix = variant.name.capitalize()
                    def assembleTaskName = "assemble$taskSuffix"
                    if (tasks.findByName(assembleTaskName)) {
                        def copyAPKFolderTask = tasks.create(name: "archive$taskSuffix", type: org.gradle.api.tasks.Copy) {
                            from "$buildDir/outputs/apk/debug/"
                            into "C:/Users/.../Desktop/"
                            include parent.name + ".apk"
                        }
                        tasks[assembleTaskName].finalizedBy = [copyAPKFolderTask]
                    }
                }
            }
        }

Ich hab auch versucht, die APK direkt auf das angeschlossene Android-Gerät abzuspeichern, bin hier aber definitiv gescheitert. Ist was für euch Profis ...

Damit wäre Punkt 1. aus dem Startposting mehr oder weniger erledigt.

Zu 2&3: Danke jogimuc für die Bemerkung. Ja, das könnte man tatsächlich machen. Das Problem ist, dass ich das nicht immer so will, sondern nur bei Apps, die mehrzeilige TextViews haben, denn dort erzeugt API 28 im Falle von Sonderzeichen unregelmässige Zeilenabstände.

Gibts denn nirgends greifbar die Vorlagen für style.xml und build.gradle??? Muss man denn fast die Software hacken, um das Template dieser beiden Files zu verändern?

Hello again Michael

Du scheinst allwissend zu sein ... Danke wiederum für den Tipp. Der verlinkte Artikel war so kurz, dass ich mich erst schlau machen musste, und funktionierte dann nicht. Aber auch hier hat mir dein Tipp nach einer weiteren Stunde Internet-Recherche das Tor geöffnet (siehe unten). Schade ist nur, dass man die nötige Ergänzung bei jedem Projekt von neuem machen muss und die Ergänzung nicht in ein Template von build.gradle aufnehmen kann. Oder gibt's letzteres doch?

Jetzt bin ich aber auf den Geschmack gekommen und möchte die (korrekt benannte) APK auch direkt auf mein PC-Desktop abspeichern. Gradle kann zwar Files speichern, aber absolute Pfade sind verboten. Mit dem Vorschalten von "/.." vor dem Namen komme ich zwar bis zur Root "D:\" meiner Partition, aber leider nicht auf "C:\" für mein persönliches Desktop. Wenn also hier jemand einen Workaround kennt, ist er herzlich willkokmmen ...

Nun aber für alle Anfänger wie mich, die auf der Suche nach einer Lösung von 1) sind, eine (hoffentlich) verständlichere Anleitung. Sie bezieht sich auf das aktuelle Android 3.3 und Gradle 4.10.1, die aufgeführte Syntax scheint nämlich häufig zu ändern, wie die vielen nicht funktionierenden Lösungen im Internet beweisen ...

1. Nach der Erzeugung eines neuen Projekts die Datei "build.gradle (Module:app)" links oben im Projektverzeichnis, das auf "Android" einzustellen ist, doppelklicken.
2. In der Mitte der Datei findet man die Zeilen

buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }

Füge VOR der letzten Klammer "}" noch folgenden Code ein, und die APK heisst ab jetzt wie das Projekt :

debug {
            android.applicationVariants.all { variant ->
                variant.outputs.all {
                    outputFileName = parent.name + ".apk"
                }
            }
        }

Das war's. Frage 1b), 2) und 3) sind immer noch offen...