Android App : J'ai défoncé un smartphone

a marqué ce sujet comme résolu.
Auteur du sujet

Salut !

Je suis développeur Web et Android. J’ai implémenté tout à fait normalement une technologie récente de Google dans l’app Android que je suis en train de concevoir. En gros il s’agit de télécharger un gros modèle de deep-learning, et de l’appliquer sur une image pas trop grande que l’utilisateur fournit (laquelle est découpée en nombreuses sous-images pour pouvoir appliquer le modèle sur chacun de ces chunks).

J’avais testé de très nombreuses fois cette techno sur mon appli, le seul bug que j’avais constaté était un crash de l’appli faute de RAM (trop de sous-images créées, trop gros modèle appliqué dessus, bref c’est ingérable). Une augmentation très considérable de la chaleur du smartphone avait également été constatée. Mais ce n’est pas très grave : Google a conçu Android de sorte à crash l’appli dès lors qu’elle essaie d’utiliser davantage de RAM que l’infime portion qui lui est allouée , et DE PLUS, l’appli ne peut pas faire surchauffer le portable, Android interrompant l’appli qui fait ça (enfin sur ce point précis je ne suis pas sûr de moi). De toute façon j’avertis l’utilisateur à divers endroits que l’appli, si une trop grosse image lui est confiée, risque de crash et de faire chauffer son téléphone comme un jeu (bien qu’elle utilise normalement le CPU et non pas le GPU, ce qui je précise aussi).

Récemment, deux mises à jour majeures de cette techno ont été publiées par Google : on est ainsi passé de la v20 à la v22. Il a fallu que je change mes sources pour pouvoir continuer à utiliser cet outil, mais il y a 99% d’équivalence. Le code que j’utilise est tout ce qu’il y a de plus banal, j’ai juste suivi la doc, je ne suis pas un pirate, ni un bidouilleur ni rien.

Suite à cette mise à jour, j’ai testé cette fonctionnalité de deep-learning appliqué sur une image de taille modeste sur mon smartphone de test. Puis sur une autre image (ce point est important). Et là, bim, l’appli ne crashe pas MAIS le smartphone s’éteint direct. J’interromps l’appli via android studio. Je relance le smartphone : il redémarre, et gèle à l’écran de démarrage, puis se relance tout seul avec succès. Par la suite, je refais exactement la même utilisation avec mon appli pour être sûr que c’est cette fonctionnalité qui a fait buguer le truc. Suite à quoi, le smartphone s’éteint direct de nouveau sans crash de l’appli. Cette fois je n’interrompts pas l’appli avec Android Studio, mais je débranche uniquement le câble qui relie le smartphone à l’ordi/AndroidStudio. Résultat : mon smartphone est resté éteint. Impossible de le rallumer. Quand je le mets à charger, la loupiotte de chargement batterie ne s’allume plus. Bref il est pété de chez pété de chez pété. (ou alors il est resté allumé, l’écran est resté éteint, ce qui expliquerait pourquoi la loupiotte de chargement ne s’allume plus).

Je précise que je dispose de 26 modèles de deep-learning, je les charge tous d’un coup, et j’utilise le bon (celui que l’utilisateur veut utiliser).

J’insiste sur le fait que je n’ai pas écrit de ligne de code bizarre, je ne fais que suivre la doc de Google.

Et pourtant, le résultat est que mon appli peut complètement foutre HS un smartphone.

J’ai rétabli l’ancienne version de l’outil de Google, et re-testerai mon appli sur mon nouveau smartphone que je recevrai dans un mois.

Je souhaite rendre publique sur GitHub le code de cette fonctionnalité.

Mes questions sont :

  1. Premier cas : Une fois publiée sur le Playstore, mon appli a pété entre 1 et 10 000 smartphones. Qui va devoir rembourser les utilisateurs et être traduit en justice : moi, qui n’ai fait qu’utiliser de la bonne façon l’outil de Google et qui DE PLUS a publié publiquement le code sur GitHub, ou bien Google, qui a fait de la bonne grosse merde ?

  2. Second cas : Une fois publiée sur le Playstore, mon appli ne pète aucun smartphone (effectivement, j’utilise l’ancienne version de l’outil, qui a priori ne cause pas ce bug). Dans ce cas toutefois, les utilisateurs observent une surchauffe de leur smartphone et le fait que l’appli crash car elle demande trop de RAM. La surchauffe concerne a priori le CPU et non le GPU car mon appli n’est pas un jeu. Les utilisateurs peuvent-ils me traduire en justice ou demander des frais de remboursements parce que cette surchauffe et ces crashs à répétitions détruisent petit à petit leur smartphone (ce qui reste à prouver, normalement Android est censé empêcher ça) ?

  3. Puis-je attaquer Google en justice pour me faire rembourser mon smartphone ?

Je suis quand même bouche bée. Je viens de créer une appli tout à fait légale sans une once de code chelou. Et elle agit comme un putain de virus qui peut détruire des smartphones entiers quoi, WTFFFFFF……………. C’est absurde comme histoire, j’ai du mal à y croire moi-même !

Merci d’avance, bonne journée.

+0 -0

Cette réponse a aidé l’auteur du sujet

Bonjour.

C’est probablement une usure matérielle du téléphone qui s’inscrit sur le long terme et qui ne vient pas de l’application. S’il y a un quelconque rapport avec ton application, elle aurait éventuellement pu être révélée par une hausse ponctuelle de la consommation de ressources, rien de plus.

À première vue, je dirais soit mort de la batterie, soit à la limite usure de la NAND (mémoire interne du téléphone). Tu devrais commencer par essayer de changer la batterie (si c’est plus rentable que d’en acheter un nouveau, bien entendu).

Une surchauffe du CPU n’est pas censée tuer ton téléphone (sauf sur certains rares modèles qui ont été très spécifiquement connus pour ces problèmes, mais tu devrais pouvoir avoir des infos en cherchant sur Google).

Quand ton téléphone démarre, il y a plusieurs étapes : le chargement du bootloader (le code qui va afficher l’animation lors du chargement de la batterie se trouve plus ou moins au même endroit il me semble), qui charge le système Android, qui charge tes applications. Si le bootloader ne charge même pas, alors le problème n’est pas survenu au niveau des applications du système.

Bonne journée,

Auteur du sujet

Bonjour.

C’est probablement une usure matérielle du téléphone qui s’inscrit sur le long terme et qui ne vient pas de l’application. S’il y a un quelconque rapport avec ton application, elle aurait éventuellement pu être révélée par une hausse ponctuelle de la consommation de ressources, rien de plus.

À première vue, je dirais soit mort de la batterie, soit à la limite usure de la NAND (mémoire interne du téléphone). Tu devrais commencer par essayer de changer la batterie (si c’est plus rentable que d’en acheter un nouveau, bien entendu).

Une surchauffe du CPU n’est pas censée tuer ton téléphone (sauf sur certains rares modèles qui ont été très spécifiquement connus pour ces problèmes, mais tu devrais pouvoir avoir des infos en cherchant sur Google).

Quand ton téléphone démarre, il y a plusieurs étapes : le chargement du bootloader (le code qui va afficher l’animation lors du chargement de la batterie se trouve plus ou moins au même endroit il me semble), qui charge le système Android, qui charge tes applications. Si le bootloader ne charge même pas, alors le problème n’est pas survenu au niveau des applications du système.

Bonne journée,

r0anne

Bonjour et merci pour ta réponse,

Il est vrai que c’est un Samsung Galaxy de 2013. Mmh ce pb est apparu systématiquement lors de mes 2 tests avec la nouvelle version de l’API Android.

Quoi qu’il en soit, si jamais des utilisateurs croient que c’est mon appli qui a cassé leur smartphone (étant donnée la grande consommation de RAM/CPU), que va-t-il se passer ? Vais-je être traduit en justice ? Je risque des amendes, de la prison ? Google devant être tenu pour responsable selon moi vu que je fais usage normal de leur outil (Firebase Machine Learning Kit).

+0 -0

si c’est plus rentable que d’en acheter un nouveau, bien entendu.

r0anne

Rentable dans quel sens ?

Oui il est peut-être plus cher de ne changer que la batterie plutôt que le téléphone complet, mais il restera plus rentable de ne remplacer que le composant défectueux.

Résultat : mon smartphone est resté éteint. Impossible de le rallumer. Quand je le mets à charger, la loupiotte de chargement batterie ne s’allume plus. Bref il est pété de chez pété de chez pété. (ou alors il est resté allumé, l’écran est resté éteint, ce qui expliquerait pourquoi la loupiotte de chargement ne s’allume plus).

As-tu essayé de faire un soft-reset ? (Volume bas + bouton démarrage pendant quelques secondes)

Il me parait très peu probable qu’une application puisse avoir un impact sur l’hardware du téléphone… o_O

+0 -0
Auteur du sujet

Résultat : mon smartphone est resté éteint. Impossible de le rallumer. Quand je le mets à charger, la loupiotte de chargement batterie ne s’allume plus. Bref il est pété de chez pété de chez pété. (ou alors il est resté allumé, l’écran est resté éteint, ce qui expliquerait pourquoi la loupiotte de chargement ne s’allume plus).

As-tu essayé de faire un soft-reset ? (Volume bas + bouton démarrage pendant quelques secondes)

Il me parait très peu probable qu’une application puisse avoir un impact sur l’hardware du téléphone… o_O

WinXaito

J’ai tout essayé il est hs de chez hs de chez hsland

+0 -0

Pour moi, ton problème est en fait là :

Il est vrai que c’est un Samsung Galaxy de 2013.

TumulteClassicisme

7 ans ou presque c’est extrêmement vieux pour un smartphone, qui n’a jamais été conçu pour ça. Il est donc très possible que divers composants étaient déjà à l’agonie voire complètement morts, ce qui ne posait pas de problème tant que tu n’avais pas d’usage lourd du smartphone. Mais la forte sollicitation provoquée par ton application a pu mettre en évidence ces faiblesses et/ou finir d’user le peu de marge qui restait.

D’autre part, les smartphones ne sont pas conçus pour être utilisés longtemps à pleine puissance. Ils ne sont conçus que pour être utilisés longtemps à faible puissance, ou très peu de temps (quelques secondes, dizaines de secondes max) à pleine puissance, au-delà la batterie se vite trop vite et surtout ils sont incapables d’évacuer la chaleur produite. Ils sont par contre conçus pour se mettre en protection quand ça arrive : ralentissement drastique des cœurs, diminution du nombre de cœurs utilisés. Sur un smartphone en bon état, ça suffit à éviter que les protections thermiques (coupure pure et simple du téléphone) se mettent en route. Par contre, les performances s’effondrent.

Un test qui date d’un peu plus de deux ans maintenant et fait par Canard PC Hardware montrait des performances divisées par environ 10 (!) entre le pic et le plateau atteint après quelques minutes de test de charge sur les appareils les plus sensibles (Sony à l’époque).

En résumé : tu essaies de faire quelque chose pour lequel les smartphones ne sont pas prévus sur un modèle antique. Tu as eu des soucis, mais ça n’est pas la faute à ton code, et Google ne peut en aucun cas être tenu responsable.

(PS : utilise un avatar carré, là il est tout déformé)

Édité par SpaceFox

Auteur du sujet

Pour moi, ton problème est en fait là :

Il est vrai que c’est un Samsung Galaxy de 2013.

TumulteClassicisme

7 ans ou presque c’est extrêmement vieux pour un smartphone, qui n’a jamais été conçu pour ça. Il est donc très possible que divers composants étaient déjà à l’agonie voire complètement morts, ce qui ne posait pas de problème tant que tu n’avais pas d’usage lourd du smartphone. Mais la forte sollicitation provoquée par ton application a pu mettre en évidence ces faiblesses et/ou finir d’user le peu de marge qui restait.

D’autre part, les smartphones ne sont pas conçus pour être utilisés longtemps à pleine puissance. Ils ne sont conçus que pour être utilisés longtemps à faible puissance, ou très peu de temps (quelques secondes, dizaines de secondes max) à pleine puissance, au-delà la batterie se vite trop vite et surtout ils sont incapables d’évacuer la chaleur produite. Ils sont par contre conçus pour se mettre en protection quand ça arrive : ralentissement drastique des cœurs, diminution du nombre de cœurs utilisés. Sur un smartphone en bon état, ça suffit à éviter que les protections thermiques (coupure pure et simple du téléphone) se mettent en route. Par contre, les performances s’effondrent.

Un test qui date d’un peu plus de deux ans maintenant et fait par Canard PC Hardware montrait des performances divisées par environ 10 (!) entre le pic et le plateau atteint après quelques minutes de test de charge sur les appareils les plus sensibles (Sony à l’époque).

En résumé : tu essaies de faire quelque chose pour lequel les smartphones ne sont pas prévus sur un modèle antique. Tu as eu des soucis, mais ça n’est pas la faute à ton code, et Google ne peut en aucun cas être tenu responsable.

(PS : utilise un avatar carré, là il est tout déformé)

SpaceFox

Ok merci beaucoup !

Si j’avertis les utilisateurs que l’utilisation de cette technologie Google peut faire surchauffer les smartphones, même des récents je pense, ça passe non ? ça ne va pas les user ?

+0 -0

Salut,

Si j’avertis les utilisateurs que l’utilisation de cette technologie Google peut faire surchauffer les smartphones, même des récents je pense, ça passe non ? ça ne va pas les user ?

Ou alors tu peux faire une appli PC à la place, comme ça tu défonces le matériel de personne et surtout tu utilises une plateforme beaucoup plus adaptée pour faire des traitements un peu lourds.

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+4 -0
Auteur du sujet

Salut,

Si j’avertis les utilisateurs que l’utilisation de cette technologie Google peut faire surchauffer les smartphones, même des récents je pense, ça passe non ? ça ne va pas les user ?

Ou alors tu peux faire une appli PC à la place, comme ça tu défonces le matériel de personne et surtout tu utilises une plateforme beaucoup plus adaptée pour faire des traitements un peu lourds.

adri1

Non car le but recherché du CDC est de garantir une appli Android de retouches d’images en local et en local uniquement.

Vous avez l’air de dire que mon projet est nickel donc je publierai l’appli incessamment sous peu et vous pourrez la tester si vous voulez

+0 -0

Vous avez l’air de dire que mon projet est nickel donc je publierai l’appli incessamment sous peu et vous pourrez la tester si vous voulez

TumulteClassicisme

Pas vraiment, non. Je dis plutôt que ton application est bancale par conception (vouloir faire de la retouche d’image à base d’IA sur smartphone directement).

Auteur du sujet

Vous avez l’air de dire que mon projet est nickel donc je publierai l’appli incessamment sous peu et vous pourrez la tester si vous voulez

TumulteClassicisme

Pas vraiment, non. Je dis plutôt que ton application est bancale par conception (vouloir faire de la retouche d’image à base d’IA sur smartphone directement).

SpaceFox

Ouais c’est clair mais j’y peux rien c’est CDC

+0 -0
Auteur du sujet

J’imagine qu’ici « CDC » c’est pour « Cahier Des Charges ».

C’est une application que tu développes pour un tiers ?

SpaceFox

Non pour moi, je crois au potentiel de cette appli car l’utilisateur n’aura jamais besoin d’envoyer ses images ou photos sur un serveur. Puis c’est une proof of concept.

D’ailleurs j’ai pas trop envie d’en parler des fois qu’on me piquerait l’idée éventuellement en lameliorant alors que j’ai passé énormément de temps dessus…

Édité par anonyme

+0 -0

Le concept est intéressant, ce qu’on essaie de te dire c’est que le smartphone n’est pas une plateforme adaptée pour faire du calcul lourd. Si tu es dans un PoC, ça va.

Mais surtout n’oublie pas qu’un PoC peut aussi prouver que le concept ne fonctionne pas.

Surtout, ça n’est pas l’idée qui fait le succès d’une application. Ça n’est jamais l’idée seule en fait. Le succès, c’est la bonne idée, au bon moment, réalisé de la bonne façon, avec la bonne communication autour et la chance du buzz qui décolle. Cf la Microsoft Tablet PC ou Flappy Bird.

Édité par SpaceFox

Non pour moi, je crois au potentiel de cette appli car l’utilisateur n’aura jamais besoin d’envoyer ses images ou photos sur un serveur. Puis c’est une proof of concept.

As ton avis pourquoi tout tes "concurrents" ont choisi d’envoyer les photos en ligne pour les traiter ?

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+5 -0
Auteur du sujet

Mais ça marche ce que j’ai fait hein, l’image de sortie est bien retournée et affichée et sauvegardée dans le portable

Juste que jsp pk, ça a niqué le smartphone, sans doute usé quoi d’après vous et je pense comme vous

+0 -0

D’ailleurs j’ai pas trop envie d’en parler des fois qu’on me piquerait l’idée éventuellement en lameliorant alors que j’ai passé énormément de temps dessus…

TumulteClassicisme

Je crois qu’on en avait déjà parlé, mais ça ça n’arrive pas. Une idée n’a pas de valeur, c’est sa réalisation qui en a. Et cette idée, tu n’es probablement pas le seul à l’avoie eue.

Au contraire, partager ton idée permet d’obtenir des retours, d’évaluer si c’est viable, de la faire évoluer.

Mais ça marche ce que j’ai fait hein, l’image de sortie est bien retournée et affichée et sauvegardée dans le portable

Ouais, mais si tu fais chauffer le portable et que tu pompes sa batterie, personne va se servir de ton app alors qu’il y a des concurrents qui sont beaucoup moins agressifs sur le téléphone en délocalisant les calculs.

I don’t mind that you think slowly, but I do mind that you are publishing faster. — W. Pauli

+0 -0

Je crois qu’on en avait déjà parlé, mais ça ça n’arrive pas. Une idée n’a pas de valeur, c’est sa réalisation qui en a. Et cette idée, tu n’es probablement pas le seul à l’avoie eue.

Au contraire, partager ton idée permet d’obtenir des retours, d’évaluer si c’est viable, de la faire évoluer.

entwanne

+1 !

Ça va faire deux mois que je code DeckyDecky presque exclusivement en diffusant le dev' , j’ai pas encore vu un concurrent pomper mes idées de différenciations. Par contre ça m’a permis de me trouver mes premiers utilisateurs !

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+5 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte