Utilizar o no firmar la firma apk de Android odex
La forma más sencilla de generar apk es:
Siempre que ejecute el proyecto de Android e ingrese a la carpeta bin en el directorio de trabajo, puede encontrar el archivo apk con el El mismo nombre que el proyecto. De forma predeterminada, el usuario de depuración ha firmado el apk.
Si desea firmar el apk usted mismo:
La importancia de la firma
Para garantizar la identificación legal de cada desarrollador de aplicaciones y evitar que algunos desarrolladores Puede surgir confusión al usar el mismo nombre de paquete para reemplazar un programa instalado. Necesitamos firmar de forma única nuestros archivos APK para garantizar que cada versión que lanzamos. Necesitamos firmar de forma única nuestros archivos APK para garantizar que cada versión que lanzamos sea coherente (. por ejemplo, las actualizaciones automáticas no dejarán de instalarse debido a versiones inconsistentes).
2. Pasos para la firma
a. Crear una clave
b. Utilice la clave generada en el paso a para firmar la apk
3 Operaciones específicas
Método 1: firma de apk en la línea de comando (principio)
Al crear una clave, debe usar keytool.exe (ubicado en jdk1.6.0_24\\bordeaux. ) para crear una clave. .0_24\jre\bin), use jarsigner.exe (ubicado en el directorio jdk1.6.0_24\bin) al firmar el apk con la clave generada y agregue los directorios donde se encuentran los dos últimos software a la ruta de la variable de entorno , abra cmd e ingrese
D: \gt; keytool-genkey-alias demo.keke. genkey -alias demo.keystore -keyalg RSA -validity 40000 -keystore demo.keystore/*Descripción: -genkey Generar clave -alias demo.keystore Alias demo.keystore -keyalg RSA Cifra firmas usando el algoritmo RSA -validity 40000 Válido para 4000 días -keystore demo.keystore */D:\gt; jarsigner -verbose -keystore demo.keystore -signedjar demo_signed Estos tres parámetros son el archivo firmado demo_signed, el archivo a firmar demo.apk y el almacén de claves demo.keystore. */
Nota: demo.apk en el directorio bin del proyecto de Android ha sido firmado por el usuario de depuración, por lo que no se puede volver a firmar siguiendo los pasos anteriores. Los pasos correctos deben ser: hacer clic derecho en el proyecto -> Herramientas Anroid-Exportar paquete de aplicaciones sin firmar (Herramientas de Android-Exportar paquete de aplicaciones sin firmar), siga los pasos anteriores para exportar el apk para firmar.
Método 2: use Eclipse para exportar el apk firmado
Eclipse puede exportar directamente el apk final con firma, lo cual es muy conveniente y recomendado. Los pasos son los siguientes:
Primer paso: Exportar.
Paso 2: cree un almacén de claves, ingrese la ubicación y la contraseña del almacén de claves exportado, recuerde la contraseña y la próxima vez se utilizará el almacén de claves existente.
Paso 3: Complete la información del almacén de claves, complete la contraseña, el período de uso y la información organizativa de algunos archivos apk.
Paso 4: Generar el archivo apk con firma, esto es el final.
Paso 5: Si es la próxima versión, vuelva a firmar utilizando el almacén de claves generado anteriormente.
Paso 6: Siguiente paso, siguiente paso, ¡terminado!
Método 3: utilice IntelliJ IDEA para exportar el apk firmado.
Los pasos del método son básicamente los mismos que los de Eclipse. La ruta de operación aproximada es: menú Herramientas-gt; Exportar apk firmado.
4. Una vez completada la firma, utilice zipalign (alineación zip) para optimizar el archivo APK.
Las aplicaciones sin firmar no se pueden utilizar ni optimizar. Después de firmar el apk, Google recomienda optimizarlo usando la herramienta zipalign.exe (ubicada en el directorio android-sdk-windows\tools):
D:\gt;zipalign -v 4 demo_signed.apk final. apk
Igual que el anterior. zipalign puede alinear los datos sin comprimir en el archivo apk en límites de 4 bytes (4 bytes es un buen valor para el rendimiento), de modo que el sistema Android pueda usar la función mmap() (verifique usted mismo el uso de esta función) para leer Al recuperar archivos, puede obtener un alto rendimiento al leer recursos.
PD: 1. Esto significa que, en términos generales, el compilador lee 4 bytes como una unidad. Aquí, en este caso, la CPU puede acceder a las variables. eficiente y rápidamente (que antes sin alineación).
2. La causa principal de la alineación: la máquina virtual Davlik de Android utiliza su propio formato patentado DEX, que es relativamente compacto y se puede optimizar aún más mediante la "alineación" para obtener un mejor rendimiento en tiempo de ejecución. Pero el tamaño generalmente aumenta. .
5. El impacto de las firmas en las aplicaciones.
No puedes crear una sola aplicación. Es posible que tengas un gran proyecto estratégico y quieras incluir todas las áreas de la vida, servicios, juegos, sistemas, etc. Google recomienda que utilice el mismo certificado de firma para todas sus aplicaciones.
Al utilizar su propio certificado de firma idéntico, nadie puede sobrescribir su aplicación incluso si el nombre del paquete es el mismo, lo que tiene los siguientes efectos:
1) Actualizaciones de la aplicación. El software actualizado con la misma firma normalmente puede sobrescribir la versión anterior del software. De lo contrario, si la comparación del sistema encuentra que el certificado de firma de la nueva versión no coincide con el certificado de firma de la versión anterior, la nueva versión no se instalará correctamente. .
2) Aplicar la modularidad. Android permite que aplicaciones con la misma firma se ejecuten en el mismo proceso. Si se ejecutan en el mismo proceso, son equivalentes a la misma aplicación, pero puede actualizarlas de forma independiente, lo que también es un concepto modular a nivel de aplicación.
3) Permitido disfrutar de código y datos****. Android proporciona etiquetas de permiso basadas en firmas. A través de la configuración de permisos, podemos lograr acceso y disfrute entre diferentes aplicaciones, de la siguiente manera:
AndroidManifest.xml: lt; permiso android: ProtectionLevel="normal" /gt;
p>La etiqueta ProtectionLevel tiene 4 valores: normal (predeterminado), peligroso, firma, firmaOrSystem.
En resumen, normal significa bajo riesgo y todas las aplicaciones no pueden acceder y disfrutar de esta aplicación. Peligroso significa alto riesgo, todas las aplicaciones pueden acceder y disfrutar de esta aplicación. Firma significa que las aplicaciones con la misma firma pueden acceder y disfrutar de esta aplicación. SignatureOrSystem significa que las aplicaciones en la imagen del sistema y las aplicaciones con la misma firma pueden acceder y disfrutar de esta aplicación, Google recomienda no usar esta opción ya que la firma es suficiente. Utiliza una licencia cuando necesita disfrutar de algunas funciones específicas de su imagen.