Lollipop : ART se prépare à l’arrivée d’Optimizing, un nouveau compilateur

Je parlait du fait que tu voulait bloquer le GPS en arrière plan, mais l'autoriser en avant plan (on sinon j'ai mal compris tes premiers message.) C'est cette partie là qui pose problème. Et sur le "faut arrêter de penser à la place des gens" parfaitement d'accord. J'aimerais pouvoir dire que oui, je veux que tasker puisse activer le GPS ou la data. Les gens doivent aussi être considérés comme assez grand pour lire la liste des permissions sur le play store. Et les refuser en bloc au besoin. Quand au trucs qui tourne en tâche de fond et bouffe la batterie, pas besoin de permission pour ça. Ocs go m'a bien tuer la batterie, pas fichue de s'éteindre correctement.

"Et donc, en tant que dev, tu ne voit pas le problème, vu comment est fait actuellement android ? Tu ne voit pas les difficultés qu'il y aurait à implémenter ce genre de choses dans android ? Que les appels gps (long), sont dans un thread séparé pour ne pas bloquer le thread UI (et donc, en arrière plan...) Entre autre..." Non, aucun problème a faire. Même avec ce que tu cites. Que les appels GPS soit en arrière plan (dans un thread séparé) n'y change rien, si dans le contexte, en fonction du réglage choisit, l'app est autorisé à faire de la géolocalisation, elle recevra une réponse valide, sinon elle recevra une erreur comme si la géolocalisation avait échoué. Sachant que déjà aujourd'hui une geolocalisation peut aboutir sur une erreur (si le système n'arrive pas à déterminer la localisation (par exemple si pas de GPS et pas de réseau)), les apps gèrent déjà le cas d'erreur. La différence sera qu'il sera instantanée (car permission non accordée). Evidement si les conditions sont remplies pour que la permission soit accordée, le système renvois la localisation comme normalement. C'est donc faisable de façon totalement transparente pour les applications (et c'est pourquoi AppOps (qui est une implémentation de Google) fonctionne déjà très bien (même s'il ne permet pas encore la granularité "toujours / quand initié par l'utilisateur (lorsque l'app est en marche) / jamais", mais seulement "on/off") avec les apps actuels). "Le planquer dans les option de dev ? Y'en a qui root sans savoir ce qu'il font, alors bon... C'est pas ça qui va arrêter les boulets." S'il faut maintenant tenir compte des boulets... Ces derniers assument s'ils font des conneries. Ils sont grand et responsables. Faut arrêter de toujours vouloir penser à la place des gens.

Et donc, en tant que dev, tu ne voit pas le problème, vu comment est fait actuellement android ? Tu ne voit pas les difficultés qu'il y aurait à implémenter ce genre de choses dans android ? Que les appels gps (long), sont supposé être fait dans un thread séparé pour ne pas bloquer le thread UI (et donc, en arrière plan...) Entre autre... iOS à été pensé différemment, voila tout. Le planquer dans les option de dev ? Y'en a qui root sans savoir ce qu'il font, alors bon... C'est pas ça qui va arrêter les boulets.

"Non je suis pas devin, mais j'ai une vague idée du fonctionnement des permissions et de la sécurité sur andoid (et linux).Tu as déjà fait du dev sur android ? Tu a une idée du fonctionnement actuel ?" Oui, mais je ne parle pas du fonctionnement actuel, mais de ce qui devrait être fait (à mon avis). "Déjà que je vois mal google implémenter ça (mais ça c'est que mon avis). Mais peut être qu'on aura un équivalant appOps un jour, mais j’espère pas." En fait AppOps est une implémentation de Google, au départ c'était juste caché dans le système (on pouvait y accéder même sans root). Depuis la 4.4.2, elle n'est plus accessible sans root. Donc en réalité Google travaille sur cette interface depuis plusieurs versions maintenant, mais semble pas encore enclin à la rendre public (certainement parce que pas encore tout à fait prête à leurs yeux). "Ras le bol de voire certaines app devenir inutiles à cause des paranos des permissions. (Et de certains dev qui font n'importe quoi)" Oui bah les paranos comme tu dis, ils ont autant le droit d'exister que toi. Et si on tient à contrôler ce qu'on autorise aux apps, c'est notre droit. "Mais revoir la façon de gérer les permission de façon aussi drastique, juste pour une distinction premier plan / arrière plan et faire plaisir à une minorité, non, ça n'arrivera pas." Et qui te dit que c'est une minorité? Avec le contexte actuel, le nombre de personnes qui se soucis de leur données privées est de plus en plus important. Et je ne vois pas le problème d'implémenter cela pour ceux qui n'ont rien à faire de contrôler les permissions, par défaut toutes les permissions peuvent être accordée, et c'est l'utilisateur qui, s'il le souhaite, peut aller les désactiver. Evidement pour éviter les risques qu'un utilisateur pas suffisamment conscient des implications de la désactivation de tel ou tel permission, cette fonctionnalité peut être cachée dans la partie "développeur" des réglages d'Android (qui est cachée par défaut comme tu le sais). "Si cette fonction est si importante pour toi, et que effectivement ça existe chez Apple, ben, achète un iPhone quoi." J'ai les deux, je suis développeur mobile sur iOS ET Android, donc j'ai un terminal iOS et un terminal Android.

Non je suis pas devin, mais j'ai une vague idée du fonctionnement des permissions et de la sécurité sur andoid (et linux).Tu as déjà fait du dev sur android ? Tu a une idée du fonctionnement actuel ? Déjà que je vois mal google implémenter ça (mais ça c'est que mon avis). Mais peut être qu'on aura un équivalant appOps un jour, mais j’espère pas. Je voudrait surtout pouvoir donner plus de droit au application moi (genre les droits de toogle data / gps que google à dégager..) Ras le bol de voire certaines app devenir inutiles à cause des paranos des permissions. (Et de certains dev qui font n'importe quoi) Mais revoir la façon de gérer les permission de façon aussi drastique, juste pour une distinction premier plan / arrière plan et faire plaisir à une minorité, non, ça n'arrivera pas. Si cette fonction est si importante pour toi, et que effectivement ça existe chez Apple, ben, achète un iPhone quoi.

"Une application à le droit pour le GPS ou ne n'a pas. La distinction arrière plan / premier plan n'existe pas. Et n'existera jamais." Ah bon ça n'existera jamais? Tu es devin maintenant. Car techniquement y'a aucun problème à le gérer et d'ailleurs c'est le cas sur iOS. Mais effectivement cela nécessite une évolution au niveau de l'OS (dans sa version actuelle on ne peut effectivement qu'activer ou désactiver la permission, même avec AppOps), et donc l'intervention de Google. "Google now vérifie régulièrement ou tu es. C'est ce qu'il faut pour mettre à jour les cartes. Sans ça, tu perds des fonctionnalités." Oui je sais très bien, et je préfère personnellement perdre ces fonctionnalité pour gagner en autonomie. Et je suis bien content que Google Now permette à l'utilisateur de choisir. "Laisser l'utilisateur contrôler les droit, et après venir pleurer que ça marche pas... Non merci. C'est sûrement pour ça que ce genre de fonction n'existe pas." Pourtant Google n'a pas rejeté les demandes d'évolution (feature request) qui ont été fait en ce sens. Donc je pense que cela sera bel et bien implémenté dans une prochaine version d'Android. Car c'est un défaut majeur d'Android à mes yeux comparé à iOS par exemple qui le permet d'office sans jailbreak (équivalent du root sur iOS). "Sinon, tu coupe carrément la localisation, ça marche aussi." Oui mais je préférerais le faire que pour certaines application, et que pour l'arrière plan. Comme je peux déjà le faire sur iOS par exemple.

Ben, non. Une application à le droit pour le GPS ou ne n'a pas. La distinction arrière plan / premier plan n'existe pas. Et n'existera jamais. Laisser l'utilisateur contrôler les droit, et après venir pleurer que ça marche pas... Non merci. C'est sûrement pour ça que ce genre de fonction n'existe pas. Google now vérifie régulièrement ou tu es. C'est ce qu'il faut pour mettre à jour les cartes. Sans ça, tu perds des fonctionnalités. Sinon, tu coupe carrément la localisation, ça marche aussi.

Oui tout à fait c'est pour ça qu'il faut une implémentation intelligente de la gestion des permissions, pour celles qui doivent rester activés si initiée au départ par l'utilisateur. Pour la localisation, il faut que l'utilisateur puisse choisir entre autoriser à ce que la geolocalisation en arrière plan soit toujours possible (même si c'est pas suite à sa demande), autorisée uniquement s'il l'a initié lui même (cas d'un GPS (maps par exemple)), jamais autorisé. Et persiste et signe si tu veux, j'ai constaté moi même l'impact de la geolocalisation en arrière plan. Pour prendre un exemple d'une app qui laisse le choix de l'activer ou non: Google Now. Si on désactive cela, on voit un impact d'environ 5% sur la batterie (sur un Nexus 5). Cela peut paraître faible, mais si on a d'autres apps qui font ce genre de chose, l'accumulation de toutes a un impact notable. C'est parfaitement implémentable sans que les devs n'aient à se casser la tête à gérer les différents cas. Cela est déjà fait par un système concurrent et ça marche très bien.

Pas du tout. Le premier plan, côté Android, c'est l'activité affichée. L'extinction de l'écran à le même résultat que un changement d'activité. On appelle la fonction on pause. Si le dev à fait son taf dans les on pause / on resume il n'y a pas de problème. Donc, je persiste et signe. La demande de la localisation à un impact quasi null sur la batterie. Si ça arrive c'est où une utilisation réelle (maps), ou une programmation n'importe comment. Seul une service en tâche de fond aura cette effet, en cas de demande répété. Si un jour Google implémente ça, les dev s'assurent que l'application à les droit, et paf on balance une erreur. Retour à la case départ. Par ce que non, les dev vont pas avoir envie de ce pourrir à gèrer les différents cas.

"Et comment map fait pour fonctionner autrement hein ? Les applications mentionnées, comment elle marche autrement ? Si tu laisse l'écran allumé et tue encore plus ta batterie.." Etre au premier plan, ne nécessite pas forcément de garder l'écran allumé. Cela nécessite seulement que l'application soit la dernière lancé et qu'on ne la quitte pas. A noter que la géolocalisation soit fait écran éteint, lorsqu'elle a été explicitement initié par l'utilisateur et donc lorsque l'application est active, cela ne me dérange aucunement. Et a noter également que je ne dis pas que certaines géolocalisation en tâche de fond (i.e: constante et régulière), ne sont pas pratique et utiles. Ce que je demande c'est qu'en standard l'utilisateur puisse décider s'il juge tel ou tel permission utile pour tel ou tel application, selon ses besoins. Bref, ce que permet AppOps (sur device rooté ou ROM custom), mais en standard. "Si les développeurs font de la merde, Google n'est pas en cause. Et je parle en tant que dev. Signal le problème au dev plutôt." Tu es trop binaire dans ton raisonnement. Je n'ai aucunement mis en cause les développeurs, car les fonctionnalités qui utilisent ces permissions le font judicieusement dans la vaste majorité des cas. C'est à dire que la permission est belle et bien nécessaire pour les dites fonctionnalités. Donc non, ce ne sont pas les développeurs qui font de la merde dans les exemples que j'ai donné. C'est juste que ces fonctionnalités ne sont pas utiles pour tous le monde. Bref, ce que je dis depuis le début c'est que les utilisateurs devraient pouvoir choisir eux même s'ils jugent tel ou tel permissions nécessaire en fonction de leurs usages de l'application. A noter que quand je dis que pouvoir configurer les permissions est très utile, notamment pour l'autonomie, je parle en connaissance de cause, pour avoir utilisé cette fonctionnalité sur mon Nexus 5 avec AppOps. Donc tu pourras dire ce que tu veux, que c'est la faute des développeurs, que ça sert à rien, tu n'arriveras pas à me convaincre, puisque je sais en pratique l'intérêt énorme de cette fonctionnalité (notamment pour l'autonomie mais aussi pour la vie privée), et c'est pourquoi je souhaiterais que cela soit en standard. Ne t'inquiète pas, j'ai déjà fait une feature request auprès de Google (et je ne suis pas le seul à l'avoir fait). Et je suis persuadé que tu seras le premier à vanter les mérites de cette fonctionnalité dès lors qu'elle sera intégrée en standard (ou si d'ici là tu l'expérimente en rootant ton téléphone et en installant AppOps).

Et comment map fait pour fonctionner autrement hein ? Si les développeurs font de la merde, Google n'est pas en cause. Et je parle en tant que dev.

"Même le smartphone lui-même tu peut t'en passer." C'est sur si tu pars de ce principe là... N'importe quoi! "jamais vu une application avec des droits qui ne s'expliquent pas." Je n'ai jamais parlé de droits qui ne s'expliquent pas, seulement de droits qui consomment la batterie. Un exemple concret: la geolocalisation en arrière plan, si ce droit est autorisé sans aucune restriction de temps, alors cela peut faire chuter la bartterie drastiquement. Il est utile mais peut être limité soit uniquement lorsque l'app est au premier plan (bien souvent cela est suffisant pour la plupart des gens), soit limité dans le temps. Un exemple d'application qui permet d'ajuster ce paramètre, c'est Sensorly, on peut choisir entre rester actif en permanence (et on peut dans ce cas limiter l'impact sur la batterie a un maximum (en pourcentage)), ou ne l'autoriser que lorsque l'app est active (au premier plan). Et pour avoir tester différents réglages, je peux te dire que la différence est très visible. Si tu as en plus plusieurs applications qui font de la geolocalisation en arrière plan (ex: Google Now, TripAdvisor, RunKeeper...), même de façon légère, cela s'additionne et au bout d'un moment l'impact sur la batterie devient notable.

Les deux points n'ont rien à voir. Et toute les applications sont dispensables. Même le smartphone lui-même tu peut t'en passer. Et à part des applications louches, jamais vu une application avec des droits qui ne s'expliquent pas. Même l'application Facebook, tu peux trouver les fonctionnalités correspondant à chaque droits.

Ta règle n'est applicable que si on peut se passer de l'app en question. Ce qui est loin d'être toujours le cas, surtout qu'énormément d'app abusent des permissions. C'est bien dommage de supprimer bêtement et simplement une app dont on a besoin alors qu'avec un système de contrôle fin des permissions il serait possible de la conserver tout en faisant en sorte qu'elle ne consomme pas excessivement la batterie.

Oui c'est clair. A noter qu'il y a déjà des feature requests pour cette fonctionnalité sur AOSP. Espérons qu'elles seront bientôt prise en compte.

Il n'y aura aucun problème avec le nouveau compilateur avec les soc atom X86(X64 bit).

En faite, c'est déjà le cas.Il n'y a plus aucun problème avec les soc atom X86 sur les logiciels android, intel travaille main dans la main pour optimiser ses soc atom pour. Le zenfone 2 le prouve bien avec l'atom moorefield, le morganfield arrive en 14 nm aussi. Intel ne veut pas s'embarrasser avec du arm, il n'en a pas du tout besoin.

Les autorisations n'ont rien à voir avec ça. Et si une application abuse, ne l'installez pas. Pareil pour celle qui bouffent ma batterie, ça dégage. Les processus en arrière plan, oui.

Ce n'est pas parce que ARM aide Google que les processeurs x86 de Intel et AMD ne seront supportés. Si le code du compilateur est libre, Intel et AMD pourront l'optimiser pour architecture x86 qu'ils utilisent.

Si le compilateur compile du code natif pour le processeur et non du bytecode, ART sera inutile. Mais il sera probablement conservé pendant quelques temps pour pouvoir faire fonctionner les apps compilées en bytecode.

TG.

encore pire a mon avis, le droit de réveiller ou d empêcher la mise en veille. Et les éditeurs ne sont pas les seuls a blâmer, qd je vois que les services Google play me pompent plus de batterie que tout Le reste, y compris écran, obligé de lui retirer ces droits <i>-------<a href="https://play.google.com/store/apps/details?id=com.frandroid.app">Envoyé depuis l'application FrAndroid pour smartphone</a></i>

ils feraient surtout mieux d être plus stricts sur les autorisations données au apps ou au moins de donner plus de contrôle a l utilisateur. c est pour moi le principal problème d'Android car n importe quelle app peut demander n importe quelle autorisation. les listes d autorisations demandées sont bcp trop longues pour le commun des mortels qui n a pas 5min a chaque install pour decortiquer une liste de 3 pages d autorisations dont il ne comprend pas les implications. un système du type privacy guard serait bien plus efficace, mais il faudrait l adapter au grand public. je pense que ça fait peur au développeurs d apps mobiles qui ne veulent pas perdre la possibilité d abuser des autorisations en toute impunité.<i>-------<a href="https://play.google.com/store/apps/details?id=com.frandroid.app">Envoyé depuis l'application FrAndroid pour smartphone</a></i>

Ça c'est pas mon problème. Google m'a "vendu" le project volta comme solution miracle au PB d'autonomie, on voit bien le résultat...

Le meilleur "projet Volta" serait que l'utilisateur puisse désactiver, en standard (sans avoir à rooter ou installer une ROM custom, les permissions des applications à la permission prêt, app par app. Ainsi que de pouvoir contrôler les apps qui peuvent s'executer en arrière plan. Car au final ce qui bouffe le plus la batterie ce sont certaines permissions (je pense notamment à la geolocalisation) ou traitements en arrière plan.

Ha oui t'as raison !

Celui qui a dit, du temps où il officiait sur foun radio que les petits juifs partaient en camp de vacances ?

Si c'était le cas, y'aurait pas de N6 32 Gigas, et encore moins 64;)

Ce qui prend plus de place c'est surtout a cause du FHD et QHD pour du FHD faudrait minimum 32Go (mini 16Go mais c'est limite) et en QHD faudrait minimum 64Go a cause des photos et vidéo qu'on prend sut ce genre de smartphone par exemple qui prennent 3 fois plus de place qu'avant . -------Envoyé depuis l'application Humanoid pour smartphone

J'adore Google et les Google phone mais le plus gros point noir de Google c'est de nous forcer aux Cloud et c'est vraiment débile !-------Envoyé depuis l'application Humanoid pour smartphone

ART bouffe surtout un peu plus de mémoire vive !! Pour le stockage pas grand chose à changer et cela fait un moment que 8Go c'est obsolète . -------Envoyé depuis l'application Humanoid pour smartphone

c'est parceque sur mobile c'est la courses ! Ils vont tous trop vite que ce soit Apple , Samsung , Google ils vont en ce précipitant et ils ce disent que si y'a des problèmes ils corrigeront le tir par la suite . -------Envoyé depuis l'application Humanoid pour smartphone

Projet volta n'est qu'un outils pour les dev. Encore faut-il que les dev l'utilise. La majorité ( si pas la totalité) des problèmes que j'ai eut, c'était une application mal faite.

non tu est juste comme le francais moyen tu lis des trucs mais tu comprend que dalle.

l'animateur de skyrock ? je pense pas, car c'etait ya bien 18ans deja je m'en rappel, ou alors il doit etre rincé maintenant... le pauvre

C'est ce qu'il a dit, t'es paumé toi vraiment <i>-------<a href="https://play.google.com/store/apps/details?id=com.frandroid.app">Envoyé depuis l'application FrAndroid pour smartphone</a></i>

Fallait sortir Lollipop pour le Nexus 6 et y avait pas le temps de faire ART et Optimizing<i>-------<a href="https://play.google.com/store/apps/details?id=com.frandroid.app">Envoyé depuis l'application FrAndroid pour smartphone</a></i>

C'est ce qu'il a dit :D

oh non mais comment peut on osé, mais ca existe encore difool? XD

Intel c'est de l'architecture X86, alors que les mobiles actuels utilisent l'architecture ARM (jeux d'instruction différent). Néanmoins, rien n'empêche Intel d'acheter une licence de production ARM. Je ne pense pas que ce soit réellement un problème pour l'avenir. Il serait également possible d'optimiser un compilateur pour puces Intel.

...et Google et sa politique de l'espace de stockage interne minimal et non-extensible. Bientôt les applis elles-mêmes seront stockées dans le cloud Google drive...

La question à 1M$ est : pourquoi donc ont-ils précipité ART avec un compilo bricolé issu de Dalvik, tout en markettant ART comme étant radicalement différent de Dalvik, plutôt que de préparer proprement et sortir Optimizing avec ART ?... ART a fait l'effet d'un pétard mouillé jusqu'à présent... Les économies de batteries et améliorations de perfs sont pas si grandioses ; associé à Lollipop et ses leaks gênants qui ont mis une sous-version à être corrigés... Bof...

Malheureusement faudrait déjà qu'ils abandonnent le 4 Go.

c'est bien d’améliorer les performances, mais faut pas oublier que le passage de Dalvik à ART n'est pas sans conséquences. La place que prenne les applications est beaucoup plus importante et avec le nouveau compilateur selon les chiffres annoncer dans cet article ça ne va pas s'arranger. Les constructeurs devraient abandonner le 8go et standardiser la mémoire interne de 16go voir 32go parce-que 8 c'est très vite saturé surtout avec les surcouches constructeurs qui bouffe de l'espace (appli pré-installer). A cause de ca depuis le passage de mon HTC sur android 5.0 et par la même occasion le changement de machine virtuelle au bout d'une dizaine d'appli installer j'avais plus d'espace donc j'ai du changer de phone :/

oui j'avais mal lue le début de l article désolé :3 <i>-------<a href="https://play.google.com/store/apps/details?id=com.frandroid.app">Envoyé depuis l'application FrAndroid pour smartphone</a></i>

Ah oui le fameux enfumage du project volta...

Logiquement elle devrait augmenter un peu, puisque le CPU est utilisé moins longtemps pour chaque action.

Ils promettaient des améliorations de performance avec Lollipop et au final apparemment pour beaucoup de monde c'était plutôt l'inverse... Il faut espérer que cette fois la pratique sera à la hauteur de la théorie <i>-------<a href="https://play.google.com/store/apps/details?id=com.frandroid.app">Envoyé depuis l'application FrAndroid pour smartphone</a></i>

C'est quoi le rapport ?

C'est censé être drôle ?

Pourquoi cela ???

non tu n'as rien compris, ART va toujours être utilisé comme machine virtuelle, c'est juste le compilateur qui change pour une amélioration des performances.

tu es paumé mec (et non pommé, où alors c'est que tu es victime d'Apple, et alors je compatis à ta maladie). Jeu de mots mis à part, c'est bien toujours ART mais avec un nouveau compilateur qui va encore améliorer ses performances.

C'est bien, manque plus que l'autonomie et ce sera parfait. 40% d'autonomie en plus, j'en rêve tellement !-------Envoyé depuis l'application Humanoid pour smartphone

Ok super merci

Art..! enlève ton slip ! :-) <i>-------<a href="https://play.google.com/store/apps/details?id=com.frandroid.app">Envoyé depuis l'application FrAndroid pour smartphone</a></i>

" Au lieu d’être basé sur le compilateur de Dalvik (comme l’est Quick), les ingénieurs ont tout repris de zéro " donc se sera toujour art mais avec un nouveau compilateur ou je suis pommé? :3<i>-------<a href="https://play.google.com/store/apps/details?id=com.frandroid.app">Envoyé depuis l'application FrAndroid pour smartphone</a></i>

Ça pue pour les futurs mobiles Intel du coup ?

art va être remplacer à se que j ai compris sauf pour le boot pour le moment, encore un petit coups de jeune pour mon s3 manque plus que d être patient et que des roms customs sortent :3<i>-------<a href="https://play.google.com/store/apps/details?id=com.frandroid.app">Envoyé depuis l'application FrAndroid pour smartphone</a></i>

non il s'agit simplement du compilateur d'ART.<i>-------<a href="https://play.google.com/store/apps/details?id=com.frandroid.app">Envoyé depuis l'application FrAndroid pour smartphone</a></i>

Ok c'est cool ça, parce que déjà que ART a du mal à ce mettre en place, alors si il foutent encore un autre ça va être la galère

Juste le compilateur d'après ce que j'ai compris.

C'est une bonne nouvelle! Cependant je n'ai pas suivis. ART va encore être remplacé ou c'est juste le compilateur ?