Votre sang de geek bouillonne depuis la mise en ligne de l’annonce d’Android 4.4 alias KitKat. Vous avez peut-être même déjà craqué pour un nouveau Nexus 5. Et certains d’entre vous auront fait comme à chaque fois, ils auront testé la nouvelle image pour l’émulateur en se disant : « Mais non, ça ne va pas ramer, et cette fois-ci, il y aura des trucs à voir dans l’émulateur »… Bon au final, l’émulateur a mis 15 minutes pour se lancer… et à part des icônes un peu changées il n’y a rien de marrant. Vous étiez donc blasés et avez décidé de partir au lit en boudant avec votre nounours. Mais heureusement, nous on avait rien à faire alors on a lu la doc’… Et il y a quand même quelques trucs à retenir !
Pour rappel, quelques sources sont utiles pour les développeurs et les designers :
- La page de mise en avant des grosses features : http://developer.android.com/about/versions/kitkat.html
- La doc des nouvelles APIs : http://developer.android.com/about/versions/android-4.4.html
- La même chose pour les nouveautés design : http://developer.android.com/design/patterns/new.html
- Le changelog précis : http://developer.android.com/sdk/api_diff/19/changes.html
- Les changements dans la lib de support : http://developer.android.com/tools/support-library/index.html
- Les changements des outils de dev : http://tools.android.com/release
- Les changements des Play Services : http://android-developers.blogspot.fr/2013/10/google-play-services-40.html
Ouais, ça fait beaucoup à lire … du coup on va résumer pour vous !
Les designers, quelques changements pour vous
Maintenant, c’est une habitude. Depuis qu’il y a de vrais bons dans l’équipe Android (comme ce cher Matias Duarte), les aspects design et ergonomie sont beaucoup mieux définis. Pour cette version, Google a pris en compte un retour fréquent de la communauté de développeurs : les couleurs de Holo sont très fortes (ce bleu flashy notamment), du coup les choix de couleurs spécifiques des marques peuvent être gênés. Deux changements vont corriger le problème.
Une nouvelle page dans la rubrique Design de la documentation a fait son apparition. Elle donne quelques recommandations pour appliquer les couleurs de votre marque à votre application, tout en restant dans les lignes de conduite Android : http://developer.android.com/design/style/branding.html.
L’objectif est d’être « compatible avec l’expérience Android, tout en gardant la personnalité de votre marque« .
Un autre point intéressant est situé au niveau du changement du retour utilisateur au moment du clic. Avant, il était conseillé de mettre un halo de couleur autour de la touche. Google a pensé que ce halo est trop appuyé et n’aide pas à la lisibilité. Pour corriger cet effet, il est maintenant conseillé d’appliquer un effet « plus sombre » à son bouton dans l’état pressed. Là aussi, la page dédiée à ce comportement a été majourée (une contraction du verbe mise-à-jourer… je te majoure, tu te majoures…) : http://developer.android.com/design/style/touch-feedback.html. J’ai demandé sur Google+ à Nick Butcher et Roman Nurik s’il était intéressant de garder une rétrocompatibilité sur ce changement. J’attends leur réponse au moment d’écrire l’article.
Un autre changement majeur est l’arrivée de la mise en page Full-Screen pour toutes les applications. Comprenez par là la disparition de la barre de notification et de la barre de boutons si le terminal en dispose. Jusque là, seule la lecture de vidéo en profitait quand le système la gérait. Maintenant toutes les applications vont pouvoir en profiter pour rendre l’expérience plus immersive, notamment pour la lecture de livres ou de vidéos ou pour les jeux vidéo. De plus, la barre de notifications devient translucide. J’ai repéré une discussion intéressante entre Romain Guy et Jake Wharton sur Twitter sur la manière de gérer le padding de la barre de notifications transparente.
Enfin, pour les graphistes, un dernier outil a été ajouté : de nouvelle gestures. Les graphistes pourront imposer à leur développeurs d’intégrer des gestures+animations de « page qui se tourne » sans que le développeur dise que c’est trop compliqué.
Nouvelles APIs pour les développeurs
On a pas mal de choses à se mettre sous la dent grâce aux nouvelles APIs propres à KitKat.
Tout d’abord, le composant WebView a pas mal changé. Précédemment, Android utilisait le moteur WebKit de base dans la WebView comme dans le navigateur natif. Maintenant, c’est le moteur de rendu de Chromium (partie 100 % open source de Chrome) qui est utilisé. Les promesses sont toujours plus de performances et les dernières APIs HTML5 dans votre WebView. Je laisse les spécialistes commenter sur le sujet.
Un tout nouveau package CardEmulation fait son entrée. Pour les services autour du NFC (partage de données à courte portée, paiement sans contact, carte de fidélités, toussa toussa) c’est une fonctionnalité de plus pour permettre aux développeurs de rendre nos smartphones indispensables. C’est une API qui doit permettre de mieux gérer les cartes virtuelles NFC. Par ailleurs, il semble aussi qu’il soit possible pendant l’exécution de l’application de bloquer certaines lectures de tag NFC à vote application.
A partir de Android KitKat, il ne sera plus nécessaire de demander la permission External Storage pour accéder au dossier spécifique de son application sur la carte mémoire externe. Sans la permission, vous n’aurez accès qu’au dossier retourné par Context.getExternalFilesDir(). Le gros avantage, c’est que si vous n’avez pas besoin de naviguer dans toute l’arborescence, c’est une permission de moins nécessaire.
Une amélioration de l’AlarmManager a pour objectif d’améliorer l’impact pour la batterie. Vos services utilisant AlarmManager pour s’exécuter à un moment précis ne sont plus assurées de s’exécuter au temps précis défini. Le système va lancer toutes les alarmes « proches » ensemble afin de réveiller le terminal qu’une fois pour toutes ces alarmes « proches ». Si vous souhaitez une mise à jour précise (pour une application d’horloge par exemple 8) ), utilisez « setExact » en lieu et place de « set« . Le même comportement est ajouté aux APIs de synchronisation.
Toute une nouvelle API pour l’intégration d’imprimantes a été ajoutée. Vous aller pouvoir envoyer des images et des documents au format PDF. Toutes les applis de billetterie vont pouvoir se mettre à jour par exemple. Le tout se passe avec le nouveau PrintService.
L’API SMS abeaucoup changé. Avant, toutes les applications étaient en lecture/écriture sur le ContentProvider des SMS. Maintenant, l’utilisateur peut définir une application SMS par défaut. Celle-ci sera la seule en capacité d’écrire les SMS. Pensez à lire le billet du blog officiel sur le sujet.
Pas mal de mises à jour sur l’API de médias ont été faites. C’est assez pointu, donc je vais commenter ce que j’ai compris :
Pour la vidéo, vous pourrez maintenant adapter le rendu du codec à la volée, avoir un accès à l’ImageRenderer plus précis pour de meilleures performances et profiter de nouveaux codec comme le WebVTT. Pour l’audio, plus de libertés sur la lecture sont données et un effet pour les basses plus efficace est à disposition. Enfin, l’API de contrôle de lecture a distance a été améliorée afin d’offrir plus d’options aux applications tierces.
De nouvelles animations sont aussi disponibles dans le package Transitions. Vous avez à votre disposition l’objet Scene pour mieux représenter une ensemble d’animations à appliquer entre deux vues. Vous pouvez aussi mettre en pause maintenant vos animations.
Des optimisations pour les graphismes ont été ajoutées vous permettant de gérer plus finement la réutilisation des bitmaps. C’est un gain en performance qui peut être non-négligeable.
La gestion des fichiers intègre au nouveau format : le document. L’intérêt est de fournir à n’importe quel fichiers des propriétés de documents. C’est-à-dire un fichier pour lequel l’application peut vouloir garder l’accès sans pour autant le charger complètement. Toute une nouvelle page a été ouverte pour cette fonctionnalité.
De nouveaux capteurs vont permettre d’enrichir vos applications. Le plus marrant étant le capteur de « pas » (quand vous marchez) hardware ou podomètre pour une meilleure optimisation batterie. Le magnétomètre vient offrir de nouvelles fonctionnalités quand le gyroscope n’est pas disponible. De plus, dans un objectif d’amélioration de la batterie, votre application pourra décider de ne recevoir des événements de capteurs qu’à une fréquence que vous aurez choisi et non pas à chaque rafraîchissement du capteur.
Vous pourrez maintenant transformer votre terminal Android en petite console. En effet, les développeurs de jeux vont être capables de différencier les contrôleurs connectés pour différencier les joueurs. Pensez donc à supporter le nouveau getControllerNumber.
Pour l’accessibilité, des nouvelles APIs permettent de gérer des drawables miroir pour que non seulement le texte, mais aussi le visuel, s’adaptent au besoin.
Trois nouvelles permissions ont également vu le jour. Deux servent à gérer l’ajout et la suppression de raccourcis et une à gérer l’interface IR, je vais y revenir.
Cinq nouvelles fonctionnalités du téléphone peuvent être demandées par votre applications :
- La présence d’un capteur infrarouge
- La gestion d’une politique de terminal
- La fonction NFC Host Card vue plus tôt dans l’article
- Et les deux fonctions liées au compteur de pas
Enfin, c’est peu visible dans l’annonce, mais une nouvelle API de gestion d’échanges par infrarouge devrait vous permettre de faire des télécommandes universelles avec les terminaux compatibles. Je pense que c’est dans le package ConsumerIRManager.
Pensez à passer votre target API en 19 !
Faites enfin de belles vidéos de vos applications
Un des problèmes récurrents sur Android, c’est la difficultés de faire des vidéos promotionnelles de vos applications. Actuellement, il fallait une carte d’acquisition HDMI et un terminal compatible.
Maintenant, avec Android KitKat, une nouvelle option dans le menu « Options pour les développeurs » permet de lancer le l’enregistrement du flux vidéo. Pour récupérer le résultat, exécutez « adb shell screenrecord » depuis la console de votre ordinateur. C’est quand même bien plus facile.
Grosse mise à jour dans les Play Services
Pour rappel, les Play Services sont les fonctionnalités « closed sources » de Google poussées par l’intermédiaire des mises à jour du Play Store. L’avantage numéro 1 c’est la migration indépendante de la version (donc avec une large rétro-compatibilité), le désavantage étant le menottage aux fonctionnalités Google (big brother, NSA, tout ça…). Après, il faut dire qu’il y a des fonctionnalités sympathiques.
Tout d’abord, si vous utilisez AdMob, maintenant Google Mobile Ads est intégré au Play Services pour remplacer la bibliothèque AdMob. Google promet des corrections de bugs « over the air« , de nouvelles pubs plus interactives (comprenez plus performantes aussi), de nouveaux outils pour vous aider à monétiser vos applications. L’autre ajout majeur est de prendre en compte l’Android ID de l’utilisateur. C’est pour lui la possibilité de restreindre les pubs aux seuls thèmes qui l’intéresse, mais aussi pour le développeur d’améliorer la pertinence de la pub grâce à des informations cross-apps.
Les fonctionnalités de localisation et de Maps ont encore été améliorées afin d’être toujours moins gourmandes pour votre batterie. N’hésitez pas à utiliser les Geofencing par exemple.
Enfin, des fonctionnalités de test en sandbox sont disponibles pour Google Sign-In et Google Wallet. Mais aussi quelques amélioration pour vos possibilités d’achats In-App avec Google Wallet.
La bibliothèque de support et le NDK légèrement améliorés
La « support library » pour améliorer la rétro-compatibilité a été aussi un peu améliorée. Essentiellement, l’objectif est d’utiliser des APIs qui ressemble à celles nouvellement introduites (comme le framework de Print) et la bibliothèque gère pour vous le renvoi des données cohérentes quelle que soit la version Android d’exécution. Le détail sympa, c’est l’ajout de PopupMenu drag’n’dropables, je vous laisse lire la doc.
Le NDK, la partie des outils pour le développeur qui vous offre la possibilité d’écrire dans du code C/C++ bas niveau a un peu changé. Outre quelques APIs stabilisées, c’est RenderScript qui est maintenant accessible depuis le NDK. C’est donc pleins d’optimisations pour vos animations écrites avec le NDK qui sont offertes.
Quelques améliorations dans les outils pour développeurs
Tout d’abord, la nouvelle star Android Studio passe en version 0.3.2. On reste en version preview.
Android Studio est capable maintenant d’appeler lui même la fonctionnalité d’enregistrement d’écran afin de stocker le flux de votre écran en fichier vidéo.
Android Studio propose maintenant une preview des drawables créés de façon programmatique. C’est très utile pour vérifier que le résultat de votre image est bien celui que vous souhaitez, sans lancer l’application sur le terminal. Une nouvelle vue de preview est aussi disponible pour les menus.
Une nouvelle méthode de build expérimentale promet aussi entre 20 et 30% de gain de temps. A vos risques et périls si vous l’activez.
De leur côté, le SDK et le plugin ADT n’ont connu que des corrections de bugs et le support de KitKat. De là à voir le pragmatisme de l’abandon de Eclipse, il n’y a qu’un pas.
En conclusion, laissons Google récapituler
Et pour finir l’article, quoi de mieux qu’un DevBites pour revoir tout ça ?
Retrouvez un résumé du meilleur de l’actu tech tous les matins sur WhatsApp, c’est notre nouveau canal de discussion Frandroid que vous pouvez rejoindre dès maintenant !
Merci pour ta réponse, du coup, je me demande pourquoi j'ai dû passer à une version cyanogen car il y avait de moins en moins d'applications compatibles ? probablement car une api de compatibilité gardera, malgré tout, des limites ? et que, de ce fait, la fragmentation dûe à une non-imposition d'une règle de mise à jour proposée par les constructeurs n'a pas été envisagée ? Cela restera, pour moi, un gros désavantage. Un peu comme WP où les possesseurs du 7 ont vu rapidement une désaffection des développeurs pour WP8... Nous verrons la gestion des màj qui seront faites avec WP8 et les suivants, mais si c'est aussi désastreux qu'Android... ça risque de me poser problème :(
C'est quoi le codec vidéo ? H264 ? H265 ? On peut aussi enregistrer le son ? Si oui, avec quel codec ?
Les distributions GNU/Linux ont quasiment toujours SELinux activé. C'est bien pour la sécurité, on peut le configurer et le désactiver (bien que ce soit déconseillé). Il faut juste espérer que Android laisse le choix à l'utilisateur de faire ce qu'il veut.
Ca s'intègre au niveau de l'application, et oui les dévs l'utilisent vraiment surtout pour les fragments qui sont apparu avec Android ICS pour les smartphones, la librairie de support permet leur utilisation avec les versions < 4. Si tu veux en savoir plus : http://developer.android.com/tools/support-library/features.html :)
et ça s'intègre dans l'ancien OS ou dans l'application ? si c'est au niveau applicatif, est-ce que les dévs l'utilisent vraiment ? si c'est au niveau OS pourquoi n'est-ce pas plus connu et où le trouve-t-on ?
Ce n'est pas à des bénévoles de faire le travail de ceux qui ont pris l'argent de nos portefeuilles d'ensuite aller se rendormir dans leurs caves... Rien à ajouter :)
ben c'est bien ce que je dis, il y a une garantie qui doit permettre de couvrir les devices pendant x années. Tu évoque une ROM custom, de fait, c'est du reverse engineering donc de la bidouille... Peu importe la capacité des dév' qui s'en occupent, ce n'est pas leur rôle. Donc si les différents constructeurs veulent s'y appuyer, why not, mais il faut l'officialiser et le définir dés le départ. Reste que le problème sera le même, il y a un minimum d'effort à fournir de la part des constructeurs, que ce soit des drivers, que ce soit eux qui fournissent la version initiale sans la surcouche, etc... Ce n'est pas à des bénévoles de faire le travail de ceux qui ont pris l'argent de nos portefeuilles d'ensuite aller se rendormir dans leurs caves...
Oui. Mais le coup du proco, c'est un peu comme Samsung et ses Exynos. Si le coded n'est pas fourni, pas de ROM custom. Pour le support, j'ai moi aussi été déçu de cette décision.
Merci pour cette explication très claire. Du coup... ils ont un peu de retard ;)
Sur Android tu as la librairie de support qui apporte aux versions antérieures la compatibilité nécessaire, d'un point de vue Soft uniquement bien sur.
Et ? il y aura toujours des différences, dans ce cas, c'est à android de voir ce qui peut être afit pour un support minimal de 2 ou 3 ans, pendant lesquels une mise à jour de x niveau est assurée (version majeure, mineure, etc...). ex : pendant 1 ans, toutes les màj sont assurées, la 2nde année, une mise à jour majeure et toutes les màjs mineures, la 3ème année, une mise à jour importante et toutes les mises à jour de sécurité... (ce n'est qu'un ex, évidemment)
j'appellerait ça "jouer sur les mots", si une application veut profiter des nouvelles fonctions il doit faire appel à des APIs qui n'existent pas sur les anciennes versions, du coup, si les dév' veulent utiliser ces apis leurs apps ne seront plus compatibles avec les autres. Ce serait effectivement un petit prix à payer si on ne laissait pas sur le carreau autant de devices... à partir du moment où les mises à jours sont toujours aussi rare dans l'environnement Android (et je n'ai aps dit que c'était facile, c'est une constatation) soit il devrait y avoir un accord entre constructeur et android pour proposer une version nue et donc potentiellement facile à upgrader, soit le constructeur devrait s'engager à x années de mise à jour... Là ce n'est pas rassurant car depuis le début on nous dit que si on veux des mises à jours, il faut prendre un Nexus... raté...
Avec Android certaines fonctionnalités du BLE n'ont pas été intégrées, comme par exemple la fonctionnalité N°1 du BLE (le mode peripheral/central, le central agit comme un hub en gros), il n'y a que le mode client/server actuellement (qui n'autorise qu'une seule connexion). De plus, quand tu regardes dans l'API de Google, tu remarqueras que tu peux scanner les devices LE ou scanner les devices LE en fonction d'un identifiant de service (en somme, assez logique, vu que en LE tu cherches à te connecter à un service plus qu'à un device, hors cette méthode ne prends pas en comptes les UUID de service de plus de 16bits (en général des UUID de services connu en bluetooth, hors si tu veux créer ton propre service, c'est 128bits). L'API est encore jeune, mais j'aurais pensé qu'avec la version 4.4 ils auraient un peu amélioré les choses :)
Le soucis du Galaxy Nexus viendrait de son processeur qui ne serait plus maintenu. Un vieux TI OMAP.
J'ai pas trop compris la partie sur le BT LE. En quoi il est moins performant que sur iOS ?
Les API ne changent pas. Il y en a des nouvelles. C'est ce que l'on appelle stable justement.
Si je résume, pour avoir une meilleure expérience utilisateurs, les dév' devraient utiliser les nouvelles APIs. De fait, ces apis ne sont dispo QUE pour kitkat. Comme aujourd'hui seuls les derniers devices seront sous kitkat (et encore...) ou auront une mise à jour (même pas sûr), quelles probabilités que les dév' utiliseront ces apis ? sinon, combien d'utilisateurs seront mis sur la touche ? du coup, le principe de forcer une mise à jour sur TOUS les devices de moins de x années ne seraient pas totalement idiots... nan ? Perso, ça me donne envie d'attendre, android évolue très vite et les constructeurs très lentement, même une nexus de 2 ans, n'aura pas kitkat, comme quoi ce n'est pas un gage de màj... A quand une certaine stabilité chez Google ? de façon à ce que seule des modifications d'ordre cosmétiques soient apportées, mais que les apis ne changent pas ? là, j'hésitais à me prendre une nexus 7, mais je me dis que c'est une pas si bonne idée en fait... je vais devoir me débarrasser de ma "vieille" GT2 qui rame comme pas possible, alors que je ne l'utilise que peu... :( non, vraiment, cela me fait plus hésiter qu'autre chose... finalement, une bonne, ou une mauvaise nouvelle pour tout un chacun ?
API'S LEVEL IS OVER 9000
Gros point positif : Le Host Card Emulation :P Gros point negatif : Pas d'amélioration au niveau du bluetooth Low Energy :( , Android est donc toujours à la traine face à iOS sur ce point là ...
MP4 et FPS aucune idée
On pourrat donc filmer en quel qualiter les enregistrements d'ecrans ? Combien de fps et en quel format ?
SELinux (enforcing mode) Android 4.4 updates its SELinux configuration from "permissive" to "enforcing." This means potential policy violations within a SELinux domain that has an enforcing policy will be blocked. Ça c'est pas spécialement bon pour les bidouilleurs =)
Ce contenu est bloqué car vous n'avez pas accepté les cookies et autres traceurs. Ce contenu est fourni par Disqus.
Pour pouvoir le visualiser, vous devez accepter l'usage étant opéré par Disqus avec vos données qui pourront être utilisées pour les finalités suivantes : vous permettre de visualiser et de partager des contenus avec des médias sociaux, favoriser le développement et l'amélioration des produits d'Humanoid et de ses partenaires, vous afficher des publicités personnalisées par rapport à votre profil et activité, vous définir un profil publicitaire personnalisé, mesurer la performance des publicités et du contenu de ce site et mesurer l'audience de ce site (en savoir plus)
En cliquant sur « J’accepte tout », vous consentez aux finalités susmentionnées pour l’ensemble des cookies et autres traceurs déposés par Humanoid et ses partenaires.
Vous gardez la possibilité de retirer votre consentement à tout moment. Pour plus d’informations, nous vous invitons à prendre connaissance de notre Politique cookies.
Gérer mes choix