Mod para abrir apps mas rapido

[titoflow]

Buenas, hace unos dias leí por aquí que habia un mod que arreglaba un bug de android, que hacia que las app tardaran algo mas de lo normal en abrir. Tambien leí que el kernel perseus lo lleva ya integrado este mod. Yo flasee el perseus y si que se notaba, pero ahora he vuelto a flasear el kernel original y me gustaria encontrar este mod. Llevo todo el dia buscandolo y no se donde está... Se que lo vi por aqui, pero os juro que no tengo coj.. A encontrarlo. Si alguien me puede ayudar.... Gracias!!

[yocasta]

La aplicación se llama seeder, la puse por aquí yo. Busca en mis hilos :thumbup:

[titoflow]

Muchas gracias ya lo encontré!

[hugopincho]

Sinceramente en mi caso por lo menos, yo he probado varios días esta app y no he notado nada de nada, también la probé en un s3 y en una galaxy tab2, y tampoco he notado nada en absoluto.

[garagrim]

Sinceramente en mi caso por lo menos, yo he probado varios días esta app y no he notado nada de nada, también la probé en un s3 y en una galaxy tab2, y tampoco he notado nada en absoluto.


No eres el único, yo tampoco noto nada de nada :S

[litoceb]

Por si acaso puesto está jajaj.

[jaaa]

Lo que ocurre es que no todos necesitáis usar el seeder...

Esa aplicación es una chapuza (en el sentido auténtico de la palabra, no peyorativo) que intenta corregir un problema después de que haya ocurrido. El modo correcto de solucionarlo sería con una modificación del kernel.

El problema consiste en que hay varias aplicaciones que necesitan números aleatorios para funcionar y, por un pequeño error, el sistema no los genera a la velocidad adecuada... Cuando se necesitan más números aleatorios, si el sistema no los tiene disponibles, la aplicación que los necesita se "para" y "espera" hasta que los pueda conseguir... Eso hace que, a nosotros como usuarios, la aplicación nos parezca lenta o que va "a saltos".

Como algunos de los kernels personalizados ya han subsanado ese error -y, posiblemente, alguno de los originales de Samsung también- es muy probable que con el kernel que estéis usando la aplicación "seeder" sea inútil.

Por si fuera poco, es otro proceso más corriendo todo el tiempo, así que puede ralentizar el sistema (muy poco) en vez de ayudar.

Lo que intento decir es que, el chico que programó "seeder", probablemente no sabía o quería meterse en "el fregao" de modificar el kernel... O si sabía, pero necesitaba una "prueba de concepto" antes de meterse al lío... Y -con toda la buena voluntad- ideó una chapuza que solventaba el síntoma, pero que no eliminaba la causa.

Una vez conocido el problema, los programadores de los kernels han ido directos al grano para eliminar la causa (que es como se debió resolver en un principio.)

Un saludo a todos :bye:

[ultiimate]

Saludos.

Ojo con esta aplicacion o metodo porque tiene mas de efecto placebo que de realidad empirica.

De hecho es la forma de funcionar de android a la hora de generar datos aleatorios. Si tu estas "despertando" a la CPU cada segundo o dos para que genere mas datos aleatorios para que las apps no tengan que esperar estas forzando el sistema y concretamente cpu.

Paradogicamente como relata uno de los programadores de android con mayores conocimientos CYANOGEN. el uso de estos datos aleatorios /dev/ramdon solo son usados por la libreria libcrypto, que es utilizada para las operaciones criptograficas como las conexiones SSL, generacion de claves ssh.

wpa_supplicant / hostapd, para generar WEP / WPA y las bibliotecas que generan al azar identificadores de partición cuando haces un formato ext2/3/4.

En ninguno de esos 3 usos se usan apps por lo que generar datos aleatorios no hace nada excepto al "azar"

Por supuesto totalmende desaconsejado en jelly bean.

En XDA lo desaconsejan.

Saludos

Conclusion, mas no siempre es mejor.


http://www.xda-developers.com/android/entropy-seed-generator-not-all-its-hacked-up-to-be/

[natispain]

Jaja, ultimate, como siempre a nivel estelar. No es que he entendido todo lo que has dicho pero sigo tus consejos siempre, ya sabes. Jaja

[ultiimate]

Jaja, ultimate, como siempre a nivel estelar. No es que he entendido todo lo que has dicho pero sigo tus consejos siempre, ya sabes. Jaja

No no, yo si lo he entendido, pero en este caso yo solo me he valido y he informado de los grandes conocimientos de la gente de xda.

Por cierto, una aclaracion sobre el seeder, mas que totalmente desaconsejado en jelly bean, no dispongo de informacion de si la forma de generar datos aleatorios ha sido modificada, como digo, ni creo que haya sido revisada por google.

Es evidente que en equipos rapidos con quads core y demas esta "espera" es irrelevante. Yo desde que la probe en muchas circunstancias ya note un notable efecto placebo :D

Lo dicho, mas que totalmente desaconsejada en jelly bean totalmente desaconsejada en moviles rapidos como es el caso del note2.

Saludos

[sowed]

a mi directamente me da el mismo nivel de entropia (el maximo) tanto activado como desactivado... así que fuera, sobretodo si encima decís que es desaconsejable.

[jollito]

ke os parece la apk pimp my rom??Antes la habia para flasear desde cwm pero ahora la hay en el google play!! Yo la he utilizado siempre y ami me va bien, sobretodo en pequeños lags!!
Salu2

[jaaa]

Por cierto, una aclaracion sobre el seeder, mas que totalmente desaconsejado en jelly bean, no dispongo de informacion de si la forma de generar datos aleatorios ha sido modificada, como digo, ni creo que haya sido revisada por google.

Es evidente que en equipos rapidos con quads core y demas esta "espera" es irrelevante. Yo desde que la probe en muchas circunstancias ya note un notable efecto placebo :D

Lo dicho, mas que totalmente desaconsejada en jelly bean totalmente desaconsejada en moviles rapidos como es el caso del note2.

A ver, desglosemos el tema en partes, que sólo estoy de acuerdo a medias. :D

Sé que lo tengo muy difícil porque, cuando me expreso directamente "a las claras", casi siempre doy con alguien que se mosquea... mientras que si dejo una parte para leer "entre líneas" aparece otro alguien que quiere entrar más "de lleno"... :loco::palomitas:


Lo primero aclararé mi comentario anterior, porque creo que no me expliqué nada bien:

Donde dije: "lo que pasa es que muchos de vosotros no necesitáis el seeder"...
Quería que se entendiese: "lo que pasa es que muchos de vosotros no tenéis el problema que el seeder intenta solucionar."
No intenté decir que el seeder fuese útil...
(Aunque estoy convencido que, en determinados casos, lo será)
Pero tampoco intenté decir que fuese inútil...
(Porque sé a ciencia cierta que, en el resto de casos, puede serlo)
Lo que sí intenté transmitir en el post es:
- En qué consiste el problema.
- En qué consiste el "seeder".
- Cómo creo que se debería abordar la búsqueda de la solución real.
- Y, finalmente, en qué parte del sistema sería lógico implementarla (el kernel.)



Ejemplo sencillo y muy habitual: "¿Son útiles los antibióticos?"

No... (En ausencia de infección.)
Sí... (En presencia de infección.)
Sólo si, además, la infección padecida es del tipo que reacciona ante antibióticos.
Sólo si, además, el antibiótico seleccionado es adecuado para tratar esa infección concreta.
Sólo si, además, el antibiótico se administra y dosifica de forma adecuada.

Cuando -como en este caso- es el propio paciente el que:
Diagnostica e identifica la infección, selecciona el antibiótico, y verifica y administra la dosis...
Pues, ¡apaga y vámonos!


Estoy bastante de acuerdo con ultiimate respecto al "seeder", aunque pueda parecer que no.
Lo que ocurre es que, globalmente, mi evaluación no es tan severa.
Como puntos negativos, encuentro que:

Es sintomático: No soluciona el problema, sino las consecuencias de éste.
No va al grano: Permite que el problema se produzca, aunque minimice el impacto.
Produce sobrecarga: Aunque hay que tener en cuenta el contexto:
- Se solicitan en el OP opiniones y comprobaciones al resto de miembros de xda.
- Ha mejorado en base a las respuestas recibidas, ya que hay un montón de versiones.
- Actualmente no es demasiado invasivo: Dos veces por minuto no es gran cosa.
No está documentado el diagnóstico, aún no se por qué.
No está documentada la lógica de la elección de la solución elegida.
No se intenta refutar que la mejora provenga de algún efecto colateral.
Y no parece apoyarlo ningún desarrollador reconocido.



En lo que no estoy de acuerdo con ultiimate es en "negar la mayor":

El lag existe realmente: ¿Lo habéis visto/sentido alguna vez? Pues esa es la realidad.
Como es real, sí que se está trabajando en el tema: Ved esta incidencia concreta (https://code.google.com/p/android/issues/detail?id=42265).
Aquí ayuda mucho que el código de Google y sus incidencias sean de dominio público.
Como es evidente, en esa incidencia interviene cierto número de programadores "reconocidos"...
Si el tema fuese una sandez, se estarían concentrando en asuntos más productivos.
Aparentemente existe una cierta relación causa-efecto entre los lags (retardos) y el sistema de provisión de números aleatorios.
(Que, a falta de más datos fiables, apunta a su escasez en momentos concretos).



Sin embargo, en el desarrollo de este caso, se han producido una serie de despropósitos, errores y asunciones varias que lo empañan y dificultan su esclarecimiento:

Casualmente los "genios", desarrolladores, usuarios y chapuceros comparten foro, documentación y voz...
(Me complace ver que, en la toma de decisiones, el sufragio no es universal. ¡Todavía!)
Cualquier experiencia realizada en esas condiciones de laboratorio es de dudosa buena calidad:
(A mi entender, y siendo extremadamente generoso.)
- La muestra no representa a la población (Sólo XDA. Sin pre-selección, el que quiera participa...)
- La muestra es sesgada y determinista (No recoge todos los estratos proporcionalmente. Se hace con voluntarios. Participan más los perjudicados...)
- Hay sesgo de información (Por ser peyorativa la opción "no vale para nada"... especialmente si has pagado la aplicación.)
- Hay sesgo de exclusión (Para responder, hay que justificarlo... y no todos saben como)
- Hay sesgo de confirmación (La aplicación distorsiona el sistema Android en favor del "va bien", pero no se intenta compensar, ni refutar...)
- La pregunta que se hace es muy concreta, pero el experimento que debería darle respuesta no está claramente definido (No se ofrece un mismo experimento para todos...)
- Las estimaciones, si es que las hay, no son coherentes (La muestra ha crecido, pero no así la confiabilidad de las respuestas...)
- Por todo lo anterior, la conclusión o justificación resultante, es (para mi) casi despreciable... (Especialmente, si sigue sin documentarla, es una experiencia inútil y abocada al fracaso. Se queda en una simple solicitud de opinión.)
Cyanogen habrá dicho "que /dev/ramdon sólo es usado por la librería libcrypto" realmente... y con razón, porque habla del sistema (kernel incluido)...
Pero no ha dicho que el desencadenante del problema no pueda estar fuera del sistema:
¿Y las aplicaciones instaladas? En un mercado como éste, ¿Pueden, de verdad, estar todas bien programadas?
El OP del hilo del "seeder" (tal vez por inexperiencia, o por exceso de entusiasmo ante el descubrimiento, o -conjeturo- por obtener ventaja económica*) cometío el error técnico de no seguir el cauce "oficial":
- No ofreció documentación detallada de sus comprobaciones.
- No ofreció documentación detallada de la lógica aplicada para obtener su conclusión.
- No informó a ningún colega [1 (http://www.wordreference.com/definicion/colega)] de la conclusión, para verificarla con su ayuda, como paso previo a la publicación.
- Y tampoco lo comunicó a Google abriendo una incidencia...
- Lo que sí hizo, fue poner directamente la miel en la boca del asno...
Como todos quieren que el juguetito esté a la altura del Maserati del vecino, se "generó alarma social"... Y así va el hilo, con 2600 post y ninguna conclusión razonable.
E inmediatamente -como no podría ser de otra manera- todo propietario (niño y mayor, lego y profano, capacitado e incapaz,...) se puso a hacer sus propias pruebas y publicar resultados, opiniones, sensaciones, conjeturas, porcentajes y actos de fe... Y, henos aquí, hablando también del tema. :D



Y si, en vez de ser un teléfono Android, fuese un coche...
¿Lo pondríamos en manos de cualquier chapucero?
Alguien que dijese: "Pasa del fabricante, ¡tú prueba esto, que va de PM!"...
O esto: "Si no anda, se reprograma la centralita y listo, ¡total!, ¿Qué puede pasar?"

(A mi es que, este tema concreto, me alucina:
Se exige tanta inteligencia y cualificación para unas cosas,...
Para acabar consintiendo, con contumacia, que nuestros -carísimos- aparatos se conviertan en la cobaya particular de cualquier arrogante: Niños, charlatanes, meapilas,...
De verdad, ¡se me hace increible!)



Resumen de la historia (y principio del fin):

El hilo del OP es del 12 de noviembre...
(Durante mes y medio se hacen pruebas y chorradas, pero sin documentarlas correctamente)
El 3 de enero el desarrollador Craig Andrews (http://candrews.integralblue.com/resume) se lo anuncia a Google. (Pero da a entender que es un error de la MV Dalvik por la sección donde lo publica...)
El mismísimo día 3, Google cierra la incidencia (¡Normal, si no es un problema de la Dalvik!)...
Medio mundo se indigna porque Google cierra una incidencia...
(¿Pero cómo se atreve Google? !¡Normal! Lo lógico es buscar el origen del fallo y crear otra incidencia en la sección adecuada.)
...
El día 26 de enero, por fin, pengus77 aplica un primer parche razonable (Changelog de la versión 011, duodécima línea (http://forum.xda-developers.com/showpost.php?p=36669390&postcount=2)).
(Finalmente se implementa en el kernel... :oh: ¿qué estábamos hablando el otro día!)
(Y, a pesar de lo dicho por Steve Kondik, se hace en un kernel derivado del suyo) :palomitas:
Continuará... :sisi1:


__________________________________________________ ________________________
* Sí, ya sé que también cede su utilización de forma gratuita a los miembros de xda...

[ultiimate]

saludos.

poco que objetar ante semejante exposicion jaaa. brillante disertacion repleta de detalles con conocimientos.

tienes razon, la incidencia es real, si bien me gustaria hacer hincapie estos puntos que relatas.



No está documentado el diagnóstico, aún no se por qué.
No está documentada la lógica de la elección de la solución elegida.
No se intenta refutar que la mejora provenga de algún efecto colateral.
Y no parece apoyarlo ningún desarrollador reconocido.

es cierto que el uso del metodo reduce en "algunos" moviles un "lag", que apoyaria la tesis o diagnostico realizado por el desarrollador y su metodo para mantener la entropia.

digo "lag" porque si hay algo que tengo meridianamente claro es que los lags que sufre android son de diversos origines y causas dispares. Es decir, si hay algo que a dia de hoy me atrevo a asegurar es que los lags de android no se deben unica y exclusivamente al posible problema del acceso de datos aleatorios por parte de las apps.

Digo esto mas que nada porque he llegado incluso a "leer" disparates semejantes como que el lag en android se corrije con el seeder (o el metodo).

ciertamente si tienes muchisima razon en que mi afirmacion fue demasiado tajante. Queria enfatizar que en el caso del note 2 no parece tener ningun impacto relevante.

Como ha comentado otro forero, la entropia mostrada en las ultimas versiones de la app seeder muestra los mismos "niveles" tanto activado como desactivado. Esto refrendaria un "experimento" que realice con un colega y otro note 2.

Misma rom, mismas apps, misma configuracion de sistema, evidentemente con un nandroid es facil sacar una "radiografia" del estado de un telefono e insertalo en otro.

Diferencias, uno con seeder y el otro sin seeder, mismas apps cargadas en memoria.

Esta claro que no dispongo de ningun tipo de metodo para medir tiempo de ejecucion, asi que despreciaremos milisengundos y esas fracciones de tiempo.

El comportamiento en la apertura de apps, cierre, cambio de una a otra se muestra visualmente exactamente igual tanto en el note con seeder como con el note sin seeder.

como podras comprobar el "experimento" cuenta con lagunas, pero todo y asi me hace pensar de forma abrumadora de que se comporta como un placebo.

lo dicho, yo he puesto la informacion de xda. a partir de ahi cada uno puede comprobar si nota efecto pausible en su note2, y por supuesto sera un tema a seguir.

saludos

[yocasta]

Efectivamente se nota (en mi caso) mejoría a la hora de abrir ciertas apps como es el tapa, el maps y el market. En otras no lo he notado.
También tengo que decir que dejé de usarla porque el beneficio no es para quitar el hipo en un móvil como el nuestro. Al igual que tampoco veo la necesidad de hacer overclock al procesador o gpu.

[Gelrooss]

Ante todo... Me quito el sombrero, ante probablemente una de las mejores explicaciones que he visto sobre algo en un foro. Me refiero a la argumentación que ha proporcionado el usuario jaaa. Ya no es lo que dice, sino como lo que dice. Ya no es los datos que da, sino... como los da. Así mismo también me quito el sombrero ante el compañero ultimate. Que quizás siendo menos conciso, también aporta lo suyo.

Dicho esto y entendiendo perfectamente los argumentos expresados, por ambos contertulios...

Decir que en Jeally Bean, que posiblemente a estas alturas ya esté parcheado el kernel, se recomiende no usarlo, me parece bien.

Pero actualmente, yo que ando con un Galaxy Mini S5570i y con una Pascal 2 y Con una Huawey Ideo S7

Terminales en sí poco potentes y con SO que no está a la última... Pues que quieres que os diga, yo juraría que si debe de hacer algo, porque si lo quito el lag aumenta y en algunos casos considerablemente.

No se, quedo a la espera de respuesta... Pero creo que No es placebo en mís casos. Terminales poco potentes y con SO más antiguo.

Ya me diréis si ando equivocado...

Salu2

[jaaa]

Lo primero, agradeceros los agradecimientos... :D ¡Animan mucho!



me gustaria hacer hincapie estos puntos...
... es cierto que el uso del metodo reduce en "algunos" moviles un "lag"...
... los lags que sufre android son de diversos origines y causas dispares...
... no se deben unica y exclusivamente al... acceso de datos aleatorios por... las apps.
... he llegado incluso a "leer"... que el lag en android se corrije con el seeder (o el metodo).

Estamos totalmente de acuerdo, en todo. :D

Hay un montón de motivos para sufrir retardos y, aunque unos sean más habituales que otros, buscar una única solución mágica no parece factible...
Pero eso no impide que, la teoría tras el seeder, pueda ser la solución de "uno" de los "múltiples" problemas que causan "alguno" de los retardos.



Quería enfatizar que en el caso del note 2 no parece tener ningun impacto relevante.
la entropia mostrada en... seeder muestra los mismos "niveles" tanto activado como desactivado.
Esto refrendaría un "experimento"... Misma rom, mismas apps, misma configuración...
El comportamiento... se muestra visualmente exactamente igual...
me hace pensar... que se comporta como un placebo.

En esta parte, sólo estoy parcialmente de acuerdo.

Lo primero habría definir placebo en este entorno: "La falsa píldora, o medicamento, o solución."
(Esto deberían saberlo los que se lanzan al cuello del OP del seeder y soluciones parecidas)

Una cosa, o es, o no es placebo...
Estos aparatos, como no son susceptibles de sentir emociones, no alteran su comportamiento ante un placebo.


Aquí el "efecto", en el caso de que alguien lo sienta, será el evaluador y no el paciente.
Y eso, a mi, me indica que el método de observación aplicado no es correcto.


Si la solución funciona en un cierto número de casos, la palabra "placebo" deja de ser aplicable...
Es "medicamento", aunque (quizás) no sea el apropiado para el resto de los casos.


Pregunta importante: ¿notaste retardos en alguno de los dos teléfonos?
Porque si no había retardos a suprimir, el seeder no pudo cumplir su mision... :rolleyes:

En todo caso, un experimento fallido no siempre anula la teoría.

Y creo, además, que las claves las ofrecéis vosotros mismos (entre los tres):

con un nandroid es facil sacar una "radiografia" del estado de un teléfono...
... se nota... mejoría a la hora de abrir ciertas apps como es el tapa, el maps y el market. En otras no lo he notado.
... dejé de usarla porque el beneficio no es para quitar el hipo en un móvil como el nuestro.
yo que ando con... Terminales poco potentes y con SO más antiguo....
yo juraría que si debe de hacer algo, porque si lo quito el lag aumenta y en algunos casos considerablemente... creo que No es placebo en mís casos.

Con tal diversidad de terminales, es muy probable que unos sean más proclives a mostrar el problema que otros.
Como el Note 2 y el Nexus actual son de los más potentes, podríamos no percibir el problema aunque estuviese ahí.
Por eso habría que indagar más en el caso de Gelrooss: "con terminales poco potentes y SO más antiguos"... Como mi pobre HTC Magic, que se muere con JB.
(O sea, que no vale que los que llevamos un maquinón les gritemos al resto que es placebo)


Con tal diversidad de terminales, podría depender del hardware concreto que posean.
No parece razonable, porque con el mismo móvil hay una gente que lo padece y otra que no.
(Aunque al ser una percepción, podríamos estar ante un mismo efecto que se manifieste por problemas distintos)


O podría ser una cuestión de interdependencia entre las aplicaciones instaladas.
Aquí viene al caso la "radiografía" de ultiimate: es verdad que es fácil obtener un duplicado.
La pregunta es: ¿Cuantos llevamos un móvil idéntico al de cualquier otra persona?
Y la respuesta es: Probablemente ninguno. Nadie lleva la misma configuración y las mismas aplicaciones.
(Total, que dos teléfonos idénticos, podrían exhibir distinto comportamiento en función de las aplicaciones instaladas)
Quizás por eso, yocasta percibe unos retardos que ultiimate no encuentra.


O podría ser una cuestión relativa a la incorrecta optimización de las aplicaciones instaladas.
(Que una misma aplicación, en dos teléfonos idénticos, muestre distinto comportamiento en función de si está activo el seeder o no)
Aunque tras el experimento de ultiimate es improbable, aún es posible que sólo se perciba el problema bajo determinadas condiciones.


Y, como última idea, podría ser que el retardo lo disparase otro error subyacente.
(Un error de I/O, o una operación congelada que retenga recursos, o ..., podría coincidir con esta "debilidad" del sistema de números aleatorios y amplificar el problema a un nivel perceptible)


Mi conclusión: Excepto increparse sinsentidos los unos a los otros, cualquier opinión ayuda... Si es con pruebas rigurosas ¡Mejor!

Y, ¡hasta ahí puedo leer! :risitas:

[natispain]

Madre mía! Me voy a centrar en disfrutar del teléfono y no profundizar en los errores y los lags, digamos.
Y, sí, jaaa, tus tutos siguen encantándome pero como he dicho en una ocasión me pondré en serio con ello este fin de semana jajaja
Tú sigue así que posts como los tuyos se necesitan mucho por aquí.

[Gannicus85]

En mi caso no se nota nada de nada, así que fuera!!!