Content from 2012-08

Apps für Android 4 fit machen

posted on

Im Play-Store gibt es einige Apps zur Vorbereitung auf Funk- und Sportbootführerscheine von mir. Um eine möglichst große Zahl von Nutzern zu erreichen, habe ich die Anwendungen kompatibel zu Android 2.1 entwickelt. – Für mich hieß das, dass ich bei der Erstellung für die Anwendungen das API-Level 7 als „Project Build Target“ benutzt habe.

Ergebnis dieser Vorgehensweise ist, dass auch Telefone mit einer neueren Version von Android die Anwendung in einer Art „Kompatibilitätsmodus“ ausführen. In diesem Modus wird die ganze Oberfläche möglichst genau so gezeichnet wie es unter der alten Version der Fall war. Dies soll sicherstellen, dass auch eine Anwendung, die sich z.B. genau darauf verlässt wie groß ein Button zu sein hat auch Buttons in genau dieser Größe vorfindet.

Schauen wir uns das ganze zuerst in Bildern an:

Android-2.1-kompatibler Modus von Jelly Beans (Android 4.1)

Originäre Darstellung auf Jelly Beans (Android 4.1, Telefon mit Hardwaretasten)

Die Unterschiede hier sind:

Die notwendigen Änderungen damit neuere Android-Versionen nicht in den Kompatibilitätsmodus schalten sind minimal und benötigen keine einzige Änderung am Programmcode. Lediglich ein paar Änderungen in den XMLs der Anwendung sind notwendig.

AndroidManifest.xml

Die wichtigste Änderung, die vorzunehmen ist, befindet sich in der Datei AndroidManifest.xml:

<?xml version="1.0" encoding="utf-8"?>

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="eu.wimmerinformatik.sbfs"
    android:installLocation="auto"
    android:versionCode="5"
    android:versionName="1.4" >

    <uses-sdk android:minSdkVersion="7" android:targetSdkVersion="16" />

    <application
        android:icon="@drawable/ic_launcher_sbfs"
        android:label="@string/app_name" >
        <activity
            android:name=".SBFSTrainerActivity"
            android:label="@string/app_name" >

            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>

        <activity
            android:name="eu.wimmerinformatik.sbfs.QuestionAsker"></activity>

        <activity
            android:name=".StatisticsActivity"></activity>
    </application>
</manifest>

Die hier wichtige Änderung ist das android:targetSdkVersion="16". Diese Angabe bedeutet, dass die Anwendung bis SDK Release 16 (= Android 4.1) getestet ist und keine Kompatibilitätseinstellungen für ältere Android-Versionen benutzt werden müssen. Diese Änderung sorgt dafür, dass Android ab Version 3.0 das Holo-Theme für die Darstellung der Anwendung nutzt. D.h. die neuen Widgets werden benutzt und das App-Icon erscheint in der Action-Bar, die überhaupt erst hiermit aktiviert wird.

Menü-XML-Dateien

Eine weitere Änderung ist in den XML-Dateien, die die Menüs der Anwendung definieren notwendig:

<?xml version="1.0" encoding="utf-8"?>

<menu
    xmlns:android="http://schemas.android.com/apk/res/android" >

    <item
        android:id="@+id/statistics"
        android:visible="true"
        android:title="@string/menuStatistics"
        android:enabled="true"
        android:showAsAction="ifRoom"
        android:icon="@drawable/ic_statistics"></item>

    <item
        android:id="@+id/resetTopic"
        android:title="@string/menuResetTopic"
        android:titleCondensed="@string/menuResetTopicCondensed"
        android:visible="true"
        android:enabled="true"
        android:showAsAction="never"></item>

</menu>

Neu hier eingefügt sind die Attribute android:showAsAction. Mit diesem Attribut und dem Wert „ifRoom“ habe ich festgelegt, dass ich den Menüeintrag für die Statistik gerne direkt in der ActionBar sehen würde (wenn Platz dafür ist). Mit dem Wert „never“ lege ich fest, dass der Menüeintrag zwar fit für neuere Android-Versionen ist, aber nicht direkt in der ActionBar angezeigt werden soll.

Eclipse-Einstellung

Zuletzt muss noch Eclipse gesagt werden, dass es die neuen Einträge in den XML-Dateien auch akzeptiert. Hierzu werden im Kontextmenü des Projektes die Properties ausgewählt. Auf dem Tab „Android“ wird als „Project Build Target“ „Android 4.1“ ausgewählt.

Die App wird damit jetzt mit dem SDK für Jelly Beans übersetzt, das die neuen Einträge im XML kennt und verarbeiten kann. Da in der AndroidManifest.xml als minSdkVersion die 7 angegeben ist, entsteht jedoch eine APK-Datei, die auch von älteren Android-Versionen akzeptiert wird.

Achtung, diese Einstellung bewirkt, dass der Compiler einen nicht mehr aufhält, wenn man Klassen nutzt, die nicht auf allen Android-Versionen, die man unterstützen möchte vorhanden sind. Der Programmierer ist jetzt selbst dafür verantwortlich sicherzustellen, dass die App unter allen als kompatibel markierten Android-Versionen auch wirklich auffähig ist. Das heißt: es wird noch viel wichtiger, dass man die App vor der Veröffentlichung gut testet und diese Tests unter verschiedenen Android-Versionen auszuführen.

Kompatibilität von 8192-Bit-Zertifikaten

posted on

Aufgrund der Tatsache, dass die Hardware mit denen Public-Key-Schlüssel angegriffen werden kann immer leistungsfähiger wird, ist es notwendig, dass auch die Größe der eingesetzten Schlüssel immer weiter vergrößert wird.

Für den Einsatz mit qualifizierten digitalen Signaturen in Deutschland veröffentlicht beispielsweise die Bundesnetzagentur jährlich den sogenannten Algorithmenkatalog. In ihm steht jeweils welche Mindestschlüssellänge bis zu welchem Zeitpunkt als ausreichend angesehen werden kann.

Aktuell wird für den Einsatz von RSA-Schlüsseln bis Ende 2018 beispielsweise empfohlen, dass diese mindestens 2048 Bit lang sein sollten.

Dies betrifft aber natürlich nicht nur qualifizierte Signaturen sondern beispielsweise auch die verschlüsselte Übertragung von Webseiten mit dem HTTPS-Protokoll. Auch hierfür werden meistens RSA-Schlüssel eingesetzt. Üblicherweise trifft man auf Webservern dabei meistens Schlüssel der empfohlenen Länge an. (Ergebnis einer nicht repräsentativen Überprüfung einiger Websites durch mich.)

Natürlich kann man aber auch längere Schlüssel erzeugen und genau das habe ich gemacht bevor ich mir mein letztes Zertifikat habe ausstellen lassen. Der zugehörige RSA-Schlüssel ist 8192 Bit lang. Sicher eine an sich zur Zeit noch übertriebene Schlüssellänge, aber ein interessanter Key um damit zu testen ob alle Browser mit Keys dieser länge umgehen können.

ChromeFirefoxInternet Explorer 9Opera 12Safari 6
Linux (Debian wheezy)OKOK-OK-
Mac OS X (10.8)Meldung „Ungültiges Serverzertifikat“. Fehler kann nicht ignoriert werden.OK-OKLaden der Seite hängt, keine Fehlermeldung
Windows 7OKOKOKOK- (Safari 5: OK)

Wer sicherstellen möchte, dass seine Seite problemlos von allen Nutzern angeschaut werden kann, sollte zur Zeit also noch keine 8192-Bit-Schlüssel einsetzen, da er ansonsten einen Großteil von Mac-OS-X-Nutzern ausschließt.


Fehlermeldung von Chrome unter Mac OS X 10.8.1

TODO: Es interessiert mich noch, wie es mit älteren Versionen von Windows aussieht. Ich habe es noch nicht getestet, aber es könnte sein, dass es unter Windows XP anders aussieht als unter Windows 7.


Unless otherwise credited all material Creative Commons License by Matthias Wimmer