Recents Taste sperren

  • Hallo



    Ich programmiere OpenSource.



    Ich will dass die Recents Taste entweder nicht mehr angezeigt wird oder besser dass sie gar nicht mehr funktioniert. Bei der App </acronym>Surelock oder Sitekiosk funktioniert das auf unterschiedliche Art. Das muss auch ohne rooten gehen.



    Im Internet gibt es verschiedene Ansätze. Aber entweder sie
    funktionieren nur manchmal oder gar nicht. Und der eine Ansatz, der
    manchmal funktioniert funktioniert mit einer Methodik die doof ist, weil
    das Recents-Menü für eine Sekunde doch noch angezeigt wird.


    http://www.juliencavandoli.com/how-t...s-home-button/
    http://stackoverflow.com/questions/1...nt-apps-button



    Die App </acronym>Surelock zeigt beim clicken auf die Recents Taste folgendes an:


    Surelock blocked: com.android.systemui


    com.android.systemui.recent.RecentsAcitivity



    Kann man irgendwie programmfremde Activities sperren?


    EDIT:
    Also mit Keyevents geht das nicht. Für jede andere Taste würde das gehen, aber bei der Recents Taste geht das nicht.
    Kann man nicht irgendwie Appfremde Activities vorm plötzlichen starten blocken, also damit auch dieses Recentsmenü?


    Oder Prozesse blocken?


    Gibts da auch Kernelhooks, die feuern, wenn ein Prozess oder eine Activity gestartet wurde?


    Oder hat jemand zumindest Ideen, wie man das lösen könnte?

  • Diese 'Recents' Taste ist auf einigen Geräten eine Hardwaretaste, das 'nicht mehr anzeigen' wird also bestenfalls schwierig. ;)


    Doch davon völlig unberührt: es gibt keinen Grund in die Funktionalität der Hardware eingreifen zu wollen.
    Noch weniger gibt es einen Grund dafür das Verlassen der App über die 'Recent Apps' Taste unterbinden zu wollen.


    Ein Kiosk-Modus ist und bleibt Sache des Betriebssystems. Da Android das offenbar nicht anbietet und es mit Bordmitteln offenbar nicht möglich ist, gibt es das auch nicht.


    Mir fällt als einzige Möglichkeit nur ein, dass Du Deine Manifest-Datei anpasst. Gemäß Surelock fangen sie 'einfach' das Intent com.android.systemui.recent.RecentsAcitivity
    ab.


    Eventuell kannst Du Deine Activity im Manifest so konfigurieren, dass diese beim Aufrufen von com.android.systemui.recent.RecentsAcitivity gestartet wird.


    Nur noch einmal zum Betonen meines Standpunktes: Finger weg von der Usability. Diese Funktionalität hat ihre Gründe und mir fällt absolut kein Punkt ein, die eine Deaktivierung rechtfertigen würde.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • Es gibt einen Grund in die Funktionalität einzugreifen, wenn man einen Kiosk Modus programmieren möchte, insbesondere dann wenn das die Aufgabe meiner Informatik Masterarbeit ist, die mir ein Professor gegeben hat. Außerdem gibt es mehrere solcher Apps die einen Kioskmodus umsetzen und die sind nicht von der Firma, die das Betriebssystem programmiert haben. Das gilt für Adroid, aber auch für Windows etc. Ein Kiosk Mode war noch nie die Aufgabe des Betriebssystems, lediglich die Bereitstellung der Betriebssystemfunktionen.


    Zitat

    Mir fällt als einzige Möglichkeit nur ein, dass Du Deine Manifest-Datei
    anpasst. Gemäß Surelock fangen sie 'einfach' das Intent
    com.android.systemui.recent.RecentsAcitivity
    ab.

    Wie geht das? Ich dachte in Manifestdateien kann ich nur etwas über meine App eintragen und nicht über das System.



    Wenn mit Tablets Klassenarbeiten geschrieben werden sollen, dann dürfen die Schüler nicht abgucken können. Dafür braucht man einen Kiosk Modus. Auch Geldautomaten etc. brauchen einen Kiosk-Modus und der kommt nicht von Microsoft.

  • Ich habe mal den Android Quellcode gelesen und herausgefunden, dass ab
    Android 4.2 bis 4.4 und vielleicht auch demnächst danach die
    Recentsactivity existiert und ein Intent empfangen kann, das die
    Recentsansicht deaktiviert oder so. Vor 4.2 existiert zwar ein Package
    recent oder recents oder so mit Klassen drin, aber ne Activity habe ich
    da nicht drin gesehen. Frage mich wie das damals ohne Activity überhaupt
    ging. Naja egal.




    Problem ist damit noch nicht ganz gelöst, aber ich bin jetzt zumindest auf einer heißen Spur!

  • So jetzt muss ich com.android.systemui.recent.RecentsActivity


    importen, aber da meckert eclipse ... nach vielen Minuten googlen bin ich darauf gekommen:


    A way to import system files into Eclipse without errors (Android)? : Android Community - For Application Development




    Zitat

    Otherwise, you will have to fix each and every dependency
    yourself, by hand, for those dependencies that can indeed be
    fixed.

    Also mit anderen Worten, ich soll das nicht machen, und
    wenn ichs mache, dann müsste ich alle irgendwelche Abhängigkeiten
    behandeln.




    So aber ich denke mir, dass die eine Kiosk App Surelock das doch auch
    konnte. Ich solls zwar nicht tun, aber verdammt der hätte trotzdem mal
    erklären können wie es trotzdem gehen würde, auch wenn mans nicht tun
    soll. Mir bleibt keine andere Wahl!

  • Schön, dass Eclipse meckert. Eigentlich solltest Du wissen, dass man ohne genauere Angaben absolut nicht helfen kann.
    Zumindest bei mir scheint java.lang.occultism.CrystalBall gesprungen zu sein und java.lang.spiritualism.Ouija ist irgendwie auch nicht sehr auskunftsfreudig. :P


    Ich weiß nur, dass man Intents blocken kann. Eventuell wird diese Activity ja über einen Intent aufgerufen, der eben diese Signatur der Activity hat. Dann könntest Du Deine Activity für diesen Intent registrieren und eventuell wird die RecentApps Activity dann nicht aufgerufen, sondern Deine App erneut.

    SureLock ist ein plattformübergreifendes Mobile Device Managementsystem für Android, iOS und Windows/Windows Mobile.
    Das Ding kostet nicht aus Spaß $50 pro Lizenz. Da stecken Hirnschmalz und jahrelange Arbeit hinter. Vermutlich haben Sie im Windows Mobile/Windows CE Bereich angefangen, da diese Systeme hauptsächlich im Bereich Lager und Logistik eingesetzt wird und der 'Kiosk Modus' dort aus Sicht der Chefetage eine Existenzberechtigung hat.
    (Mit auf den Workflow zugeschnittener Hard- und Software bräuchten die das nicht – aber es ist ja cooler Tausende von Euro für ein breit verbreitetes allgemeines Betriebssystem auszugeben und weitere Tausende von Euro für eine Software, die das System beschneidet, als ein paar Tausend Euro für ein angepasstes Betriebssystem zu bezahlen.)


    Wenn Du es also wissen willst, wie die das machen, dann könntest Du ja da einfach mal nachfragen.
    Wenn es einfach wäre, gäbe es Hinweise auf StackOverflow. Beispielsweise wie beim Home-Button. Welcher sich seit 4.0 aber auch nicht mehr so abfangen lässt…


    Nach wie vor behaupte ich: niemand braucht einen Kiosk Mode.


    Ein Kiosk Mode versteckt Betriebssystemfunktionalität vor den Anwendern. Ein Kiosk Mode funktioniert so lange gut, bis das Admin Kennwort herausgefunden wurde. Und meine Erfahrungen mit Kiosk Modes sind, dass es immer mindestens einen Weg gibt dran vorbei zu kommen und sie immer mindestens eine Betriebssystemfunktionalität ungewollt beeinträchtigen.


    Wenn ein Gerät (beispielsweise ein Tablet für die schriftliche Prüfung – was an und für sich schon ein absurder Gedanke ist!) also nur eine Sache können soll, dann soll es gefälligst auch ein nur auf diese eine Sache speziell ausgerichtetes Gerät sein.
    Statt also zu versuchen irgendwie die normalen Eingabemethoden zu verhindern
    und die Eingabemethoden über eine Bluetooth Tastatur
    und die Eingabemethoden über ein Bluetooth Headset
    und die Eingaben über die Sprachsteuerung
    ist ein Custom ROM mit auf das Einsatzgebiet des Tablets zugeschnittenen Programmen die richtige Lösung.


    Keine Recent Apps? Dann ruft das Custom ROM eben keine Activity auf. Keine Browserunterstützung, um Googlen während der Prüfung zu unterbinden? Dann hat das Custom ROM eben keinen Browser. Ein Store fällt ebenfalls aus, weil die Schüler und Studenten sicherlich keine Apps installieren dürfen.


    Oder, anders ausgedrückt:
    Lieber einen Porsche kaufen, höher legen lassen, größere Reifen drauf, Getriebe statt auf Geschwindigkeit mehr auf Drehmoment anpassen, Unterboden angemessen versiegeln und eine Anhängerkupplung dran anstatt gleich einen Trecker zu kaufen.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

  • Hier ist ja ein Lösungsansatz:


    android intercept recent apps button - Stack Overflow




    Das funktioniert
    auch, aber leider nicht immer, sondern nur meistens oder machmal.


    Und außerdem ist das nicht akzeptabel, dass das Recentsmenü angezeigt wird.




    Hier ist der Code der Recentsactivity von Android:


    GC: RecentsActivity - com.android.systemui.recent.RecentsActivity (.java) - GrepCode Class Source




    Da gibt es nicht nur wie in dem Codebeispiel hier das:


    Code
    String TOGGLE_RECENTS_INTENT = "com.android.systemui.recent.action.TOGGLE_RECENTS";

    sondern auch das:


    Code
    String CLOSE_RECENTS_INTENT = 
    "com.android.systemui.recent.action.CLOSE";

    Und ich glaube
    letzteres ist das was ich suche.




    In dem Codebeispiel hier steht:


    Code
    Intent closeRecents = new Intent("com.android.systemui.recent.action.TOGGLE_RECENTS");

    daraus habe ich einfach mal


    Code
    Intent closeRecents = new Intent("com.android.systemui.recent.action.CLOSE");

    aber das hat dazu geführt, dass es gar nicht mehr ging.




    Hat jemand einen Rat?

  • Und ich glaube
    letzteres ist das was ich suche.


    Wie kommst Du auf die Idee, dass Du die Stelle suchst, an der die Recents geschlossen werden sollen? Du kennst die Implementierung des Ganzen nicht. Wenn es zu früh geschieht und die RecentsActivity noch gar nicht vollständig angezeigt wird, wer garantiert Dir dann, dass alles stehen und liegen gelassen und die RecentsActivity geschlossen wird?


    Eventuell brauchst Du eher die com.android.systemui.recent.action.PRELOAD um einzugreifen, bevor der Kram angezeigt werden soll.
    Und wenn Du dort 'nur' ein com.android.systemui.recent.action.CANCEL_PRELOAD schickst.
    Doch wird auch das nur passieren, wenn das PRELOAD überhaupt ausgeführt wurde, weshalb Du versuchen müsstest, Deine App für dieses Intent zu registrieren.


    Allerdings ist es im Allgemeinen so, dass Android Dir eine Auswahl der Apps anbietet, die das gewählte Intent verarbeiten können. Und da kann der User dann wieder raus aus Deiner App.


    Würde dieses Buch mir weiterhelfen?


    Vermutlich nicht. Dort steht nur, wie Du Deine Apps mit Intents verschönern und anpassen kannst. Du willst in die Funktionen des Betriebssystems eingreifen.
    (Und ich habe Dir schon mehrfach erklärt, dass das einerseits eine blöde Idee und andererseits schwer umzusetzen ist.)


    Entweder weitest Du Deine Recherche aus in dem Du Unternehmen fragst, die das hinbekommen haben, oder Du baust Dir ein eigenes angepasstes ROM.
    Du kannst es auch mit einem Java Disassembler etwas Reverse-Engineering versuchen.


    Nur wenn dieses Problem so trivial zu lösen wäre, dass eine halbe Stunde Google Dir Erleuchtung brächte, wäre so eine Masterarbeit ja geschenkt. Und damit noch weniger wert als eine abgeschriebene Doktorarbeit.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Daraus folgt: je mehr Käse, desto weniger Käse.


    »Dies ist ein Forum. Schreibt Eure Fragen in das Forum, nicht per PN!«

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!