Les OS de smartphones devraient être rayés de la carte

Le 16 mai 2024 à 18:50:40 :

Le 16 mai 2024 à 18:47:39 :

Le 16 mai 2024 à 18:45:33 :

Le 16 mai 2024 à 18:44:00 :

Le 16 mai 2024 à 18:42:00 :

> Le 16 mai 2024 à 18:41:21 :

>

> Liste des partitions sur le disque numéro 4 d'une puce Qualcomm

La moitié est vide, mais est quand même présente

Et pour rappel, c'est une seule des 6 mémoires flashs sur un appareil

Il y a aussi le fait qu'il n'y ait pas de normes unifiées pour la communication matériel, chaque constructeur fait ce qu'il veut et ce n'est généralement même pas documenté, du coup pour ceux qui veulent booter sur autre chose, il faut souvent rétro-ingénier

En vrai si, toute la communication matérielle se fait depuis le noyau, et t'as juste à charger un fichier dtb, mais c 'est pas grâce à Android ça, mais juste linux
En gros dans ton boot android, tu as le noyau linux modifié + un fichier dtb qui décrire les adresses pour accéder au hardware et à quoi ça correspond + un executable pour charger le reste du système

Ok, personnellement j'ai jamais tenté de booter sur autre chose sur Android car j'ai pas envie d'introduire des bugs et que j'en ai pas énormément l'utilité (j'utilise RDP et ça me convient), je sais que c'est plus compliqué que sur les interfaces PC et pas spécialement prévu pour (sur de nombreux smartphones)

Mais les constructeurs n'essayent pas d'obfusquer encore plus le fonctionnement des blobs pour rendre compliqué la tâche de booter sur autre chose que leur surcouche Android ? Il y a des forums où ils sont obligés de rétroingénier

Même quand les constructeurs sont ultra ouverts et te donnent tous les fichiers pour flasher, tu peux pas aller plus loin que de flasher le boot.img et la partition principale (si les constructeurs ont choisi de désactiver la vérification de signature au niveau de abl). Donc tu peux mettre linux ou un os custom dessus MAIS, tu ne peux pas modifier le bootloader et l'environnement d'execution TEE de l'appareil. Car le premier bootloader est physiquement pas modifiable, et vérifie la signature de ce que t'as flashé avant de le charger
Seul Qualcomm dispose de la clé privée pour générer cette signature et flasher ce que tu veux

Le 14 mai 2024 à 12:09:41 :
Essaye de configurer un serveur sous Android

Pourquoi tu voudrais configurer un serveur sous android ?

Le 16 mai 2024 à 18:55:28 :

Le 16 mai 2024 à 18:50:40 :

Le 16 mai 2024 à 18:47:39 :

Le 16 mai 2024 à 18:45:33 :

Le 16 mai 2024 à 18:44:00 :

> Le 16 mai 2024 à 18:42:00 :

>> Le 16 mai 2024 à 18:41:21 :

> >

> > Liste des partitions sur le disque numéro 4 d'une puce Qualcomm

>

> La moitié est vide, mais est quand même présente

Et pour rappel, c'est une seule des 6 mémoires flashs sur un appareil

Il y a aussi le fait qu'il n'y ait pas de normes unifiées pour la communication matériel, chaque constructeur fait ce qu'il veut et ce n'est généralement même pas documenté, du coup pour ceux qui veulent booter sur autre chose, il faut souvent rétro-ingénier

En vrai si, toute la communication matérielle se fait depuis le noyau, et t'as juste à charger un fichier dtb, mais c 'est pas grâce à Android ça, mais juste linux
En gros dans ton boot android, tu as le noyau linux modifié + un fichier dtb qui décrire les adresses pour accéder au hardware et à quoi ça correspond + un executable pour charger le reste du système

Ok, personnellement j'ai jamais tenté de booter sur autre chose sur Android car j'ai pas envie d'introduire des bugs et que j'en ai pas énormément l'utilité (j'utilise RDP et ça me convient), je sais que c'est plus compliqué que sur les interfaces PC et pas spécialement prévu pour (sur de nombreux smartphones)

Mais les constructeurs n'essayent pas d'obfusquer encore plus le fonctionnement des blobs pour rendre compliqué la tâche de booter sur autre chose que leur surcouche Android ? Il y a des forums où ils sont obligés de rétroingénier

Même quand les constructeurs sont ultra ouverts et te donnent tous les fichiers pour flasher, tu peux pas aller plus loin que de flasher le boot.img et la partition principale (si les constructeurs ont choisi de désactiver la vérification de signature au niveau de abl). Donc tu peux mettre linux ou un os custom dessus MAIS, tu ne peux pas modifier le bootloader et l'environnement d'execution TEE de l'appareil. Car le premier bootloader est physiquement pas modifiable, et vérifie la signature de ce que t'as flashé avant de le charger
Seul Qualcomm dispose de la clé privée pour générer cette signature et flasher ce que tu veux

Vivement que le matériel libre débarque en force : RISC-V, LibreBoot, etc.

C'est ahurissant à quel point les smartphones sont limités, intolérable même

Le 16 mai 2024 à 18:57:56 :

Le 16 mai 2024 à 18:55:28 :

Le 16 mai 2024 à 18:50:40 :

Le 16 mai 2024 à 18:47:39 :

Le 16 mai 2024 à 18:45:33 :

> Le 16 mai 2024 à 18:44:00 :

>> Le 16 mai 2024 à 18:42:00 :

> >> Le 16 mai 2024 à 18:41:21 :

> > >

> > > Liste des partitions sur le disque numéro 4 d'une puce Qualcomm

> >

> > La moitié est vide, mais est quand même présente

>

> Et pour rappel, c'est une seule des 6 mémoires flashs sur un appareil

Il y a aussi le fait qu'il n'y ait pas de normes unifiées pour la communication matériel, chaque constructeur fait ce qu'il veut et ce n'est généralement même pas documenté, du coup pour ceux qui veulent booter sur autre chose, il faut souvent rétro-ingénier

En vrai si, toute la communication matérielle se fait depuis le noyau, et t'as juste à charger un fichier dtb, mais c 'est pas grâce à Android ça, mais juste linux
En gros dans ton boot android, tu as le noyau linux modifié + un fichier dtb qui décrire les adresses pour accéder au hardware et à quoi ça correspond + un executable pour charger le reste du système

Ok, personnellement j'ai jamais tenté de booter sur autre chose sur Android car j'ai pas envie d'introduire des bugs et que j'en ai pas énormément l'utilité (j'utilise RDP et ça me convient), je sais que c'est plus compliqué que sur les interfaces PC et pas spécialement prévu pour (sur de nombreux smartphones)

Mais les constructeurs n'essayent pas d'obfusquer encore plus le fonctionnement des blobs pour rendre compliqué la tâche de booter sur autre chose que leur surcouche Android ? Il y a des forums où ils sont obligés de rétroingénier

Même quand les constructeurs sont ultra ouverts et te donnent tous les fichiers pour flasher, tu peux pas aller plus loin que de flasher le boot.img et la partition principale (si les constructeurs ont choisi de désactiver la vérification de signature au niveau de abl). Donc tu peux mettre linux ou un os custom dessus MAIS, tu ne peux pas modifier le bootloader et l'environnement d'execution TEE de l'appareil. Car le premier bootloader est physiquement pas modifiable, et vérifie la signature de ce que t'as flashé avant de le charger
Seul Qualcomm dispose de la clé privée pour générer cette signature et flasher ce que tu veux

Vivement que le matériel libre débarque en force : RISC-V, LibreBoot, etc.

C'est ahurissant à quel point les smartphones sont limités

RISC-V n'atteindra pas la puissance d'ARM avant 10-20 ans malheureusement :'(

Le 16 mai 2024 à 18:59:32 :

Le 16 mai 2024 à 18:57:56 :

Le 16 mai 2024 à 18:55:28 :

Le 16 mai 2024 à 18:50:40 :

Le 16 mai 2024 à 18:47:39 :

> Le 16 mai 2024 à 18:45:33 :

>> Le 16 mai 2024 à 18:44:00 :

> >> Le 16 mai 2024 à 18:42:00 :

> > >> Le 16 mai 2024 à 18:41:21 :

> > > >

> > > > Liste des partitions sur le disque numéro 4 d'une puce Qualcomm

> > >

> > > La moitié est vide, mais est quand même présente

> >

> > Et pour rappel, c'est une seule des 6 mémoires flashs sur un appareil

>

> Il y a aussi le fait qu'il n'y ait pas de normes unifiées pour la communication matériel, chaque constructeur fait ce qu'il veut et ce n'est généralement même pas documenté, du coup pour ceux qui veulent booter sur autre chose, il faut souvent rétro-ingénier

En vrai si, toute la communication matérielle se fait depuis le noyau, et t'as juste à charger un fichier dtb, mais c 'est pas grâce à Android ça, mais juste linux
En gros dans ton boot android, tu as le noyau linux modifié + un fichier dtb qui décrire les adresses pour accéder au hardware et à quoi ça correspond + un executable pour charger le reste du système

Ok, personnellement j'ai jamais tenté de booter sur autre chose sur Android car j'ai pas envie d'introduire des bugs et que j'en ai pas énormément l'utilité (j'utilise RDP et ça me convient), je sais que c'est plus compliqué que sur les interfaces PC et pas spécialement prévu pour (sur de nombreux smartphones)

Mais les constructeurs n'essayent pas d'obfusquer encore plus le fonctionnement des blobs pour rendre compliqué la tâche de booter sur autre chose que leur surcouche Android ? Il y a des forums où ils sont obligés de rétroingénier

Même quand les constructeurs sont ultra ouverts et te donnent tous les fichiers pour flasher, tu peux pas aller plus loin que de flasher le boot.img et la partition principale (si les constructeurs ont choisi de désactiver la vérification de signature au niveau de abl). Donc tu peux mettre linux ou un os custom dessus MAIS, tu ne peux pas modifier le bootloader et l'environnement d'execution TEE de l'appareil. Car le premier bootloader est physiquement pas modifiable, et vérifie la signature de ce que t'as flashé avant de le charger
Seul Qualcomm dispose de la clé privée pour générer cette signature et flasher ce que tu veux

Vivement que le matériel libre débarque en force : RISC-V, LibreBoot, etc.

C'est ahurissant à quel point les smartphones sont limités

RISC-V n'atteindra pas la puissance d'ARM avant 10-20 ans malheureusement :'(

C'est toujours le plus gros problème des solutions open source, elles ont souvent un train de retard

Le 16 mai 2024 à 18:56:29 :
Sinon t'as le windows phone qui embarque windows

Windows Phone est pourri aussi

Le 16 mai 2024 à 18:57:24 :

Le 14 mai 2024 à 12:09:41 :
Essaye de configurer un serveur sous Android

Pourquoi tu voudrais configurer un serveur sous android ?

Configurer un serveur distant

Le 16 mai 2024 à 19:01:19 :

Le 16 mai 2024 à 18:56:29 :
Sinon t'as le windows phone qui embarque windows

Windows Phone est pourri aussi

Le 16 mai 2024 à 18:57:24 :

Le 14 mai 2024 à 12:09:41 :
Essaye de configurer un serveur sous Android

Pourquoi tu voudrais configurer un serveur sous android ?

Configurer un serveur distant

Mais t'as d'autres solutions pour configurer un serveur distant, pourquoi tu veux absolument que ce soit android ?

Le 16 mai 2024 à 19:02:14 :

Le 16 mai 2024 à 19:01:19 :

Le 16 mai 2024 à 18:56:29 :
Sinon t'as le windows phone qui embarque windows

Windows Phone est pourri aussi

Le 16 mai 2024 à 18:57:24 :

Le 14 mai 2024 à 12:09:41 :
Essaye de configurer un serveur sous Android

Pourquoi tu voudrais configurer un serveur sous android ?

Configurer un serveur distant

Mais t'as d'autres solutions pour configurer un serveur distant, pourquoi tu veux absolument que ce soit android ?

Android est pourri, on ne peut rien faire dessus, c'est juste un OS golémique qui sert à regarder des TikTok, donc, pas pour moi

J'utilise Windows en RDP quand je suis sur smartphone, la preuve que le problème n'est pas la taille de l'écran, mais bien qu'une direction golémique a été prise dans ce genre de technologies

Le 16 mai 2024 à 18:55:19 :
j'ai pouffé de rire en voyant le retour de antoineplay, les topics ou il vient faire l'expert puis attire des mecs vraiment expert et se fait terminer

Ils sont d'accord, le golem

Le 16 mai 2024 à 18:30:47 :
Je suis 100% d'accord avec l'OP, Android est une horreur over-engineered et t'empêche de faire la moindre manipulation. Impossible de dev une app qui utilise des fonctionnalités systèmes. Obligé de décompiler/récompiler le framework pour faire ça . Impossible de lancer 2 activités en même temps sans aussi devoir retoucher au code source .
La putin de sandbox Dalvik/ART qui plombe les performances
Les signatures partout qui t'empêchent de faire la moindre bidouille
Mais avec un accès root, c'est un parcours du combattant pour faire la moindre modification à l'OS
Les fichiers systèmes sont dans une partition à part et non modifiables (sauf si tu rajoutes un overlay, mais c'est vraiment moyen)
Devoir se trimbaler une JavaVM partout dans le code natif
Tous les logiciels doivent avoir une case spécifique à android où tu as un cas spécifique Android, tout ça pour gérer cette machine virtuelle Java de merde
Les permissions qui cassent les couilles, le pire c'est qu'elles sont juste check manuellement dans le framework, c'est littéralement un appel d'API avec un if (granted) continue, des reflections java et ça peut se contourner
Des mécanismes IPC avec les pires performances au monde, AIDL au lieu de juste faire des sockets, signaux, de la mémoire partagée (même si c'est possible, faut très bien chercher pour les trouver, Android te montre que AIDL)
Le système de fichiers WTF avec 100 partitions sur 6 disques différents dont 80 qui servent avant même que le noyau linux soit chargé. En gros la première partition vérifie la 2ème et sa signature, puis la charge, et la 2ème fait idem avec la 3ème, et ce processus doit avoir lieu 6 fois au moins, en prenant en compte qu'il existe un TEE en dehors du noyau pour Qualcomm, tellement c'est pas sécurisé
Le vieux noyau linux

Le 16 mai 2024 à 18:55:19 :
j'ai pouffé de rire en voyant le retour de antoineplay, les topics ou il vient faire l'expert puis attire des mecs vraiment expert et se fait terminer

Ils sont d'accord, le golem

Le 16 mai 2024 à 18:30:47 :
Je suis 100% d'accord avec l'OP, Android est une horreur over-engineered et t'empêche de faire la moindre manipulation. Impossible de dev une app qui utilise des fonctionnalités systèmes. Obligé de décompiler/récompiler le framework pour faire ça . Impossible de lancer 2 activités en même temps sans aussi devoir retoucher au code source .
La putin de sandbox Dalvik/ART qui plombe les performances
Les signatures partout qui t'empêchent de faire la moindre bidouille
Mais avec un accès root, c'est un parcours du combattant pour faire la moindre modification à l'OS
Les fichiers systèmes sont dans une partition à part et non modifiables (sauf si tu rajoutes un overlay, mais c'est vraiment moyen)
Devoir se trimbaler une JavaVM partout dans le code natif
Tous les logiciels doivent avoir une case spécifique à android où tu as un cas spécifique Android, tout ça pour gérer cette machine virtuelle Java de merde
Les permissions qui cassent les couilles, le pire c'est qu'elles sont juste check manuellement dans le framework, c'est littéralement un appel d'API avec un if (granted) continue, des reflections java et ça peut se contourner
Des mécanismes IPC avec les pires performances au monde, AIDL au lieu de juste faire des sockets, signaux, de la mémoire partagée (même si c'est possible, faut très bien chercher pour les trouver, Android te montre que AIDL)
Le système de fichiers WTF avec 100 partitions sur 6 disques différents dont 80 qui servent avant même que le noyau linux soit chargé. En gros la première partition vérifie la 2ème et sa signature, puis la charge, et la 2ème fait idem avec la 3ème, et ce processus doit avoir lieu 6 fois au moins, en prenant en compte qu'il existe un TEE en dehors du noyau pour Qualcomm, tellement c'est pas sécurisé
Le vieux noyau linux

Et puis je rajouterais aussi : l'interface

Il y a aussi un autre gros problème, qui s'est d'ailleurs étendu aux PC désormais, l'absence de bouton kill switch

Avant, les choses étaient simples, il y avait un système mécanique ON / OFF pour couper le circuit d'un appareil

Plus maintenant, et ce n'est pas une question de modernisme, mais de stupidité pure et simple

Désormais, les systèmes golémiques exigent que cela passe par un microcontrôleur, où il faut appuyer plusieurs secondes sur un bouton, etc.

Perte d'ergonomie et de sécurité, quand je veux éteindre un PC directement, je veux qu'il s'éteigne immédiatement, sans avoir à appuyer plusieurs secondes, et bien évidemment la même chose pour un smartphone

Ce n'est pas des smartphones, mais des dumbphones

Ils sont conçus précisément dans l'optique d'aliéner toujours plus leurs utilisateurs, en la matière, iOS est chef de course