I didn't write this hack, but it appears to work with the new stock GB update.
I did edit the script and zip archive so it wouldn't need any external exe's or libs to apply. Just copy the newest framework.jar file to the script directory and run the HackHotspot.bat file. Then simply run these ADB commands from a dos window.
------
adb shell
mount /system
exit
adb push framework.jar /system/framework.jar
-------
clear Dalvik and fix permissions if desired
Reboot Phone
Done!
Much appreciated but way over my head (I've never done anything with ADB). Any chance of getting this, and the USB debugging notification fix, in a flashable form?
The debug fix is the one that doesn't display the statusbar icon when connected?
I'll see what I can do for ya
townsenk said:
Just copy the newest framework.jar file to the script directory and run the HackHotspot.bat file.
Click to expand...
Click to collapse
Awesome script. Thanks.
will this work for the revolutionary?
CAn i do this on a MAC?....
Can n e one verify that this works?
im getting errors in the script:
Code:
Extracting framework.jar
7-Zip 4.65 Copyright (c) 1999-2009 Igor Pavlov 2009-02-03
Processing archive: framework.jar
Extracting META-INF
Extracting META-INF\MANIFEST.MF
Extracting preloaded-classes
Everything is Ok
Folders: 1
Files: 2
Size: 65651
Compressed: 12413
Unpacking classes.dex
Can't find the file classes.dex
Putting HotspotHack into place
The system cannot find the path specified.
The system cannot find the path specified.
0 file(s) copied.
Repacking classes.dex
UNEXPECTED TOP-LEVEL EXCEPTION:
java.lang.RuntimeException: Cannot find file or directory "out/"
at org.jf.smali.main.main(main.java:173)
Could Not Find C:\AddHotspotHack\classes.dex
The system cannot find the file specified.
Updating framework.jar
1 file(s) copied.
classes.dex : no such file or directory
Cleaning up...
Could Not Find C:\AddHotspotHack\classes.dex
The system cannot find the file specified.
Done if no errors listed above!
C:\AddHotspotHack>
and shouldnt it be
adb push framework.jar /system/framework/framework.jar
Using Java Reflection with Eclipse ADT to Access Internal/Hidden API classes.
Purpose
We present a way to access all the Internal and Hidden Java packages/classes
in the AOS. To do this we need to both repackage the Android.jar and hack the
Eclipse ADT plugin, to allow using these internal packages.
Posting
==================================================
Do NOT post general questions/requests on how to
do this or that, they will not be answered here.
DO post if you have additional tricks, hacks or
information that can help/benefit this tutorial.
==================================================
Background
There are two reasons one cannot use internal packages. One reason is that, if
you're using Eclipse as your development platform, those packages are
internally blocked in the Eclipse ADT plugin. Second reason is that the normal
development android.jar runtime does not contain those *.class files that
belong to the internal packages.
"There is no easy way to use com.android.internal package (internal API) or
anything marked with @hide attribute (hidden API) without using reflection.
That’s because android.jar file does not contain classes from internal and
hidden API and because of this nobody can reference those classes in compile
time."
Thus we need to first restore the "original" android.jar which will allow us
to use internal and hidden APIs. But the runtime equivalent of Android SDK’s
android.jar file is framework.jar. This file is located in the
/system/framework/ directory of your device. We will extract and use this for
our pleasure.
The general procedure:
A) Grab the "full" framwork.jar from your device
B) extract the class files
C) add them to "full" android.jar ??
D) Hack the Eclipse ADT plugin jar.
Finally, NOTHING would have been possible without the excellent step-by-step
instructions on the devmaze-blog by senior Android developer Ievgenii Nazaruk
(aka. "inazaruk"). THANK YOU Ievgenii!References
http://stackoverflow.com/questions/...d-sdk-with-hidden-and-internal-apis-available
http://stackoverflow.com/questions/...-state-permission-for-apps-ran-on-gingerbread
http://code.google.com/p/smali/wiki/DeodexInstructions
http://code.google.com/p/adt-addons/
The General Procedure
NOTE: All this was performed on Windows Vista with Cygwin.(1) Grab BOOTCLASSPATH from init.rc
Find the line in your init.rc file that reads something like:
Code:
[SIZE=2]export BOOTCLASSPATH /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar[/SIZE]
Extract and reformat the path to:
Code:
[SIZE=2]core.jar:bouncycastle.jar:ext.jar:framework.jar:android.policy.jar:services.jar:core-junit.jar[/SIZE]
(2) Grab the "framework" from your device
Create a working directory somewhere, let's call it "_framework":
Code:
[SIZE=2]mkdir ./_framework[/SIZE]
[SIZE=2]cd _framework[/SIZE]
Grab all the framework files from your device:
Code:
[SIZE=2]adb pull /system/framework .[/SIZE]
Rename directory if needed.
NOTE-1: From now on I'll assume you know where you are!
NOTE-2: Most GB 2.3.4+ devices uses .odex'ed files,
with name pairs like: <package>.jar and <package>.odex.
These need to be converted.
(3) Use baksmali with (1)
You can also use baksmali with the switch: -d <framwork-dir>.
The general command is something like below, but in windows there may be "wrappers"
that allow you to just type "baksmali" without the "java -jar" prefix and without
the ".jar" post fix. Anyway here is the command I used:
Code:
[SIZE=2]java -Xmx1024m -jar ./../../baksmali.jar -a 10 -c :core.jar:bouncycastle.jar:ext.jar:framework.jar:android.policy.jar:services.jar:core-junit.jar -x framework.odex[/SIZE]
==> This results in all files put in the "out" sub-directory.
This directory contain 3 sub-directories (for GB 2.3.4):
Code:
[I]android [/I](Hidden APIs)
[I]com [/I](Internal APIs)
[I]javax [/I](Hidden APIs)
NOTE: If you are using Google's own API's, you will probably also need to add
those packages to the path above. (Eg. Email.jar, etc etc ?)
(4) Then use smali to create a dex file from "out" directory
Code:
java -jar smali.jar out
==> creates out.dex from "out" directory.
(5) Run dex2jar on out.dex
Code:
[SIZE=2]./dex2jar.bat out.dex[/SIZE]
==> creates out_dex2jar.jar
(This .jar contain close to 4900 files at 12 MB!)
(6) Rename "out_dex2jar.jar" to "framework-classes.zip"
Code:
[SIZE=2]mv out_dex2jar.jar framework-classes.zip
unzip framework-classes.zip[/SIZE]
(7) Find and copy your Android SDK's android.jar file
Go to: /path/to/android-sdk-windows/platforms/android-X/android.jar
where X is the API level of interest. This obviously have to match the
API level of the files you extracted from your device in: /system/framework .
This .jar file contain more than 5300 files when expanded, but missing all
the internal packages. Our job is to add them back in.
Let's first make a copy that we can use to expand and add files from (6):
Code:
cp android.jar custom-android.zip
unzip custom-android.zip
(8) Add all *.class files from (6) in to (7)
Copy and replace all existing *.class files from framework-classes.zip into
custom-android.zip:
Code:
[SIZE=2]cp -R /path/to/framework-classes/* /path/to/custom-android/.[/SIZE]
The root content of that directory should then look something like this:
Code:
[SIZE=2]android[/SIZE]
[SIZE=2]assets[/SIZE]
[SIZE=2]com[/SIZE]
[SIZE=2]dalvik[/SIZE]
[SIZE=2]java[/SIZE]
[SIZE=2]javax[/SIZE]
[SIZE=2]junit[/SIZE]
[SIZE=2]META-INF[/SIZE]
[SIZE=2]org[/SIZE]
[SIZE=2]res[/SIZE]
[SIZE=2]AndroidManifest.xml[/SIZE]
[SIZE=2]resources.arsc[/SIZE]
(9) Rename directory and create your new "classy-android.jar"
We rename it so not confuse with the original:
Code:
mv custom-android classy-android
zip classy-android
mv classy-android.zip classy-android.jar
IMPORTANT:
Make absolutely sure that the folder structure of your zip archive
is exactly the same as what you intended. To check, unzip the file
and see if it is what you (and eventually Eclipse) would expect.
(For example, if you use 7zip to zip a directory file called "test",
into "test.zip", you may end-up extracting it to ./test/test/... )
(10) Enabling & Restricting Access to classy-android.jar
Instead of just replacing the android.jar with classy-android.jar, we choose
to create a customized Android platform. This way you can enable the Internal
and Hidden API's for those projects requiring them, while other standard
projects doesn't have access to those.
(a) Go to: /path/to/android-sdk-windows/platforms/
and copy the relevant directory (for example):
Code:
cp -R android-10 android-10-internals
(b) Replace android.jar with your classy-android.jar:
Code:
cp classy-android.jar android.jar
("cp" overwrites!)
(c) Edit the build.prop file:
Edit/replace the following lines:
Code:
[SIZE=2]ro.build.version.sdk=10 ==> ro.build.version.sdk=[COLOR=Black][B]-10[/B][/COLOR][/SIZE]
[SIZE=2]ro.build.version.release=2.3.3 ==> ro.build.version.release=2.3.internal[/SIZE]
(11) Customizing the Eclipse ADT
In order to be able to use com.android.internal packages in the Eclipse ADT,
you have to disable the internal protection mechanism of the plugin, that
prevent you to use these libraries. You can see this by right-clicking on your
project package and navigate to:
Code:
[SIZE=2]==> Properties ==> Java Build Path ==> Libraries (tab) [/SIZE]
[SIZE=2]--> Android 2.x.x --> android.jar [/SIZE]
[SIZE=2]--> "Access rules: 1 rule defined": [B][COLOR=Red](X)[/COLOR][/B] [B]Forbidden: com/android/internal/**[/B][/SIZE]
This can not be removed (bug?), even though the interface allows changing, it
never persists after closing the Properties window. So we have to hack it!
The way to do it, is to hexedit the correct java class file and change the
name from "internal" to "internax". First let's find the correct file. The
plugin file is located in the ./eclipse/plugins/ directory, and its name is
something like:
Code:
com.android.ide.eclipse.adt_18.0.0.v201203301601-306762.jar
(a) make a backup copy of this (with the exact name preserved) in another directory.
(b) make a another copy of this in another directory.
(c) unzip (b) in that directory
Code:
[SIZE=2]cp com.android.ide.eclipse.adt_18.0.0.v201203301601-306762.jar hacked_adt.zip[/SIZE]
[SIZE=2]unzip hacked_adt.zip[/SIZE]
[SIZE=2]cd hacked_adt[/SIZE]
This is a huge directory system, so forget poking around in it,
just go to the correct sub-directory:
Code:
[SIZE=2]cd ./com/android/ide/eclipse/adt/internal/project/[/SIZE]
Then find the correct file and the approximate string location within that file:
Code:
[SIZE=2]strings.exe -f -4 -t x ./*.class |grep "android\/internal"[/SIZE]
It happens to be in "AndroidClasspathContainerInitializer.class". Now, use a
hexeditor to find and change the string "com/android/internal/**"
to "com/android/internax/**". That will do it!
Now zip-up your hacked jar directory and copy it over the old one.
(Remember that "cp" overwrites without warning!)
Code:
[SIZE=2]zip hacked_adt[/SIZE]
[SIZE=2]cp hacked_adt.zip /path/to/eclipse/plugins/com.android.ide.eclipse.adt_18.0.0.v201203301601-306762.jar[/SIZE]
You Are Done!
Enjoy your newly hacked Eclipse! Errors
If you get any errors;
1. make sure you have zipped up everything properly as warned before.
2. make sure you have included Google API packages in your BOOTCLASSPATH in step (3).
3. Try to "clean-up" the Java by: "Right-Click" ==> Source ==> "Clean Up...".
4. Google them
5. Ignore them
6. Give up. Not! But I can't help you!
If it still doesn't work, try to download inazaruk's pre-compiled set of internal android.jar's from here.
(For android 7,8,10,15.)
WIP! <here be dragons2>
For a project using internal package imports, see my thread:
"[TOOL][APP][WIP] Native AT Command Injector"
<here be more dragons>
Following the instructions in posts 1-2 above, may not always work. It is not known to me at this time, why it shouldn't. One theory is that it can have something to do with how Eclipse and Android.jar is packaging their files and the resulting sizes.
This was mentioned in this Stackoverflow post:
"Jar files: why does extracting then compression a jar file create a file of a different size to the original?"
Then reading the man pages for "jar" we can inform ourselves with:
Code:
[SIZE=2] c Creates a new archive file named jarfile (if f is specified) or to
standard output (if f and jarfile are omitted). Add to it the
files and directories specified by inputfiles.
u Updates an existing file jarfile (when f is specified) by adding
to it files and directories specified by inputfiles.
x Extracts files and directories from jarfile (if f is specified) or
standard input (if f and jarfile are omitted). If inputfiles is
specified, only those specified files and directories are
extracted. Otherwise, all files and directories are extracted.
t Lists the table of contents from jarfile (if f is specified) or
standard input (if f and jarfile are omitted). If inputfiles is
specified, only those specified files and directories are listed.
Otherwise, all files and directories are listed.
i Generate index information for the specified jarfile and its
dependent jar files.
[/SIZE]
More info is provided here:
The JAR Overview @
http://java.sun.com/javase/6/docs/technotes/guides/jar/jarGuide.html
The JAR File Specification @
http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html
The JARIndex Spec @
http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html
JAR Tutorial @
http://java.sun.com/docs/books/tutorial/jar/
pack200 Reference Page @
http://java.sun.com/javase/6/docs/technotes/tools/share/pack200.html
Another theory is that it may have something to do with what seem to be, that Google have revoked the the use of MODIFY_PHONE_STATE since Android 2.3, and that this influences the Eclipse behavior, when using and modifying older android.jar's. This was mentioned here and here.
Any help would be very much appreciated!
< bump >
Hi, thanks for the info, I made it using linux and worked really nice, these were the lines that I used, hope be useful.
This is my Android folder at home
Code:
Android/
├── eclipse
├── ndk
├── platforms-internals
├── sdk
└── tools
Start an avd running the desired API to modify in this case API-17
Code:
$ emulator -avd avd_api_17 -no-window &
Get the framework
Code:
$ cd ~/Android/
$ mkdir _framework
$ cd _framework
$ adb -s emulator-5554 pull /system/framework .
Grab BOOTCLASSPATH
Code:
$ adb -s emulator-5554 shell cat init.rc | grep BOOTCLASSPATH > bootclasspath
I didn't have the tools used in this tutorial, so I included the steps for getting them
Decompile with baskmali
Code:
$ cd ~/Android/tools
$ wget https://smali.googlecode.com/files/baksmali-1.4.2.jar
$ cd ~/Android/_framework
$ java -Xmx1024m -jar ../tools/baksmali-1.4.2.jar -a 17 -c core.jar:core-junit.jar:bouncycastle.jar:ext.jar:framework.jar:telephony-common.jar:mms-common.jar:android.policy.jar:services.jar:apache-xml.jar -x framework.odex
The parameter -a for baksmali refers to the API we are working with.
Generate out.dex with smali
Code:
$ cd ~/Android/tools
$ wget https://smali.googlecode.com/files/smali-1.4.2.jar
$ cd ~/Android/_framework
$ java -jar ../tools/smali-1.4.2.jar out
Get internal and hidden classes using dex2jar
Code:
$ cd ~/Android
$ wget https://dex2jar.googlecode.com/files/dex2jar-0.0.9.15.zip
$ unzip dex2jar-0.0.9.15.zip
$ rm dex2jar-0.0.9.15.zip
$ cd _framework/
$ ../tools/dex2jar-0.0.9.15/d2j-dex2jar.sh out.dex
$ unzip out-dex2jar.jar -d framework-classes
Add these classes to plataform's default android.jar
Code:
$ cd ~/Android
$ unzip sdk/platforms/android-17/android.jar -d custom-android
$ cp -r _framework/framework-classes/* custom-android/
$ rm -r _framework
$ cd custom-android
$ zip -r ../custom-android.jar *
$ cd ..
$ rm -r custom-android
Create new extended platform
Code:
$ cd ~/Android
$ cp -r sdk/platforms/android-17 platforms-internals/android-17-internals
$ mv custom-android.jar platforms-internals/android-17-internals/android.jar
$ vi platforms-internals/android-17-internals/build.prop
ro.build.version.release=4.2.2
ro.build.version.release=4.2.2.internal
$ ln -s ~/Android/platforms-internals/android-17-internals ~/Android/sdk/platforms/android-17-internals
I use a symlink for keep it a little organized
Hack ADT
Code:
$ cd ~/Android
$ unzip eclipse/plugins/com.android.ide.eclipse.adt_22.0.4.v201307151829--741630.jar -d hacked_adt
Go to right folder
Code:
$ cd hacked_adt/com/android/ide/eclipse/adt/internal/project/
Find file where is our desired string
Code:
$ strings -f -a -t x * | grep "android\/internal"
Edit with an hex editor
Code:
$ bless AndroidClasspathContainerInitializer.class &
Here we change the l for the x.
Replace original file making a backup
Code:
$ cd ~/Android
$ cp eclipse/plugins/com.android.ide.eclipse.adt_22.0.4.v201307151829--741630.jar eclipse/plugins/com.android.ide.eclipse.adt_22.0.4.v201307151829--741630.jar.original
$ cd hacked_adt/
$ zip -r ../eclipse/plugins/com.android.ide.eclipse.adt_22.0.4.v201307151829--741630.jar *
$ cd ..
$ rm -r hacked_adt
This worked for me... thanks E:V:A
I got just one error related to a dropbox class, but i think this is not important... hope that
lenieto3 said:
...Start an avd running the desired API to modify in this case API-17... This worked for me... I got just one error related to a dropbox class, but i think this is not important...
Click to expand...
Click to collapse
Thanks and sorry for late reply. I'm very happy to hear these instructions still works with API-17! Could you also upload your hacked JAR somewhere so that people can save some time when experimenting?
I was just here to check-in and try to bump this thread to see if it is still useful to anyone.
E:V:A said:
Thanks and sorry for late reply. I'm very happy to hear these instructions still works with API-17! Could you also upload your hacked JAR somewhere so that people can save some time when experimenting?
I was just here to check-in and try to bump this thread to see if it is still useful to anyone.
Click to expand...
Click to collapse
ive got access to ActivityManager's hidden methods.
I want to use the removeTask method, but it keeps saying that I dont have the REMOVE_TASKS permissions even though I added it to the manifest (and turned off lint).
Permission Denial: removeTask() from pid=9963, uid=10179 requires android.permission.REMOVE_TASKS
Does someone know if there are any automated tools to do/performs steps 1-9?
I'd like to see a tool to automatically pull (from phone), extract and create a compatible android.jar.
@Mohammad_Adib: Sorry, this is the wrong thread for those type of questions.
see this link stackoverflow.com|questions|30656933|android-system-framework-jar-files
Hey guys,
I write this tutorial to help guys deodex individual apps and not all apps or not to do batch deodex.
There are few good tools to Batch Deodex Roms but I found one by one tutorial which was not properly framed...
Though the credits goes to the creator of the tool.
I dont take any credits for that tool and here I just write up a tutorail on how to do it.
Step by Step Tutorial:
- First of all download this zip file of the tools required for the process - Link
- Now, extract the files of the zip to any folder.
- Head over to the directory you extracted the tools. It will contain many files such as baksmali, smali, 7zip etc..
- Now press Shift+Right Click and select Open Command Window Here.
- Now just copy the apk and the .odex.art.xz and odex.xz files in that directory.
- Now in command prompt type the following commands.
Note: Replace * With the name of the apk. (If you dont get it see the Post #2 for eg)
Code:
7za x *.odex.xz
Code:
oat2dex.bat *.odex
Code:
oat2dex.bat *.odex temp.dex
Code:
java -jar baksmali-2.0.3.jar -a 21 -x temp.dex -o deodex
Code:
java -jar smali-2.0.3.jar -a 21 deodex -o classes.dex
Code:
7za u -tzip *.apk classes.dex
Now, the apk you initially coppied is now dexoded. Now you can use that apk the way you want
See post #2 for example
Reserved
Example:
Say I want to Deodex SystemUI for any lollipop rom.
Then, I would do the following
Code:
7za x SystemUI.odex.xz
Code:
oat2dex.bat SystemUI.odex
Code:
oat2dex.bat SystemUI.odex temp.dex
Code:
java -jar baksmali-2.0.3.jar -a 21 -x temp.dex -o deodex
Code:
java -jar smali-2.0.3.jar -a 21 deodex -o classes.dex
Code:
7za u -tzip SystemUI.apk classes.dex
The apk is now deodexed successfully. Enjoy!
hey mate, any chance you can upload a few small .apk files and matching .odex.xz files?
ive got a few test to run for a tool i made but cant because i dont have any android 5.0 devices
Dear everyone,
I'd like to backup all apps and their data and settings from my old phone (Android 4.0.4, have a root shell if needed) and restore them to a new phone (Android 10) which I don't want to root. I've considered the following options, but would be glad about some guidance.
1. Backup with adb backup, restore with adb restore
This would be the obvious choice, I guess. However, my old phone is an Xperia Ray with stock ROM, which cannot run adb backup.
If I try to backup an app, I get the following in adb logcat:
Code:
V/BackupManagerService( 290): Requesting full backup: apks=false shared=false all=false pkgs=[Ljava.lang.String;@2c36b0b8
I/BackupManagerService( 290): Beginning full backup...
D/BackupManagerService( 290): Starting backup confirmation UI, token=940595255
I/ActivityManager( 290): START {act=fullback flg=0x10000000 cmp=com.android.backupconfirm/.BackupRestoreConfirmation (has extras)} from pid 290
E/BackupManagerService( 290): Unable to launch full backup confirmation
D/BackupManagerService( 290): Full backup processing complete.
The "Unable to launch full backup confirmation" is because BackupRestoreConfirmation.apk is missing.
I downloaded a system image from https://dl.google.com/android/repository/sys-img/android/sysimg_armv7a-14_r02.zip, extracted the files with unyaffs, and tried installing the BackupRestoreConfirmation.apk with adb install. This fails with INSTALL_FAILED_DEXOPT because it's an odexed app.
Using a root shell, I copied the extracted BackupRestoreConfirmation.apk and BackupRestoreConfirmation.odex to /system/app and rebooted the phone. I can see that the files are there:
Code:
$ adb shell ls -l /system/app | grep -i 'backup'
-rw-r--r-- root root 88093 2011-11-24 00:00 BackupRestoreConfirmation.apk
-rw-r--r-- root root 11816 2011-11-24 00:00 BackupRestoreConfirmation.odex
-rw-r--r-- root root 84730 2012-05-08 20:51 GoogleBackupTransport.apk
However, it still does not show up among the system apps:
Code:
$ adb shell pm list packages -f | grep -i 'backup'
package:/system/app/GoogleBackupTransport.apk=com.google.android.backup
I was expecting an entry for com.android.backupconfirm.
Q: Am I missing anything to install it as a system app? Is there any configuration file it needs to be added to?
2. Backup with a modified adb backup, restore with adb restore
Since I have root access, would it be possible to replace some code on my device such that adb backup does not require a confirmation?
adb backup calls /system/bin/bu, which runs /system/framework/bu.jar. From https://android.googlesource.com/pl...fs/tags/android-4.0.4_r2.1/cmds/bu?autodive=0, it seems that this calls somewhere into https://android.googlesource.com/pl...roid-4.0.4_r2.1/core/java/android/app/backup/, but is not directly responsible for the confirmation dialog.
Going backwards instead, "Unable to launch full backup confirmation" is printed from https://android.googlesource.com/pl...android/server/BackupManagerService.java#4911, which lives in /system/framework/services.jar.
Q: How complicated is it to compile and install a modified version of services.jar/services.odex? Is this even possible in a live system?
3. Create .ab file without adb backup, restore with adb restore
Since I have root access, I can copy out all the files I want. An .ab file is a compressed .tar archive with a special 24-byte header. If I knew which files go into the .ab file, and maybe in which order, with which permissions and user ids, and how to create the 24-byte header, I could manually create the .ab files to feed to adb restore.
Q: Is there a generic recipe for creating a .ab file for an app? Or does each app decide individually which files to backup and restore?
Thank you for any hints!
May be this helps you:
Backup android app, data included, no root needed, with adb
Backup android app, data included, no root needed, with adb - android-backup-apk-and-datas.md
gist.github.com
jwoegerbauer said:
May be this helps you:
Backup android app, data included, no root needed, with adb
Backup android app, data included, no root needed, with adb - android-backup-apk-and-datas.md
gist.github.com
Click to expand...
Click to collapse
Thank you! Unfortunately, this also uses adb backup to pull the data, for which I need to find a way to install com.android.backupconfirm on my device.
I use ApkExport* from Playstore on my non-rooted 10+ to backup all my loaded apps.
Have done a full restore using only the stored copies; worked perfectly. Cut down load time substantially... took Playwhore out of the loop.
*freeware, no ads, no internet connection
blackhawk said:
I use ApkExport* from Playstore on my non-rooted 10+ to backup all my loaded apps.
Click to expand...
Click to collapse
Thank you! But if I see correctly, this only copies the .apk files (basically, the /data/app directory), but does not export their settings and data to be imported to a new device.
f0k said:
Thank you! But if I see correctly, this only copies the .apk files (basically, the /data/app directory), but does not export their settings and data to be imported to a new device.
Click to expand...
Click to collapse
This is correct. Probably better this way especially if the phone was compromised by malware.
My important apps that are hard to reconfigure are backed up separately. I deliberately picked ones that allow for complete backup like Poweramp, PD MDM and ColorNote.
f0k said:
Thank you! Unfortunately, this also uses adb backup to pull the data, for which I need to find a way to install com.android.backupconfirm on my device.
Click to expand...
Click to collapse
The mentioned missing APKs you can fetch here:
Root - Stock APK's
Directory of \m830\rom\app 10/12/2012 05:21 PM 143,392 AccuweatherDaemon.apk 10/12/2012 05:21 PM 3,064,214 AccuweatherWidget.apk 10/12/2012 05:21 PM 5,808,937 AccuweatherWidget_Main.apk 10/12/2012 05:21 PM 124,220 Activation.apk 10/12/2012 05:21 PM...
androidforums.com
jwoegerbauer said:
The mentioned missing APKs you can fetch here:
Root - Stock APK's
Directory of \m830\rom\app 10/12/2012 05:21 PM 143,392 AccuweatherDaemon.apk 10/12/2012 05:21 PM 3,064,214 AccuweatherWidget.apk 10/12/2012 05:21 PM 5,808,937 AccuweatherWidget_Main.apk 10/12/2012 05:21 PM 124,220 Activation.apk 10/12/2012 05:21 PM...
androidforums.com
Click to expand...
Click to collapse
The download link does not work any more. However, as described above, I already extracted the missing .apk and .odex from an official sysimg from https://dl.google.com/android/repository/sys-img/android/sysimg_armv7a-14_r02.zip. That .apk is 88093 bytes and the .odex is 11816 bytes. The link you posted had a .apk of 15089 bytes and misses the .odex. Not sure if this is relevant.
In any case, user "animania260" in the thread you posted had the same problem as me: I copied the .apk and .odex into /system/app and rebooted, but adb backup still fails with the same error, and /system/app/BackupRestoreConfirmation.apk is not listed among the installed apps (adb shell pm list packages -f).
Is there anything else that needs to be done to get the phone to accept a new system app? Or are there any special requirements for system apps? Do they need to be signed differently than what's included in the official sysimg, for example?
Another route could be to compile https://android.googlesource.com/pl....0.4_r2.1/packages/BackupRestoreConfirmation/ into a deodexed .apk and install it as a user app, but I don't know how to do that yet, and I don't know if https://android.googlesource.com/pl...android/server/BackupManagerService.java#4988 will just happily start a user app if it happens to provide an intent of the correct name.
f0k said:
I copied the .apk and .odex into /system/app and rebooted, but adb backup still fails with the same error, and /system/app/BackupRestoreConfirmation.apk is not listed among the installed apps (adb shell pm list packages -f).
Is there anything else that needs to be done to get the phone to accept a new system app? Or are there any special requirements for system apps? Do they need to be signed differently than what's included in the official sysimg, for example?
Click to expand...
Click to collapse
IMO the APKs in question must NOT get simply 1:1 copied into /system/app but also renamed
Example:
Code:
/system/app/BackRestoreConfirmation-1.apk
and additionally given 0644 permission. Phone has to get re-booted afterwards, too, if that's not automatically done.
But I may err as always ...
jwoegerbauer said:
IMO the APKs in question must NOT get simply 1:1 copied into /system/app but also renamed
Click to expand...
Click to collapse
Renaming the package did not help, but this time I started adb logcat directly after adb reboot, and found something relevant that came up early in the boot process:
Code:
I/PackageManager( 291): /system/app/BackupRestoreConfirmation-1.apk changed; collecting certs
I/dalvikvm( 291): DexOpt: mismatch dep signature for '/system/framework/core.odex'
E/dalvikvm( 291): /system/app/BackupRestoreConfirmation-1.apk odex has stale dependencies
E/dalvikvm( 291): odex source not available -- failing
W/PackageManager( 291): StaleDexCacheError when reading apk: /system/app/BackupRestoreConfirmation-1.apk
W/PackageManager( 291): dalvik.system.StaleDexCacheError: /system/app/BackupRestoreConfirmation-1.apk
W/PackageManager( 291): at dalvik.system.DexFile.isDexOptNeeded(Native Method)
W/PackageManager( 291): at com.android.server.pm.PackageManagerService.performDexOptLI(PackageManagerService.java:3080)
W/PackageManager( 291): at com.android.server.pm.PackageManagerService.scanPackageLI(PackageManagerService.java:3634)
W/PackageManager( 291): at com.android.server.pm.PackageManagerService.scanPackageLI(PackageManagerService.java:2963)
W/PackageManager( 291): at com.android.server.pm.PackageManagerService.scanDirLI(PackageManagerService.java:2775)
W/PackageManager( 291): at com.android.server.pm.PackageManagerService.<init>(PackageManagerService.java:1066)
W/PackageManager( 291): at com.android.server.pm.PackageManagerService.main(PackageManagerService.java:837)
W/PackageManager( 291): at com.android.server.ServerThread.run(SystemServer.java:167)
D/PackageManager( 291): No files in app dir /vendor/app
So if I interpret this correctly, there really is a problem with the signatures. Just out of curiosity, I tried whether apps in /vendor/app would be treated differently. I created /vendor/app, moved the .apk and .odex there and rebooted, but get the same error just with different paths.
Some googling informs me that this is probably because the /system/framework/core.odex on my device is not the same as the framework/core.odex in the sysimg I took the odexed BackupRestoreConfirmation.apk from.
From https://android.googlesource.com/pl...roid-4.2.2_r1/vm/analysis/DexPrepare.cpp#1142, it seems it would be trivial to just go ahead and replace the signatures of all dependencies in BackupRestoreConfirmation.odex (with a hexdump, I can see there are nine dependencies). Is the .odex signed to catch such a modification, or would it pass through? And how would I obtain the SHA-1 signatures from the source DEX files? My device apparently knows them.
/edit: They're part of the .odex header, the signature is at offset 0x34 and has 20 bytes, so I could copy out the SHA-1 signatures from the dependencies on my phone and implant them in BackupRestoreConfirmation.odex. But that signature check will be there for a reason, I assume the .odex will point at specific offsets in its dependencies and crash if the dependencies are not the original ones.
So I will either have to recompile BackupRestoreConfirmation.apk from source with WITH_DEXPREOPT=0 or to deodex the compiled one, so I don't need a .odex file at all.
I'm learning a lot more about the internals of Android than I ever intended to
Finally got around continuing this quest, and it worked! I deodexed the BackupRestoreConfirmation.apk, resigned it, installed it as a system app, and can now run adb backup on my Xperia Ray, Android 4.0.4 ICS.
For posterity, I am documenting all required steps (assuming a Linux machine).
1. Download and extract a stock system image
Download a system image for Android 4.0.4: https://dl.google.com/android/repository/sys-img/android/sysimg_armv7a-14_r02.zip
Unzip it.
Extract the image with unyaffs (can be installed with apt install unyaffs in Ubuntu):
Code:
mkdir /tmp/sysimg
unyaffs armeabi-v7a/system.img /tmp/sysimg
It will say Warning: Can't restore owner/group attribute, run unyaffs as root, that can be safely ignored, we do not need files to be owned by root.
2. Deodex BackupRestoreConfirmation.apk
Download smali and baksmali (https://github.com/JesusFreke/smali, find download link in the README), put the two .jar files somewhere (I assume /tmp)
Extract the .odex file. java -jar /tmp/baksmali*.jar x --help is pretty self-explanatory. I did:
Code:
mkdir /tmp/backuprestore
java -jar /tmp/baksmali*.jar x -a 14 -d /tmp/sysimg/framework -o /tmp/backuprestore/out /tmp/sysimg/app/BackupRestoreConfirmation.odex
Assemble the smali files into a .dex file. Again, java -jar /tmp/smali*.jar a --help is pretty self-explanatory. I did:
Code:
java -jar /tmp/smali*.jar a -a 14 -o /tmp/backuprestore/classes.dex /tmp/backuprestore/out
Add the .dex file to the .apk file. We will copy the .apk to be sure.
Code:
cp /tmp/sysimg/app/BackupRestoreConfirmation.apk /tmp/backuprestore
cd /tmp/backuprestore
zip BackupRestoreConfirmation.apk classes.dex
It is not needed to do a new zipalign. If you're curious, you can install it (in Ubuntu, sudo apt install zipalign) and run zipalign -c 4 BackupRestoreConfirmation.apk && echo aligned || echo not aligned to check it.
If you try to install the file with adb install BackupRestoreConfirmation.apk now, it will say: Failure [INSTALL_PARSE_FAILED_NO_CERTIFICATES], because it is not correctly signed any longer. We need to resign it.
Install signapk (in Ubuntu, sudo apt install signapk. If you want, you can first verify that it is indeed not signed:
Code:
jarsigner -verify BackupRestoreConfirmation.apk
It should say jarsigner: java.lang.SecurityException: SHA1 digest error for classes.dex.
The original .apk is signed correctly; with
Code:
jarsigner -verify -verbose -certs /tmp/sysimg/app/BackupRestoreConfirmation.apk
you will see that it was signed by "[email protected], CN=Android, OU=Android, O=Android, L=Mountain View, ST=California, C=US" with a 2048-bit key.
Create a key for signing. This can be done with keytool, but this will set up a keystore that will be left behind. Instead, I followed a guide from https://sites.google.com/site/delocatedsystems/android/howto/create-cert-signapk, using 2048 instead of 1024 bits:
Code:
openssl genrsa -out key.pem 2048
openssl req -new -key key.pem -out request.pem # this will ask for some data, make up something
openssl x509 -req -days 9999 -in request.pem -signkey key.pem -out certificate.pem
openssl pkcs8 -topk8 -outform DER -in key.pem -inform PEM -out key.pk8 -nocrypt
Finally, we can sign the .apk:
Code:
signapk certificate.pem key.pk8 BackupRestoreConfirmation.apk BackupRestoreConfirmation_signed.apk
mv BackupRestoreConfirmation{,_unsigned}.apk
mv BackupRestoreConfirmation{_signed,}.apk
And optionally verify it with jarsigner -verify BackupRestoreConfirmation.apk -certs -verbose.
3. Install BackupRestoreConfirmation.apk
If you just install it with adb install BackupRestoreConfirmation.apk, it will be installed as user app. If you then run adb backup, the confirmation dialog will appear as intended. But if you confirm it, you will get:
Code:
D/BackupManagerService( 292): acknowledgeFullBackupOrRestore : token=1892071259 allow=true
D/AndroidRuntime( 8310): Shutting down VM
W/dalvikvm( 8310): threadid=1: thread exiting with uncaught exception (group=0x2b542210)
E/AndroidRuntime( 8310): FATAL EXCEPTION: main
E/AndroidRuntime( 8310): java.lang.SecurityException: acknowledgeFullBackupOrRestore: User 10104 does not have android.permission.BACKUP.
(Uninstall again with adb shell pm uninstall com.android.backupconfirm if needed.) So the .apk must be installed as a system app to have the android.permission.BACKUP permission.
To do so, copy the .apk file to your device:
Code:
adb push BackupRestoreConfirmation.apk /data/local/tmp
Now open a root shell on the device. This can be done via an exploit I explained in another post. Assuming you are in a root shell on the device, do:
Code:
remount -o rw,remount /system
cat /data/local/tmp/BackupRestoreConfirmation.apk > /system/app/BackupRestoreConfirmation.apk
chmod 644 /system/app/BackupRestoreConfirmation.apk
remount -o ro,remount /system
exit
In my case, the app was picked up directly, without having to reboot the phone. Verify with:
Code:
adb shell pm list packages -f | grep -F backup
If it worked, the list will contain:
Code:
package:/system/app/BackupRestoreConfirmation.apk=com.android.backupconfirm
Otherwise you may need to reboot your phone with adb reboot.
When you now try to backup an app with adb backup -f theappname.ab -apk com.theappname (where com.theappname is taken from the list of user apps produced with adb shell pm list packages -3), you may find that instead of a 0-byte file that you get with a missing BackupRestoreConfirmation.apk, you get a 41-byte file, which is only a moderate improvement. In adb logcat, you may find:
Code:
V/BackupManagerService( 811): Requesting full backup: apks=false shared=false all=false pkgs=[Ljava.lang.String;@4181ffc8
W/BackupManagerService( 811): Unknown package '-apk' 'com.theappname', skipping
It may not be apparent at first, but the quotes around -apk and com.theappname in the error message are not put there by BackupManagerService, they are introduced by recent versions of adb to safeguard against a shell injection. This is why -apk is not detected as a flag, and the package name is not recognized as a package. The solution is to downgrade to an earlier version of adb, as explained in more detail on https://android.stackexchange.com/a/132921.
To check the version of adb on your computer, run:
Code:
adb version
To check the version of adb on the phone, run:
Code:
adb shell adb version
In my case, the phone is running 1.0.29, but downgrading adb to 1.0.31 was enough. Precompiled versions are available for Linux, Mac, Windows.
Finally, you can backup apps with adb backup (at least those apps which support it). Phew!
(PS: If you want to run adb backup -shared, you will need to deodex and install SharedStorageBackup.apk. Didn't try.)