Beiträge von Xcreen

    Hallo Daniel,


    grundsätzlich ist das möglich. Du kannst einfach eine App bauen mit einen Button der den Whatsapp-Anruf macht.
    Diese App kannst du dann als Launcher setzten und ist somit immer der "Startbildschirm".
    Eingehende Anrufe/Whatsapp-Anrufe und die Benachrichtigungsleiste funktionieren weiterhin.


    Die Lösung in deinem Stackoverflow Link funktioniert leider nicht, aber hier habe ich was gefunden das dir hilft:
    https://stackoverflow.com/a/46049004/10759732
    Zum Launcher setzen musst du nur in der AndroidManifest.xml den Intent-Filter in der Activity anpassen:

    XML
    <intent-filter>
                    <action android:name="android.intent.action.MAIN" />
                    <category android:name="android.intent.category.HOME" />
                    <category android:name="android.intent.category.DEFAULT" />
                </intent-filter>

    Hallo,


    fürs Entwickeln und Testen bleibt die Oracle JDK kostenfrei.
    Der Produktiv-Einsatz wird pro User bzw. pro CPU bei Servern bezahlt. Die Preise können dort sehr variieren.
    Unter Android muss man sich aktuell keine Sorgen mehr machen, dort wurde schon alles auf OpenJDK umgestellt.
    Für den Desktop gibt es verschiedene JDK Anbieter. Du kannst direkt OpenJDK nutzen (macht wahrscheinlich am meisten Sinn). Es gibt auch eine entsprechende Seite mit Installern (https://adoptopenjdk.net/installation.html)
    Alternativ bietet auch Amazon JDKs an.


    Ich persönlich nutze erstmal OpenJDK.

    Die Anzahl der Threads die gleichzeitig laufen ist erstmal irrelevant.
    Du kannst auch 100 Threads haben, wenn diese nichts machen oder nur leichte Aufgaben machen, mindern die nicht unbedingt deine Leistung.
    Aber du kannst auch 2 Threads haben, und du kannst damit die ganze Performance runterziehen, wenn diese halt komplexere Aufgaben machen.
    Interessant ist halt, was in den Thread genau vorgeht.

    Genau wie jogimuc schon sagt, brauchst du eine Dialer-App.
    Allerdings ist das keine Anfänger-Aufgabe, das kann schon ziemlich komplex werden.
    Vielleicht solltest du mal mit einer einfachen App starten, um dafür ein Gefühl zu entwickerln. (z.B. Eine App die Kontakte ausliest und lokal in eine Datenbank speichert und das ganze in einer ListView ausgibt.)

    Also das Gerät kann man ja wahrscheinlich ausschließen, wenn es auf mehreren so ist.
    Das Layout und die Daten sind ja anscheinend auch nicht komplex.
    Hört sich also so an, als würde was anderes Performance ziehen.


    Eventuell hängt es mit den Threads zusammen, aber das ist natürlich jetzt alles schwer zu sagen ohne Source-Code.

    Ich würde einfach mal Tippen, dass das LG G4 ROM einfach restriktiver mit solchen System-Einstellungen umgeht, als die Standard-Android Versionen.


    Ja bei Android hast du natürlich extrem viele Kombinationen aus Hardware und Software, welche das testen im Gegensatz z.B. unter iOS schwerer macht.
    Deswegen würde ich auch vor dem Veröffentlichen der App, soviele Kombinationen testen die gehen und auch Crashlytics in die App einbauen.
    Damit siehst du später ob noch Crashes auftauchen und kannst sie dann entsprechend beheben.


    Von Anti-Viren Software unter Android halte ich sowieso nichts. Die können ohnen Root-Rechte nämlich garnicht wirklich was scannen oder auslesen und entsprechend was finden.

    Zitat

    Erst wenn in einem Einstellungsdialog explizit lokales speichern aktiviert ist werden Daten persistent mittels shared preferences hinterlassen und bei Bedarf auch wieder entfernt.

    Mich würde interessieren, welchen Grund das hat?
    Du brauchst ja für Shared-Prefernces keine extra Berechtigungen und gewissen Komponenten (z.B. der Webview) schreiben, sowieso schon direkt in dein App-Verzeichnis. Das Verzeichnis wird bei der Installation sowieso erstellt und existiert damit. Eventuell wird es auch sowieso schon benutzt (auch wenn du meinst, das dort nichts hinterlassen werden soll).

    Hi,
    dafür gibt es natürlich mehrere Ansätze.
    Eigentlich kannst du im onBackPressed das entsprechende Intent senden.

    Java
    @Override
    public void onBackPressed() {
        Intent intent = new Intent();
        intent.putExtra("data", data);
        setResult(resultcode, intent);
        super.onBackPressed();
    }


    Eine relative leichte Variante ist, das du die benötigen Daten in den Shared-Preferences speicherst und ausliest. Damit ist man relative flexible, auch wenn man über mehrere Activitys hinweg an Daten ran kommen musst.

    Dafür braucht man eine Backend-Lösung. Am besten kann man da einen Web-Server betreiben und dann dort eine Rest-API bereitstellen. Die Daten werden dann in einer Datenbank gespeichert.
    Bei der Auswahl des Servers/Sprache und der Software bist du natürlich mega flexibel.


    Mögliche Server könnten z.B. sein Apache,Ngnix,Tomcat,.Net
    Mögliche Sprachen: PHP,Java,asp.Net etc.
    Mögliche Datenbanken: MySQL, PostgreSQL, MongoDB


    Die Software hängt natürlich von der Sprache ab.
    Als PHP-Framework für Rest-APIs kann ich Codeigniter/Slim/Symfony empfehlen.
    Für Java gibt es z.B. Lucee/Spring/JavaEE.


    Je nachdem wie du das ganze baust und wie deine Vorkenntnisse sind, fallen auch die Kosten aus.
    Am günstigen ist man meisten bei einem einfach PHP-Web mit Apache und MySQL. Dies ist eine Standard-Konfiguration die man bei fast allen Server-Anbietern günstig bekommt.

    Hi,
    also in meiner Demo-App (auf dem S8) wurde der BluetoothProfile.ServiceListener direkt nach dem Start ausgeführt und ich habe dann entsprechend den Button-Text gesetzt.


    Java
    //Set Button Text
                    if ((Boolean) isTetheringOn.invoke(instance, null)) {
                        toggleBTButton.setText("Turn off");
                    } else {
                        toggleBTButton.setText("Turn on");
                    }

    Das sollte doch eigentlich bei dir dann auch so funktionieren?

    Timeouts können an zwei Stellen passieren.
    1. Der Client wartet nicht lange genug auf dem Server
    2. Der Server braucht zu lange und beendet den Request


    So wie es hier aussieht, trifft Fall 1 zu.
    Der String vom der Bitmap ist natürlich um ein vielfache größer als "adwhsdbshdbhasbdj".
    Entsprechender länger braucht der Request zum Versenden, da mehr Daten übertragen werden müssen. (Zudem dauert eventuell für den Fall auch die Server-Verarbeitung länger?)
    Wahrscheinlich solltest du dein Request Timeout erhöhen.


    Beispiel für OkHttp (ich weiß jetzt nicht ob du die Library nutzt):


    Java
    client = new OkHttpClient.Builder()
            .connectTimeout(10, TimeUnit.SECONDS)
            .writeTimeout(30, TimeUnit.SECONDS)
            .readTimeout(30, TimeUnit.SECONDS)
            .build();

    Damit hättest du ein 30 Sekunden Versand und Empfang Timeout, das sollte bei einer guten Internetverbindung locker reichen.

    Ich habe gerade mal geschaut. Der BluetoothProfile.ServiceListener wird bei mir am Start einmal ausgeführt und danach reagiert er nur auf Bluetooth (an/aus) Änderungen.
    Er reagiert nicht auf Bluetooth Tethering (an/aus) Änderungen.
    Also solltest du den Listener nicht dafür verwenden Tethering-Änderungen mit zu bekommen. Ab du könnest einen Thread/Service erstellen und dort via isTetheringOn überprüfen, ob es an oder aus ist.

    Hi,


    wahrscheinlich hast du ein String/Post Limit auf der Server-Seite. Kenne mich mit JSF jetzt nicht aus, aber vielleicht kann man dort oder im Tomcat? noch etwas einstellen.
    Alternativ, da du auf beiden Seiten Java hast, kannst du das Byte-Array auch direkt verschicken (das ist deutlich kleiner als ein String). Wie gesagt kennen ich mich mit JSF nicht aus, aber das sollte möglich sein.


    Allerdings halte ich es nicht für klug Bilder in die Datenbank zu speichern, da diese die Datenbank extrem groß machen (viel Spaß bei späteren Imports/Exports). Zudem wird die Datenbank Performance enorm leiden.
    Besser wäre es die Datei auf einen File-Server(S3,Ceph,oder einfach Festplatte) zu speichern und in der Datenbank nur ein Verweis hinzuzufügen.

    Versuch doch nochmal google() und maven hinzuzufügen. Vielleicht hilft das.
    Sollte dann so aussehen:

    Hi,
    sorry für die späte Antwort, hatte am Wochenende einiges zu tun...
    Ich habe die SDK-Version selbst auf 28 und keine Probleme.


    Die Klasse android.bluetooth.BluetootPan exisitert fest im Android-System und muss deswegen nicht hinzugefügt werden.
    Da dies aber keine offizelle API Lösung ist, kann ich dir nicht genau sagen und welchen Android-Versionen es läuft.
    Soweit ich das gesehen hatte, sollte es aber eigentlich fast überall gehen.


    Hier meine Demo-App, die kannst du ja mal vergleichen. https://drive.google.com/open?…zD8gzB3tGjHxRzOqefaMfwBin