CyanogenMod + X / SpicagenMod + X

[davandroid]

tu as testé celle de sofien ? ou mon onepackage ? :P

Message envoyé avec l'application Forum Frandroid

[BHMath76]

Oui en 2.1 !

[droid19]

Oui en 2.1 !

+1

Perso, j'ai aucun complexe avec ma ROM qui tourne depuis .... euh je n'sais plus quand x)

Je pete pas les scores à Quadrant mais je flash pas toutes les semaines, aucuns bugs/freeeeeeezzzz/reboot/SOD/ et j'en passe.

Un saut dans le temps?

Si tu veux demain je peux t'uploader ma ROM 2.1_all_in_one (2.1+FE9+3D+ thème perso)

[Obiwane]

j'ai testé celle de Sofien , bien ! par contre j'accroche pas le nouveau thème , du coup je suis repassé a la "cyanogen mod 6.1.1 8.4 kernel yonip 22b à suivre !

[davandroid]

oula kernel 22b...c'est pas les plus stables les .32...

[Obiwane]

tu me conseilles le quel ?

[thegreatflash]

sinon tu peux toujours essayer la rom Miui V4 de sofien le thème est bien mieux à mon gout que sa dernière en date, rom stable, fluide, propre, et pas trop gourmande.

[pkseb]

J'ai installé cette rom elle est très fluide, réactive cependant j'ai de gros problèmes avec plus moyen de me connecter en wifi ! le spica détecte ma box - recheche...-puis déconnecté, j'ai éssayé plusieurs kitchen idem

autre souci je n'arrive plus a démarrer le spica quand il est éteint avec la touche raccrocher ! pour le demarrer je dois soit enlever la batterie et quand je la remets il démarre tout seul ou le rebrancher sur le secteur

quand il est éteint je n'arrive plus a passer en mode download pour refaire une install propre !

par moment il s'éteint et redemarre tout seul !

cette rom est excellente merci à voku pour son travail j'aurais jamais cru avoir une rom de cette trempe sur le spica, j'ai hate de pouvoir faire une install propre et d'en profiter correctement

[LordManta]

Salut,

juste une remarque relatif à la plupart des ROMs distribuées actuellement et la Voku que j'utilise actuellement n'échappe pas à la règle...

Il me semble qu'un certain nombre d'éléments installés par ces roms soient en fait placés sur la partition data au moment de l'install. En particulier il s'agit souvent de library natives (les lib*.so) qui accompagnent les applis préinstallées. Sans ces library accessibles, nombre d'applications préinstallées ne peuvent plus fonctionner (QuickPic, OperaMini, ...). Dans une installation standard, ces library sont installées normalement par le package manager d'android qui en fait les extrait des apk elles-mêmes au cours de l'installation.

La procédure d'installation proposée par les différentes ROM, marche assez bien en général mais voilà en général toujours elle se solde par l'impossibilité par la suite de faire un Wipe data & cache sur ces roms car bien souvent les éléments à installer ont étés effacés.

Donc plutôt que de copier des library.so dans la partition /data alors que les library sont présentes dans les apks installées (par exemple dans system/app), je pense qu'il serait plus pertinent d'extraire les lib.so "à la volée" pendant les reboot du system.

J'ai cherché un moyen pour extraire les library en transformant les scripts existant et pour le moment je n'ai rien trouvé. Si quelqu'un a une solution je suis preneur (zip ne fonctionne apparemment pas avec les apks sous Android en tout cas pas complètement avec les apks zipallignés...).

Pour faire une preuve de concept j'ai donc écrit en java un petit utilitaire pour disposer d'un tel outil :

/*
* unzuping command line utility
* by LordManta
*/
package jfs.util.zip;

import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.util.zip.ZipFile;
import java.util.zip.ZipEntry;
import java.io.InputStream;
import java.util.Enumeration;
import java.util.Vector;

public class Zipper
{
 public static void main(final String args[]){
   if(args.length < 2){
     usageMessage();
     System.exit(1);
   }
   try{
     final ZipFile zipFile = new ZipFile(args[1]);
     final Enumeration<? extends ZipEntry> files = zipFile.entries();
     if(args[0].equals("list")){
System.out.println("Inspecting archive "+args[1]+":");
while(files.hasMoreElements()){
  final String fileName = files.nextElement().getName();
  if(args.length > 2){
    if(fileName.contains(args[2])){
      System.out.println(fileName);
    }
  }
  else{
    System.out.println(fileName);
  }
}
     }
     else if(args[0].equals("extract")){
if(args.length < 3){
   usageMessage();
   System.exit(1);
}
System.out.println("Extracting archive "+args[1]+" into "+args[2]+":");
Vector<String> namesToExtract = new Vector<String>();
if(args.length > 2){
  for(int i = 3; i < args.length; i++){
    namesToExtract.add(args[i]);
  }
}
       while(files.hasMoreElements()){
         final ZipEntry fileEntry = files.nextElement();
  final String fileName = fileEntry.getName();
  if((namesToExtract.size() > 0) && (!namesToExtract.contains(fileName))){
    continue;
  }
         System.out.println("Extratcting "+fileName);
         checkDir(args[2]+"/"+fileName);
         if(!fileEntry.isDirectory()){
    final byte buffer[] = new byte[4096];
           final FileOutputStream extraction = new FileOutputStream(args[2]+"/"+fileName);
    final InputStream zipIn = zipFile.getInputStream(fileEntry);
           for(int c = zipIn.read(buffer); c != -1; c = zipIn.read(buffer)){
             extraction.write(buffer,0,c);
           }
    zipIn.close();
           extraction.close();
         }
       }
       zipFile.close();
     }
   }
   catch(Exception e){
     e.printStackTrace();
   }
 }
 private static void checkDir(final String name){
   final File f = new File(name);
   if(!f.isDirectory()){
     f.getParentFile().mkdirs();
   }
 }
 private static void usageMessage(){
   System.out.println("Usage: zipper list archiveFile [filter]");
   System.out.println("Usage: zipper extract archiveFile destinationDir [filesToExtract]");
   System.exit(1);
 }
}

en cas de besoin voici la procédure de compilation :

javac jfs/util/zip/Zipper.java
dx --dex --output=classes.dex jfs/util/zip/Zipper.class
rm -f zipper.jar
aapt add zipper.jar classes.dex
rm classes.dex
rm jfs/util/zip/Zipper.class

et un petit script pour peaufiner la commande :

#! /system/bin/sh
# by LordManta

/system/bin/dalvikvm -cp /system/xbin/zipper.jar jfs.util.zip.Zipper $@

#EOF

dès lors la commande me permet après modification du script de second boot (pour la voku) d'extraire automatiquement les library des apks de system/app et de les installer au bon endroit. Ma modification de la voku fonctionne et me permet de résister au Wipe data & cache car plus rien n'est placé dans data ;-).

C'est très largement perfectible mais si ça peut contribuer ...

[khancyr]

J'ai pas compris le probleme de base....le wipe data/cache , c'est un reset , donc c'est normal que tout soit effacer et revienne comme a l'installation de la Rom.Je comprend pas a quoi sert ton programme?

[LordManta]

Un partie de l'install de la ROM est faite dans la partition DATA. Après un Wipe Data & Cache la partition DATA est reformatée. Donc, on ne retourne pas à une situation "comme à l'installation de la Rom" puisque la partie data n'existe plus.

En particulier les library natives des apks ajoutées dans system/app ne sont plus disponibles. Ce que je propose c'est de modifier les roms actuelles pour éviter l'utilisation de la partition data en extrayant directement les libs natives des apks correspondantes, comme ça pas de soucis, on a pas besoin de copier quoique ce soit dans /data pour l'install de la rom dans le recovery...

Modifié 25 juillet 2011 par LordManta

[Sofien31]

je crois comprendre ce que tu veux faire, en gros tu veux "déplacer" toutes les librairies ailleurs que dans la partition data pour éviter qu'elles ne soient "perdues" après un wipe data cache... non?

le problème, c'est que très peu d'applications contiennent des libraires exclusives à elles... et que pour par exemple passer d'une cyanogen 6 à une 7, il faut détruire les libraires pré-enregistré par la cyanogen 6 en faisant un wipe data cache, si, avec ta technique, on déplace toutes ces libraires dans une partition externe, on fait comment pour les remplacer par celle de la 7?

Puis en cas de problème avec des libraires corrompus, si on ne peux pas faire de wipe data cache pour s'en défaire, on fait comment autrement?

Modifié 26 juillet 2011 par Sofien

[LordManta]

oui je pense que tu as bien compris ce dont je parle mais je ne comprends pas bien ton objection à propos du passage de CM6 à 7. Car dans ce dernier cas tu refais une install complète donc ma modif n'intervient plus puisque en général on fait un Wipe Data & Cache et l'install re-formate la partition system.

Le problème c'est ce qui se passe en cas de Wipe Data & Cache et que l'on ne met pas à jour le système, on veut garder la même ROM.

En installant les librarys de lib.so dans /data au moment de l'install via le recovery, on s'interdit de pouvoir faire un Wipe Data & Cache plus tard...

Ce que je propose c'est de supprimer l'utilisation de data (qui sert principalement à stocker temporairement les lib.so des applis préinstalées dans /system/app). Ça peut se faire en extrayant directement au cours de l'exécution du script secondboot (pour la voku) les libs directement des apks.

voici un exemple de documentation :

# QuickPic install
PREF_FOLDER="/data/data/com.alensw.PicFolder"
APP_APK="/system/app/PictFolder.apk"
if [ -e "$PREF_FOLDER" ];
then
   echo "--- Settings for QuickPic";
   echo "extracting from $APP_APK to $PREF_FOLDER/lib"
   /system/xbin/jfs_ziptool extract "$APP_APK" "$PREF_FOLDER" lib/armeabi/libqpicjni4.so;
   mv "$PREF_FOLDER"/lib/armeabi/* "$PREF_FOLDER"/lib/
   rmdir "$PREF_FOLDER"/lib/armeabi/
   chown system:system "$PREF_FOLDER"/lib/*
   chmod 755 "$PREF_FOLDER"/lib/*
fi;

mais je suis en train de modifier le script en question pour retrouver automatiquement les library à installer.

Par exemple pour QuickPic où le nom de la library à extraire change de version en version...

Cerise sur le gateau le zip d'install est moins gros ;-).

PS: ça ne s'applique pas à ta ROM visiblement Sofien ;-).

Modifié 26 juillet 2011 par LordManta

[delavega]

Salut, c'est juste pour vous dire que j'ai laissé tomber les ROM Voku au profit d'une NextGeneration 5.3 (c'est du Yonip 22B).

Sur les Voku, la consommation de batterie est en effet catastrophique (en tout cas sur mon Spica) et ne vient pas du kernel, vu que j'ai essayé avec tout les .29 de la Voku kitchen ! Concrètement, mon Spica tenait une douzaine d'heures maxi en ne faisant strictement rien dessus, même pas téléphoner.

J'ai donc cherché quelles applis pouvaient provoquer une telle surconsommation. Comme mon installation est super minimaliste : adfree, aucun jeu, aucun task killer, aucune activtié facebook, je n'ai rien trouvé qui puisse justifier de cela. A un moment, j'ai pensé à Email (j'utilise le mode Exchange en push automatique pour Hotmail) mais en le désactivant totalement, les résultats étaient les mêmes.

J'ai supposé logiquement que ma batterie était un poil fatiguée, mon Spica datant de Noël 2009. J'avais fait les wipe stats qui vont bien, etc. Sauf que la NextGen me prouve maintenant le contraire : lorsque je laisse mon tel en veille pendant plus d'une heure, le pourcentage de batterie n'a pas bougé, chose qui n'arrivait jamais en Voku.

Est-ce le .32 qui a tout changé ? Ou autre chose ?

[sian391]

Ah! Oui un dixene d'heures oui quand même.

C'est chaud çe truc après j'ai remarqué que chaque rom et kernel se comporte différament d'un spica a l'autre alors que c'est tous les même phones.

Sent from my S.Spica using Tapatalk

[suckup_de]

oui je pense que tu as bien compris ce dont je parle mais je ne comprends pas bien ton objection à propos du passage de CM6 à 7. Car dans ce dernier cas tu refais une install complète donc ma modif n'intervient plus puisque en général on fait un Wipe Data & Cache et l'install re-formate la partition system.

Le problème c'est ce qui se passe en cas de Wipe Data & Cache et que l'on ne met pas à jour le système, on veut garder la même ROM.

En installant les librarys de lib.so dans /data au moment de l'install via le recovery, on s'interdit de pouvoir faire un Wipe Data & Cache plus tard...

Ce que je propose c'est de supprimer l'utilisation de data (qui sert principalement à stocker temporairement les lib.so des applis préinstalées dans /system/app). Ça peut se faire en extrayant directement au cours de l'exécution du script secondboot (pour la voku) les libs directement des apks.

voici un exemple de documentation :

# QuickPic install
PREF_FOLDER="/data/data/com.alensw.PicFolder"
APP_APK="/system/app/PictFolder.apk"
if [ -e "$PREF_FOLDER" ];
then
   echo "--- Settings for QuickPic";
   echo "extracting from $APP_APK to $PREF_FOLDER/lib"
   /system/xbin/jfs_ziptool extract "$APP_APK" "$PREF_FOLDER" lib/armeabi/libqpicjni4.so;
   mv "$PREF_FOLDER"/lib/armeabi/* "$PREF_FOLDER"/lib/
   rmdir "$PREF_FOLDER"/lib/armeabi/
   chown system:system "$PREF_FOLDER"/lib/*
   chmod 755 "$PREF_FOLDER"/lib/*
fi;

mais je suis en train de modifier le script en question pour retrouver automatiquement les library à installer.

Par exemple pour QuickPic où le nom de la library à extraire change de version en version...

Cerise sur le gateau le zip d'install est moins gros ;-).

PS: ça ne s'applique pas à ta ROM visiblement Sofien ;-).

I copy the libs on the first reboot to the correct path ;) because Android will create the directory's automatically on the first boot. If a app isn't installed, then the libs can't copied and will be deleted ;)

/system/xbin/cp -rf /data/lib/rockplayer_armv6/*.so /data/data/com.redirectin.rockplayer.android.unified/lib/;
/system/xbin/cp -rf /system/bin/rockplayer_sgm/*.so /data/data/org.freecoder.android.cmplayer/lib/;
/system/xbin/cp -rf /data/lib/estrongs/*.so /data/data/com.estrongs.android.pop/lib/;
/system/xbin/cp -rf /data/lib/quickpic/*.so /data/data/com.alensw.PicFolder/lib
/system/xbin/cp -rf /data/lib/qqplayer/*.so /data/data/com.tencent.research.drop/lib/;
/system/xbin/cp -rf /data/lib/opera_mini/*.so /data/data/com.opera.mini.android/lib/;
busybox rm -r /data/lib/;

[LordManta]

I understand that.

That's the purpose of the secondboot script.

But my point is that if one does a Wipe Data & Cache without reinstalling the zip file (just to reset the phone for example) libs are lost and it remains apps in system/app that will not find their native libs.

That's why I propose to directly extract libs from their corresponding apks in system/app rather than copying them in a temp location on DATA partition. As zip command doesn't seem to work I propose an utility to do the job.

In addition to that my solution makes the zip liter. This solution seems to apply at least to your ROM, IT4ALii3EN's one and NextGen but perhaps others (I didn't have tested all ROMs so far ;-)).

Modifié 27 juillet 2011 par LordManta

[pkseb]

Installé la 5.9 et gros souci depuis apres avoir éteint mon téléphone depuis reémarrage uniquement en recovery Y aurait un fichier , une rom qui me permetrait de remettre le spica aux parametres de bases ( je ne peux meme pas le connecter via odin sur le Pc)

merci

[BHMath76]

La v6 de SM+X et sorti, la v14 de CM+X aussi !

[LordManta]

Installé la 5.9 et gros souci depuis apres avoir éteint mon téléphone depuis reémarrage uniquement en recovery Y aurait un fichier , une rom qui me permetrait de remettre le spica aux parametres de bases ( je ne peux meme pas le connecter via odin sur le Pc)

merci

Tu as utilisé la kitchen pour construire ta ROM ? Si oui quel kernel as-tu utilisé ?

[pkseb]

Tu as utilisé la kitchen pour construire ta ROM ? Si oui quel kernel as-tu utilisé ?

j'avais utilisé la rom de base v.5.9

le spica toujours bloqué sur le mode recovery au démarrage, en faisant la manip juste avant le redémarrage j'arrive a le mettre en mode download mais le PC (odin) ne le reconnait pas

je désespere

[LordManta]

Le recovery est il fonctionnel ?

Si oui, j'imagine que tu as déjà tenté une réinstallation de la ROM non ?

J'avais eu un soucis similaire à un moment en ayant converti en ext2 mes partitions et en ayant toujours un "vieux" kernel qui n'avait pas encore le support ext2. Si je ne me trompe pas la v5.9 fait passer en ext2 mais si ton install pour une raison ou une autre s'est arrêté avant l'install du kernel...

Ceci pourrait expliquer cela...

[lennykove]

Bonjour

Je vous laisse un petit message apres avoir cherché pendent 3 bon jours et nuit, j'ai voulu flasher mon Spica de cette facon et je n'est plus accès au mode Recovery.

En fait j'avais deja utilisé cette rom et tout c'etait bien passé la premier fois je l'est reflasher a cause d'un problème avec ma 3g(problem qui est du a plusieur apps DL sur le Market 7 en tout donc rien avoir avec la rom)

J'ai donc refait etape apres etape dans l'ordre comme la premier fois mais la PROBLEME j'esseille d'accéder au mode recovery et il me met ce logo...

je ne comprend pas je vous demande de l'aide.

Merci d'avance a celui ou celle qui voudrai bien perdre un peut de son temps pour moi.

_Kove

[khancyr]

C'est simplement que t'a oublier de flasher le kernel root qui donne le recovery tel qu'on le connait!sa c'est le recovery de base de samsung qui permet juste un reset.

Reprend donc du début!

Flash la jh7 oiu jh6 , puis le kernel lk 2.08 , puis avec le recovery met la Rom custom que tu veux!

[lennykove]

C'est simplement que t'a oublier de flasher le kernel root qui donne le recovery tel qu'on le connait!sa c'est le recovery de base de samsung qui permet juste un reset.

Reprend donc du début!

Flash la jh7 oiu jh6 , puis le kernel lk 2.08 , puis avec le recovery met la Rom custom que tu veux!

En fait c'est sa que je comprend pas car je l'est fait sa, et j'ai recommencé genre une dixaine de fois mais toujour le meme problem, donc il y a un truc qui cloche !! :/ je me relance encore une fois et je tienau courent mais [color=red][b]sa[/b][/color] m'étonnerai que sa y change grand chose ( je vais quand même esseille de le reDL et tt ;) )

merci de ta réponse rapide.

_Kove

Bon ba j'ai resseiller rien ne boug c'est pareille je ne comprend vraiment pas pourquoi ... j'ai lu qu'il y avait un autre recovery savez vous par hasard ou je peut le trouver que je l'esseille ?

Modifié 29 juillet 2011 par Lenny_Kove