Désolé, je n'ai pas de réponse définitive à vous donner, mais j'ai quelques informations qui peuvent vous mettre sur la voie.
Vous pouvez utiliser diverses applications Apps2SD, TitaniumBackup ou le gestionnaire d'applications intégré pour déplacer certaines applications vers la partition de 10 Go. Les applications qui fonctionnent en permanence (processus d'arrière-plan, widgets, etc.) doivent rester sur la partition de 2 Go.
J'ai possédé 3 appareils Android et je me souviens avoir repartitionné l'un d'entre eux une fois, je crois que c'était le GT-P1000 en passant d'Android 1.x à 2.3. Je suivais un guide et je ne comprenais pas très bien ce que je faisais, je suivais juste les instructions étape par étape... Je sais que le repartitionnement était nécessaire car jusque là mes ROMs étaient toutes pour un système de fichiers basé sur RFS et je faisais la transition vers ext4 pour améliorer les performances du kernel. Je pense qu'ils ont également réduit /system (ROM) pour donner plus d'espace à /data (Apps).
Tout d'abord, familiarisez-vous avec XDA. Toutes les réponses dont j'ai eu besoin s'y trouvent. Je sais que tous les éléments nécessaires à la réalisation de votre projet s'y trouvent, mais peut-être pas rassemblés dans un seul fil de discussion. J'ai appris toutes ces choses au cours des 4 dernières années, et j'ai une expérience professionnelle en programmation et en administration de système depuis plus de 15 ans avant cela - il vous faudra peut-être un peu de temps pour tout assimiler.
Deuxièmement, oui, absolument, c'est possible Il n'est peut-être pas pratique. Vous pouvez soit modifier un fichier PIT, soit le faire avec fdisk via ADB en mode récupération.
Vous parlez de redimensionnement du NTFS, mais sachez que le format du système de fichiers est indépendant de votre table de partition. Dans le monde PC, vous pouvez avoir jusqu'à 4 partitions sur un disque dur, et vous pouvez mélanger FAT16, FAT32, NTFS sur chaque partition autant que vous le souhaitez. La première partition primaire se présente sous la forme C:\Npuis D:\Npuis les partitions logiques (Win9x et DOS ne supportaient qu'une seule partition primaire, les autres devaient être des partitions étendues avec 1 à 4 partitions logiques à l'intérieur de la partition étendue).
Le redimensionnement d'une partition n'entraîne pas le redimensionnement d'un système de fichiers. La plupart des outils de disque modernes effectuent les deux étapes en un seul clic, mais il s'agit tout de même de deux étapes. De plus, tous les systèmes de fichiers ne prennent pas en charge le redimensionnement, certains ne peuvent que croître, d'autres peuvent rétrécir et croître. Il existe également des outils tiers qui peuvent redimensionner des formats non redimensionnables (PartitionMagic).
Comme vous mentionnez NTFS, je présume que vous êtes un utilisateur de Windows, mais si vous êtes familier avec Unix (et donc Linux), il vous sera plus facile de suivre. Voici une traduction de haut niveau :
HardDisk1 (primary master) on a PC will show up as /dev/hda in Linux x86.
HardDisk2 (primary slave) is /dev/hdb
HD3 (secondary master) is /dev/hdc
HD4 (secondary slave) is /dev/hdd
SCSI, SATA and USB disks might be /dev/sda, /dev/sdb, ...
Les partitions sont subordonnées aux lecteurs :
HD1, Part1 = /dev/hda1
HD1, Part2 = /dev/hda2
HD1, Part3 = /dev/hda3
HD2, Part1 = /dev/hdb1
HD2, Part2 = /dev/hdb2
Ensuite, vous placez un système de fichiers sur vos partitions et vous les montez.
Fenêtres :
HD1,P1::NTFS, mounted as C:\
HD2,P1::ExFAT, mounted as D:\
Linux x86 :
/dev/hda1::ext3 mounted as /
/dev/hda2::JFS mounted as /usr
/dev/hdb1::ExFAT, mounted as /data
De plus, la table de partition contient un indice indiquant le type de système de fichiers, mais les deux ne correspondent pas toujours. Ce n'est pas parce que la table de partition indique que /dev/hdb1 est de type 0x07 que la table de fichiers est en réalité NTFS. Un bon système d'exploitation devrait comparer les deux et refuser de monter le système de fichiers, et un bon outil de formatage devrait mettre à jour la table de partition, mais pas toujours... Samsung ou Android sont connus pour attribuer des types de partition apparemment arbitraires pour indiquer la fonction plutôt que le système de fichiers. Je suis sûr qu'il y a une rime et une raison quelque part, mais je n'en ai aucune idée.
Android possède plusieurs partitions, les trois premières sont primaires, la quatrième est étendue et contient jusqu'à 30 partitions logiques. Chacune a une fonction spécifique et il existe de nombreuses FS différentes, certaines connues et d'autres propriétaires.
Le stockage intégré de 16 Go est équivalent au /dev/hda de x86, mais il s'appelle /dev/block/mmcblk0.
La première carte SD est /dev/mmcblk1 et ainsi de suite. Les partitions de chaque "disque" sont ...p1, ...p2, ...p3 et ainsi de suite.
Chaque fournisseur de produit et chaque appareil a son propre schéma de répartition des partitions.
Voir http://forum.xda-developers.com/showthread.php?t=1959445
Le i717 utilise le schéma suivant, je ne sais pas ce que tout signifie, mais j'en connais la majeure partie (j'ai obtenu cela en combinant "df" & "fdisk -l /dev/block/mmcblk0" d'Android et "heimdall print-pit" de MacOS en mode téléchargement) :
/dev/block/mmcblk0 <-- entire 16GB 'disk'
/dev/block/mmcblk0boot0 - ???
/dev/block/mmcblk0boot1 - ???
/dev/block/mmcblk0p1 - SMD_HDR - Primary boot loader
/dev/block/mmcblk0p2 - SBL1 - Secondary boot loader #1, your flash counter sits in here
/dev/block/mmcblk0p3 - SBL2
/dev/block/mmcblk0p4 - Extended Partition, container for the following logical partitions
/dev/block/mmcblk0p5 - RPM
/dev/block/mmcblk0p6 - SBL3
/dev/block/mmcblk0p7 - ABOOT
/dev/block/mmcblk0p8 - BOOT
/dev/block/mmcblk0p9 - TZ
/dev/block/mmcblk0p10 - SSD
/dev/block/mmcblk0p11 - PIT
/dev/block/mmcblk0p12 - PARAM
/dev/block/mmcblk0p13 - MODEM - 100MB /firmware vfat (baseband modem part 1)
/dev/block/mmcblk0p14 - MSM_ST1
/dev/block/mmcblk0p15 - MSM_ST2
/dev/block/mmcblk0p16 - MSM_FSG
/dev/block/mmcblk0p17 - 100MB /system/etc/firmware/misc_mdm vfat (modem part 2)
/dev/block/mmcblk0p18 - M9K_EFS1
/dev/block/mmcblk0p19 - M9K_EFS2
/dev/block/mmcblk0p20 - M9K_FSG
/dev/block/mmcblk0p21 - DEVENC - 10MB /efs ext4 - individual info like IMEI and Encryption
/dev/block/mmcblk0p22 - RECOVERY - 10MB - Recovery, ClockWorkMod or TWRP
/dev/block/mmcblk0p23 - FOTA
/dev/block/mmcblk0p24 - SYSTEM - 1GB /system ext4
/dev/block/mmcblk0p25 - USERDATA - 2GB /data ext4
/dev/block/mmcblk0p26 - CACHE - 300 MB /cache
/dev/block/mmcblk0p27 - TOMBSTONES - crash dump area?
/dev/block/mmcblk0p28 - UMS 10GB /sdcard user's playground (usually a vold virtual device)
Ainsi, votre partition de 2 Go est /dev/block/mmcblk0p25 et votre partition de 10 Go est /dev/block/mmcblk0p28.
Faire ce que vous voulez tout en préservant les données n'est pas vraiment possible, mais j'ai déjà fait quelque chose de similaire sur x86 comme suit :
first you have to shrink the filesystem on /dev/block/mmcblk0p28,
then shrink the partition,
then move the partition to the end of the disk,
then move p27 to end just before p28 starts,
move p26 to butt up against p27,
grow partition p25 to fill the empty space in front on p26,
then extended filesystem on p25 to fill the partition...
En réalité, il n'existe pas d'outils facilement disponibles pour faire tout cela. Une méthode plus pratique :
1 You'll have to back up the contents of p25, p26, p27 and p28 to external SD,
2 rebuild the partition table with the new boundaries,
3 create new filesystems on each,
4 then restore data onto each.
Il s'agit en fait d'une réinitialisation d'usine, la ROM devrait rester intacte. Si je devais le faire, je le ferais :
0 insert a brand new 32GB sd card into the note
1 boot to recovery
2 connect with adb shell
3 mount /dev/block/mmcblk1p1 to /external_sd
4 mount /dev/block/mmcblk0p25 to /data
5 mount /dev/block/mmcblk0p28 to /sdcard
6 tar /data to /external_sd/data.tar
7 tar /sdcard to /external_sd/sdcard.tar
8 unmount /data and /sdcard
9 use fdisk to rebuild partitions p25, p26, p27 & p28 where p25 is bigger, p26 & p27 are moved and p28 is smaller
10 make new filesystems on all four p25-p28
11 mount /data and /sdcard again
12 untar /external_sd/data.tar to /data
13 untar /external_sd/sdcard.tar to /sdcard
14 pray
15 reboot
Voici la table de partition complète :
~ # fdisk -ul /dev/block/mmcblk0
Disk /dev/block/mmcblk0: 15.7 GB, 15758000128 bytes
1 heads, 16 sectors/track, 1923584 cylinders, total 30777344 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 204800 102400 92 Unknown
Partition 1 does not end on cylinder boundary
/dev/block/mmcblk0p2 * 204801 205800 500 4d Unknown
Partition 2 does not end on cylinder boundary
/dev/block/mmcblk0p3 205801 208800 1500 51 Unknown
Partition 3 does not end on cylinder boundary
/dev/block/mmcblk0p4 208801 30777343 15284271+ 5 Extended
Partition 4 does not end on cylinder boundary
/dev/block/mmcblk0p5 212992 213991 500 47 Unknown
/dev/block/mmcblk0p6 221184 225279 2048 45 Unknown
/dev/block/mmcblk0p7 229376 234375 2500 4c Unknown
/dev/block/mmcblk0p8 237568 258047 10240 48 Unknown
/dev/block/mmcblk0p9 262144 263143 500 46 Unknown
/dev/block/mmcblk0p10 270336 271335 500 5d Unknown
/dev/block/mmcblk0p11 278528 279527 500 91 Unknown
/dev/block/mmcblk0p12 286720 307199 10240 93 Unknown
/dev/block/mmcblk0p13 311296 511999 100352 c Win95 FAT32 (LBA)
/dev/block/mmcblk0p14 516096 522239 3072 4a Unknown
/dev/block/mmcblk0p15 524288 530431 3072 4b Unknown
/dev/block/mmcblk0p16 532480 538623 3072 58 Unknown
/dev/block/mmcblk0p17 540672 741375 100352 8f Unknown
/dev/block/mmcblk0p18 745472 751615 3072 59 Unknown
/dev/block/mmcblk0p19 753664 759807 3072 5a Unknown
/dev/block/mmcblk0p20 761856 767999 3072 5b Unknown
/dev/block/mmcblk0p21 770048 790527 10240 ab Darwin boot
/dev/block/mmcblk0p22 794624 815103 10240 60 Unknown
/dev/block/mmcblk0p23 819200 839679 10240 94 Unknown
/dev/block/mmcblk0p24 843776 2940927 1048576 a5 FreeBSD
/dev/block/mmcblk0p25 2940928 7139327 2099200 a6 OpenBSD
/dev/block/mmcblk0p26 7143424 7761919 309248 a8 Darwin UFS
/dev/block/mmcblk0p27 7766016 8030207 132096 a9 NetBSD
/dev/block/mmcblk0p28 8036352 30777343 11370496 90 Unknown
J'allais décrire ce que vous pourriez faire avec fdisk, mais je vois que la table de partition existante laisse des espaces inégaux entre chaque partition - cela me dérange parce que je ne sais pas pourquoi. Traditionnellement, sur un disque, vous créeriez chaque partition en commençant 1 secteur après la précédente. Cependant, la taille des partitions est toujours alignée sur les limites des cylindres, donc peut-être que chaque nouvelle partition commence sur une limite (multiples de puissances de 2 ?) même si la partition précédente ne se termine pas sur une limite ? ?? Les espaces sont tous (multiples de 1024) plus 1, mais jusqu'à ce que je sache quelle est la règle pour créer un espace, je ne toucherais pas aux partitions... Est-ce que cela signifie que je peux agrandir la partition précédente de 1024, 2048, 3192, 4096, ... blocs ? Est-ce que le système utilise sournoisement cet espace vide à des fins non documentées ? qui sait ?
Sidebar : Vous demandez si l'installation de CyanogenMod aiderait ou si c'est plus bas. Les partitions sont à peu près aussi basses que possible, il y a les chargeurs de démarrage, le noyau, la ROM (Cyanogen, ParanoidAndroid, etc.), puis l'espace utilisateur comme /data, /sdcard et /external_sd. Le démarrage en mode de récupération est un peu comme le démarrage d'une image LiveCD d'un système d'exploitation sans disque où l'ensemble du système est chargé dans la RAM. De cette manière, vous pouvez faire ce que vous voulez sur le disque dur : sauvegarder, formater, partitionner, restaurer, redimensionner, disséquer, cloner, etc. ; ensuite, tant que vous avez tout remis en place correctement, vous pouvez redémarrer dans votre système d'exploitation d'origine.
Quant à la raison pour laquelle Samsung a choisi cette limite arbitraire de 2 Go, il s'agit d'une question de compatibilité ascendante datant de l'époque où les puces de mémoire de 2 Go étaient les plus grandes que l'on pouvait obtenir, et dans un appareil, il y avait 2 puces de 2 Go. La première puce avait des partitions pour les chargeurs de démarrage, le noyau, Root(/), /usr et la ROM /system - et était en LECTURE SEULE du système d'exploitation en cours d'exécution pour empêcher les utilisateurs de casser l'appareil ; la deuxième puce était montée en LECTURE / LARGE sur /data pour permettre aux utilisateurs d'installer des applications et des paramètres. C'était l'Android de base utilisant le stockage intégré. Si vous vouliez plus d'espace, vous pouviez utiliser une carte SD que vous placiez dans un emplacement, et qui était montée sur /sdcard. Lorsque les puces sont devenues plus grandes et moins chères, Samsung est resté fidèle à la conception de base et vous a donné 12 Go (10 utilisables) de stockage interne en le présentant comme /sdcard, puis ils ont ajouté le stockage externe et ont créé /external_sd. Cela a causé beaucoup de confusion, et certaines ROMs montaient la carte SD externe comme /sdcard et montaient les 12GB comme quelque chose d'autre comme /emmc. Sauter des ROMs à l'époque était pénible si vous échangiez entre des développeurs qui suivaient des paradigmes différents. Aujourd'hui, c'est devenu plus standard avec /storage/sdcard0, sdcard1, etc. et les applications sont conçues dans cette optique, laissant les utilisateurs choisir la carte SD à utiliser plutôt que de supposer que /sdcard ou /emmc existent sous la bonne forme.
Dans l'ensemble, je suis d'accord que 2GB est trop petit pour /data, je suis constamment en train de déplacer des applications vers SD et d'intégrer les mises à jour de google app dans la ROM. Je ne pense pas que j'irais jusqu'à l'égalité, et je sais que je ne les combinerais pas en un seul gros /data et que je n'aurais qu'une carte SD externe comme /sdcard - à l'ancienne... Peut-être 4 Go pour /data et 8 Go pour /sdcard...
Quoi qu'il en soit, bonne chance.
