App crash auf Tablet aber nicht auf Smartphone

Hallo,

ich bin dabei eine App zu entwickeln. Auf meinem Galaxy S4 funktioniert sie ohne probleme. Aber auf meinem Galaxy Tab 10.1N stürzt die app ab sobald ich ein ImageView drücke.

<code> 05-22 09:07:20.900: E/AndroidRuntime(26699): FATAL EXCEPTION: main
05-22 09:07:20.900: E/AndroidRuntime(26699): java.lang.IllegalStateException: Could not execute method of the activity
05-22 09:07:20.900: E/AndroidRuntime(26699): at android.view.View$1.onClick(View.java:3098)
05-22 09:07:20.900: E/AndroidRuntime(26699): at android.view.View.performClick(View.java:3620)
05-22 09:07:20.900: E/AndroidRuntime(26699): at android.view.View$PerformClick.run(View.java:14322)
05-22 09:07:20.900: E/AndroidRuntime(26699): at android.os.Handler.handleCallback(Handler.java:605)
05-22 09:07:20.900: E/AndroidRuntime(26699): at android.os.Handler.dispatchMessage(Handler.java:92)
05-22 09:07:20.900: E/AndroidRuntime(26699): at android.os.Looper.loop(Looper.java:137)
05-22 09:07:20.900: E/AndroidRuntime(26699): at android.app.ActivityThread.main(ActivityThread.java:4507)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.lang.reflect.Method.invokeNative(Native Method)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.lang.reflect.Method.invoke(Method.java:511)
05-22 09:07:20.900: E/AndroidRuntime(26699): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:978)
05-22 09:07:20.900: E/AndroidRuntime(26699): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:745)
05-22 09:07:20.900: E/AndroidRuntime(26699): at dalvik.system.NativeStart.main(Native Method)
05-22 09:07:20.900: E/AndroidRuntime(26699): Caused by: java.lang.reflect.InvocationTargetException
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.lang.reflect.Method.invokeNative(Native Method)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.lang.reflect.Method.invoke(Method.java:511)
05-22 09:07:20.900: E/AndroidRuntime(26699): at android.view.View$1.onClick(View.java:3093)
05-22 09:07:20.900: E/AndroidRuntime(26699): ... 11 more
05-22 09:07:20.900: E/AndroidRuntime(26699): Caused by: java.lang.StackOverflowError
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.util.HashMap.get(HashMap.java:298)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectStreamClass.getReflectionField(ObjectStreamClass.java:190)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeFieldValues(ObjectOutputStream.java:953)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:368)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeHierarchy(ObjectOutputStream.java:1074)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeNewObject(ObjectOutputStream.java:1404)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeObjectInternal(ObjectOutputStream.java:1671)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1517)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1481)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.util.ArrayList.writeObject(ArrayList.java:644)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.lang.reflect.Method.invokeNative(Native Method)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.lang.reflect.Method.invoke(Method.java:511)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeHierarchy(ObjectOutputStream.java:1053)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeNewObject(ObjectOutputStream.java:1404)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeObjectInternal(ObjectOutputStream.java:1671)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1517)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1481)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeFieldValues(ObjectOutputStream.java:979)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:368)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeHierarchy(ObjectOutputStream.java:1074)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeNewObject(ObjectOutputStream.java:1404)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeObjectInternal(ObjectOutputStream.java:1671)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1517)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1481)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeFieldValues(ObjectOutputStream.java:979)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:368)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeHierarchy(ObjectOutputStream.java:1074)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeNewObject(ObjectOutputStream.java:1404)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeObjectInternal(ObjectOutputStream.java:1671)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1517)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1481)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeFieldValues(ObjectOutputStream.java:979)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:368)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeHierarchy(ObjectOutputStream.java:1074)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeNewObject(ObjectOutputStream.java:1404)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeObjectInternal(ObjectOutputStream.java:1671)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1517)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:1481)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeFieldValues(ObjectOutputStream.java:979)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:368)
05-22 09:07:20.900: E/AndroidRuntime(26699): at java.io.ObjectOutputStream.writeHierarchy(ObjectO
</code>

Weiß jemand woran das liegt?

Gruß

Und was genau meinst du damit?

Fabian Simon

Also Stackoverflow:
Dazu sollte man wissen das ein Ram in 2 Bereiche aufgeteilt ist:
Der größere heißt Heap(Haufen).
Und der kleiner Stack (Stapel).

Wenn nun ein komplexes Object im Ram erzeugt wird, wird dies im Heap abgespeichert.
Desweiteren wird im Stack eine Refernzid zur ensprechenden Stelle im Heap abgelegt.
Nun hat der Stack (je nach Ram größe) nur eine gewissen Anzahl an Variabeln die er gleichzeitig Speichern kann.
Werden es zu viele, kommt der Stackoverflow excption.
Somit liegt es warscheinlich weniger an Smartphone bzw Tablet sondern eher wieviel Ram deiner Anwendung zur Verfügung steht.

Folgendes solltest du beachten:
statisch gespeicherte Variabeln werden die Komplette Laufzeit im Ram vorgehalten.
Globale Variabeln werden nur solange vorbehalten wie eine Klasse referenziert wird.
methoden Variabeln leben nur solange wie die Mehtode im Abarbeitungsstatus ist.
der GC (Garbige Collector) räumt das ganze auf.

Somit solltest du deinen Code bzg. benötigter Variabeln, nochmal überarbeiten.

Nachtrag:
Wenn du grad dabei bist Object aus einen Stream zu laden / zu speichern, schau dir die Methode Flush an .

Gruß
Fabian

Vielen dank für diese Hinweise, ich werde mal google und mir das genauer anschauen.

Georg C.

Versuche es auch so:
Ohh my god,

aus der log ist zu entnehmen: -> Caused by: java.lang.StackOverflowError
StackOwerflowError wird ausgeworfen (bedeutet) wenn der Stack "überläuft". Weil ich nicht vermute das ..... -> vermute ich eine Rekursion.
(wie der Pascal es auch schon angedeutet hat!)
Oft wird StackOwerflowError generiert, wenn eine Methode rekursiv aufgerufen wird und irgendwas mit Parametern nicht stimmt oder keine Endbedienung existiert.
Was das bedeutet?:
Ein Paradenbeispiel:

protected void onCreate(Bundle savedInstanceState) {
...
mache_wasMethode(...);
...

public void mache_wasMethode(int x, String str_z) {

mache_wasMethode(...);

}

in der onCreate Method wird eine mache_wasMethode(...) aufgerufen.
In der mache_wasMethode(...) wird die selbe Methode aufgerufen.
Weil in oberen Beispiel jedoch keine weitere "Sachen" implementiert sind,
wird einfach die StackOverflowError Extension ausgeworfen mit dem Fatalen Abbruch der JVM (?Dalvick)

Du musst einfach in deinem Code nach vergleichbare "Code- Konstellation" suchen. Es muss nicht unbedingt in der onCreate Methode sein!
(Wenn Du jetzt denkst; - Rekursion ist was schlimmes - NO! Ohne dieses werde z.B. ein Verzeichnisinhalt unmöglich darzustellen - durchsuchen .... )

LG
Georg

Das klingt ja ähnlich wie eine Endlosschleife. Da ich aber sowas nicht in meinem quelltext habe kann es ja daran nicht liegen oder?

Martin

Hab schon einmal gefragt - benutzt du verschiedene Layouts?

Nein es ist das selbe layout.

Edit:

Mittels debugger hab ich jetzt herausgefunden das es immer auftritt wenn startactivity(intent); aufgerufen wird.
Ich hab meine app jetzt sofern es mir möglich war verbessert z.b. weniger listen und variablen. Sie arbeitet gefühlt auch besser aber frisst dennoch ganz schön viel RAM. Fängt mit 30MB an und steigert sich bei benutzung bis 120MB.

— geändert am 24.05.2014, 22:02:09

Martin

Poste mal das Fragment vom Aufruf dann ist es vermutlich einfacher dir zu helfen - was mich wundert ist, dass es am S4 läuft und am Tablet nicht obwohl beide Geräte ähnlich gute Hardware haben

...deshalb auch meine Vermutung, dass irgendetwas mit dem Layout nicht stimmt - oder greifst du eventuell auf eine Telefonfunktion zu, die beim Tablet nicht vorhanden ist?

hier das fragment:

<ScrollView xmlns:android="schemas.android.com/apk/res/android"
    xmlns:tools="schemas.android.com/tools"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:paddingBottom="@dimen/activity_vertical_margin"
    android:paddingLeft="@dimen/activity_horizontal_margin"
    android:paddingRight="@dimen/activity_horizontal_margin"
    android:paddingTop="@dimen/activity_vertical_margin"
    android:background="#293c4b" >

    <LinearLayout
        android:id="@+id/ll"
        android:layout_width="fill_parent"
        android:layout_height="wrap_content"
        android:orientation="vertical" >

    </LinearLayout>

</ScrollView>

Das Fragment ist so leer weil ich die TextViews aus Designgründen mit Code hinzufüge. Es wird dann insgesamt eine Liste angezeigt mit X Items, je nachdem wie groß die ArrayList ist. Ein onClick Event gibt es für jedes Item. 90% der Items kann ich anklicken und ein neues View öffnet sich mit Infos zu dem Item. Allerdings bei den anderen 10% stürzt die App mit dem Stackoverflowerror ab. Unabhängig davon ob ich zuerst funktionierende Items öffne oder zuerst ein abstürzendes Item öffnen möchte. Unterschiede zwischen den Items sind nur minimal. z.B. anderer R.string oder anderes R.drawable.

Und wie schon erwähnt, auf meinem Galaxy S4 klappt alles ohne Probleme. Beide Geräte haben genug RAM. Ich habe die App gestern noch mehrere male versucht umzuschreiben und eine Lösung zu finden z.B. den Gebrauch von static zu vermeiden, Globale variablen verringert, alles in allem mehr dynamisch gemacht mit Vererbung.

Ein anderen Gedankengang den ich hatte war das ich zu viele TextViews habe, was aber auch nicht sein kann weil diese erst mit der Laufzeit beim Anzeigen des Items erzeugt werden.

Es ist mir auch nicht bekannt warum genau diese bestimmten Items abstürzen, wie oben schon angemerkt haben die nur andere R.string und R.drawable, und auf meinem Smartphone läuft es ja. Aber es sind immer die selben Items.

— geändert am 25.05.2014, 12:31:03

Nick Reitemeyer

Schau dir mal ListViews an. Ich hab gehört, dass die nicht so viel RAM brauchen.

Schön das du das gehört hast, aber ich kann mich schlecht darauf verlassen wenn du es nur gehört hast.

Fabian Simon

Dann zeig uns bitte mal den Code wo du den Icon einen OnClickListener hinzufügst.

    private void ShowList(ArrayList<ItemProperties> al) {

    for (final ItemProperties o : al) {
        //Itemproperties hat informationen wie name und picture
        MyTextView mtv; //MyTextView(context,string,picture,pictureposition,picturesize,textunderline,paddingtop)
        LinearLayout ll = (LinearLayout) findViewById(R.id.ll);
        mtv = new MyTextView(this, getString(o.getName()), o.getPicture(), "left", 3, false, 0);
        mtv.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                    Intent intent = new Intent(ListActivity.this, ItemView.class);
                    Bundle b = new Bundle();
                    b.putSerializable("key", o);
                    intent.putExtras(b);
                    startActivity(intent);
            }
        });
        ll.addView(mtv);


    }

}

Ich würde nur ungern auf ListView umsteigen da ich bisher immer Probleme mit denen hatte. Außerdem benutze ich TextViews welche auf der Linken seite ein Bild zu dem Item anzeigen. Ob ich nun eine ListView mit einem neuen layout befülle welches ein Textview mit einem Bild hat oder ein LinearLayout in einem ScrollView habe welche ich mit Textviews befülle kann ja eigentlich kann doch eigentlich kein großer unterschied sein?

Das mit dem OnClickListener nicht in der schleife hat leider nicht geklappt. Bekomme immer noch den Stackoverfloweror.

— geändert am 27.05.2014, 11:22:11

Fabian Simon

Du hast diese Frage noch nicht beantwortet:
befindet sich die Methode in der Klasse ltemview? Vermutlich nicht oder?
Ich glaube auch das du ein rekurionsproblem hast.
Allerdings ein sehr verstecktest....
Ich vermute, das du mit dem Intent aufruf die Klassen immer und immer wieder aufrufst. halt wie bei einer Rekusion.
Dies würde zutreffen wenn der Stackoverflow nur dann käme, wenn du schon ein paar elemente angeklickt hattest.
so nach dem motto bis zum xten TextView gehts und dann kommt bei element y das exception

Nein die Methode liegt nicht in der ItemView Klasse, sondern in der ListActivity wie man es im Intent erkennen kann.
Intent intent = new Intent(ListActivity.this, ItemView.class);

ItemView klasse bekommt nur das Bundle. Naklar rufe ich für jedes Item die selbe Klasse(activity) auf. Warum sollte ich auch für jedes meiner Objeckte eine eigene Activity machen.

Das mit der idee "bis zum xten textview gehts und dann kommt bei element y das exception" klingt ja einerseits nach einer guten Idee. Andererseits kann ich alle Items öffnen nur bestimme Items funktionieren nicht.

Beispiel: Stell dir eine List mit 10 Items vor. Alle funktionieren tadellos bis auf Item Nummer 6.
Fall 1: Ich öffne Item 1-5 mit einem klick und schließe sie mit dem backbutton. Kein Problem. Nun klicke ich nummer 6. Zack Stackoverflow.
Fall 2: Ich öffne Item 7-10mit einem klick und schließe sie mit dem backbutton. Kein problem. Nun klicke ich nummer 6. Zack Stackoverflow.
Fall 3: Ich versuche nummer 6 zu öffnen. Zack Stackoverflow.

Alle 10 Items sind identisch bis auf den R.string für den namen und R.drawable für das Bild.

Fabian Simon

So langsam wo du den Ganzen Code Zeigen müsstest eine Idee Hab ich aber noch:

und zwar glaub ich das Problem ist entweder in Zeile b.putSerializable("key", o); oder in der Klasse ltemview.
Wenn du dir den Stacktrace anschaust.
Schreibt er oft was ObjectStreams ....
und genau solche werden bei einer Serializierung verwendet um das Obejct zu serializieren.
Wo ist "o" definiert ? bzw. Was ist "o"??

o ist ein Object der Klasse ItemProperties welche Informationen hat wie z.B. Name und ein bild. o ist nirgendswo definiert da es nur die lokale variable für die java foreach schleife ist.

Beispielcode: al repräsentiert eine ArrayList<ItemProperties>

for(ItemProperties o : al){
     //Code here
}

Der fehler könnte in der ItemView liegen da ich dort ein Item anzeige und manche dieser Items bestehen aus Items desselben Typs.

Beispiel für Item 1:

Name: Item 1
Bild: Denk dir hier das Bild
Bestandteil von: Item2

Item2 ist in diesen fall anklickbar welches Item2 anzeigt. Also aus der ItemView heraus wird eine ItemView angezeigt. Das nennt man doch Recursion richtig? Und wenn diese zu Tief wird ist der Stack irgendwann voll und es gibt ein StackoverflowException? Oder hab ich da was falsch verstanden?

Jetzt mal angenommen das es an der Recursion liegt, warum stürzt es dann auf dem Tablet ab und auf dem Galaxy S4 nicht? Meiner recherche nach ist die Stack größe unter android 4.x.x gleichgroß, also müsste es doch auf meinem S4 auch abstürzen.

Martin

Andreas-George

Jetzt mal angenommen das es an der Recursion liegt, warum stürzt es dann auf dem Tablet ab und auf dem Galaxy S4 nicht? Meiner recherche nach ist die Stack größe unter android 4.x.x gleichgroß, also müsste es doch auf meinem S4 auch abstürzen.

...genau aus dem Grund glaub ich immer noch, dass du irgendeine API verwendest, welche vom Tablet nicht unterstützt wird - hast du keine anderen Geräte zum Testen?
...ich hätte ein Tablet mit Mobilfunk und eines ohne - wenn du mir die .apk schickst könnt ich ausprobieren ob es eventuell daran liegt

Das projekt hat API 10 (2.3.3) bis API 19 (4.4.2). Das Tablet nimmt sich doch dann die passende API. Es hat Android 4.4.4 also API 15?

APK kann ich dir schicken. Link hab ich dir per PN geschickt.

Ludy

wie sieht die class MyTextView denn aus?

public class MyTextView extends TextView {

    public MyTextView(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);
        // TODO Auto-generated constructor stub
    }

    public MyTextView(Context context, AttributeSet attrs) {
        super(context, attrs);
        // TODO Auto-generated constructor stub
    }

    public MyTextView(Context context, String text, int icon, String position, int iconsize, boolean underline, int paddingtop) {
        super(context);
        setTextSize(20);
        setTextColor(Color.WHITE);
        setGravity(Gravity.CENTER_VERTICAL);
        setPadding(0, paddingtop, 0, 0);
        if (underline) {
            SpannableString content = new SpannableString(text);
            content.setSpan(new UnderlineSpan(), 0, content.length(), 0);
            setText(content);
        } else {
            setText(text);
        }

        if (icon != 0) {
            Drawable image = getResources().getDrawable(icon);
            image.setBounds(0, 0, getLineHeight() * iconsize, getLineHeight() * iconsize);

            if (position.equals("left&quot) {

                setCompoundDrawables(image, null, null, null);
                setCompoundDrawablePadding(20);

            } else if (position.equals("top&quot) {

                setCompoundDrawables(null, image, null, null);
                setCompoundDrawablePadding(20);

            } else if (position.equals("right&quot) {

                setCompoundDrawables(null, null, image, null);


            } else if (position.equals("bottom&quot) {

                setCompoundDrawables(null, null, null, image);
                setCompoundDrawablePadding(20);

            }

        }
    }

}

— geändert am 27.05.2014, 19:39:43

Martin

Hab die App jetzt auf Xperia Z, Nexus 5, Note 10.1 2014 und Asus Transformer Pad getestet und hab nirgens Probleme gehabt

Hmm echt komisch...dann muss es irgendwie am Tablet liegen. Vll ist da irgendwas in der Software fehlerhaft weil es schon so alt ist.

Naja danke trozdem an alle für die Hilfe!

— geändert am 28.05.2014, 16:51:38