Schlauchserie - Android

[Quentin]

mal dumm gefragt. Habe jetzt mal eine Beispiel-App für Android erstellt. Hat ja auch fein geklappt. Wie bekomme ich das Teil aufs Handy? Bin dabei leider völlig unbewandert.

[Kitty Hello]

Handy anstecken, Compilieren. Suchen. GLBasic installiert das beim Erstellen automatisch im 2. Schritt.

[Quentin]

Was? So einfach?
Super!
Probier ich dann beim nächsten Mal. Komme jetzt aber wohl erst man ne Woche nicht dazu.

[backslider]

Es kann also auch zum Problem werden, dass GLBasic "zu einfach" ist.

[Quentin]

lol, ja kann es wohl. Wie zu beweisen war.

Aber wo ich schon mal bei dummen Fragen bin:
Bei Updates wird der alte Stand dann auch überschrieben?
Und wo genau wird die Anwendung abgelegt?

ok, vielleicht sollte ich mit dem Teil erst mal ein wenig vertraut werden, bevor man beginnt, Programme dafür zu schreiben ...

[backslider]

Also die Anwendung sollte ja eigentlich im "App"-Ordner sein, da wo auch alle anderen Apps sind.
Und bis man mit Android vertraut ist, gibts schon ne neue Version.

[Quentin]

Weiter gehts mit "Auf dem Schlauch stehen"

Ganz so einfach ist es dann doch nicht. Hab den ganzen Kram jetzt auch auf meinem Lappi installiert. Der erste Build-Lauf ist erfolgreich, beim zweiten bekomme ich folgende Meldungen:

BUILD STAGE 2: Install on device
     [echo] Creating output directories if needed...
     [echo] Compiling aidl files into Java classes...
     [echo] Compiling RenderScript files into Java classes and RenderScript bytecode...
     [echo] Generating R.java / Manifest.java from the resources...
     [echo] Converting compiled files and external libraries into D:\dev\Projects\GLBasic\GLAndroid\distribute\Android\bin\classes.dex...
     [echo] Packaging resources
     [echo] Running zip align on final apk...
     [echo] Debug Package: D:\dev\Projects\GLBasic\GLAndroid\distribute\Android\bin\glbasic-debug.apk
     [echo] Installing D:\dev\Projects\GLBasic\GLAndroid\distribute\Android\bin\glbasic-debug.apk onto default emulator or device...

BUILD FAILED
D:\dev\GLBasic\Compiler\platform\android\android-sdk-windows\tools\ant\main_rules.xml:641: The following error occurred while executing this line:
D:\dev\GLBasic\Compiler\platform\android\android-sdk-windows\tools\ant\main_rules.xml:271: exec returned: 1

[Kitty Hello]

hast ein Android Gerät eingesteckt und die Treiber für Windows installiert? Am Gerät USB-Debuggen aktiviert?

[Quentin]

ja, HTC ist per USB angeschlossen. Die Treiber werden ja beim ersten Mail automatisch installiert. Kann das Gerät ja auch z.B. als externe Festplatte ansprechen.

USB-Debugging war noch nicht eingeschaltet. Habe ich jetzt nachgeholt. Die Fehlermeldung bleibt jedoch die Gleiche.

[Quentin]

UPDATE!
Goil! Jetzt gehts. Musste noch HTCSync installieren. Jetzt klappts! *froi*

dann gleich die nächste Frage:
In den Projekt-Optionen haben ich als Auflösung 800 x 480 eingestellt. Mit GETSCREENSIZE im Programm erhalte ich jedoch die Werte 533 x 320 ? Verwendung von SETSCREEN ändert daran auch nichts.

[Kitty Hello]

Das verstehe ich auch oft nicht. Was sagt "GETDESKTOPSIZE"?

[Quentin]

GETDESKTOPSIZE leifert die gleichen Werte zurück.
Zumindest stehe ich mit diesem Problemchen nicht alleine da. Damit schlagen sich wohl viele rum.

Eine mögliche Erklärung? findet sich auf

http://developer.android.com/guide/practices/screens_support.html

Auto-scaling of pixel dimensions and coordinates

An application can disable pre-scaling by setting android:anyDensity to "false" in the manifest or programmatically for a Bitmap by setting inScaled to "false". In this case, the system auto-scales any absolute pixel coordinates and pixel dimension values at draw time. It does this to ensure that pixel-defined screen elements are still displayed at approximately the same physical size as they would be at the baseline screen density (mdpi). The system handles this scaling transparently to the application and reports the scaled pixel dimensions to the application, rather than physical pixel dimensions.

For instance, suppose a device has a WVGA high-density screen, which is 480x800 and about the same size as a traditional HVGA screen, but it's running an application that has disabled pre-scaling. In this case, the system will "lie" to the application when it queries for screen dimensions, and report 320x533 (the approximate mdpi translation for the screen density). Then, when the application does drawing operations, such as invalidating the rectangle from (10,10) to (100, 100), the system transforms the coordinates by scaling them the appropriate amount, and actually invalidate the region (15,15) to (150, 150). This discrepancy may cause unexpected behavior if your application directly manipulates the scaled bitmap, but this is considered a reasonable trade-off to keep the performance of applications as good as possible. If you encounter this situation, read the following section about Converting dp units to pixel units.

Usually, you should not disable pre-scaling. The best way to support multiple screens is to follow the basic techniques described above in How to Support Multiple Screens.

in AndroidManifest.xml sehe ich auch folgende Zeile:

Code: (glbasic) [Select]

<supports-screens android:resizeable="false"
Sollte resizeable nicht auf true stehen, um die Anpassung an unterschiedliche Auflösung zu ermöglichen?

[UPDATE]
Geht! Man muss allerdings "resizeable" UND "anyDensity" auf true stellen. Dann bekommt man wohl die höchstmögliche Auflösung. Kann es leider nicht auf schwächeren Geräten testen.

Code: (glbasic) [Select]

<supports-screens android:resizeable="true"
  android:smallScreens="true"
  android:normalScreens="true"
  android:largeScreens="true"
  android:anyDensity="true" />

[Kitty Hello]

Probier's einfach mal aus was besser ist. Und dann macht mich schlau

[Quentin]

*schlaumach*

siehe oben

[Kitty Hello]

Teste mit diesen Einstellungen mal ein Programm das mit 320x480 gemacht würde. Was macht er dann?