I was just wondering... when you download an app from the market, the apk file is clearly saved somewhere... but where? I mean, sometimes the download is successful, but the installation fails. instead of downloading the file again, I'd like to launch the downloaded apk and re-install directly. Anybody has a clue?
/system/data
EDIT: Oh, nevermind, I didn't realize you meant when the install fails.
If not on root/data/app than try root/mnt/asec/ and they have many folders wich have inner files that name "pkg.apk" but apk icon say about that file was installed...You can copy in external drive and change on original name.
Regards
miro666 said:
If not on root/data/app than try root/mnt/asec/ and they have many folders wich have inner files that name "pkg.apk" but apk icon say about that file was installed...You can copy in external drive and change on original name.
Regards
Click to expand...
Click to collapse
Thanks!
ZioGTS said:
...when you download an app from the market, the apk file is clearly saved somewhere...
Click to expand...
Click to collapse
/cache
The size of this partition may be the root of your install failed problems. When I first flash JVR, I hit the marked like a madman and just hit download on all the apps I regularly downloaded. The /cache partition quickly filled up and half of my installs failed. To make matters worse, the half downloaded files stayed in /cache and I had to manually remove them to regain the space (although I assume they would have been cleaned up next boot).
If the app installs successfully the apk is deleted from /cache and you can then find it in the locations mentioned by miro666.
Hi all,
My question is aimed to head deep into the Android OS and the flashing process itself. I know that if I flash my phone with a new ROM that system files are replaced and also some other files too. My question is how is this done? Is there an exact order in which the files have to be replaced, and are they "just" overwritten or are they deleted first and then the new ones put in place?
Forgive me if this question has already been answered. I really tried my best to find answers on Google and in here.
Thanks in advance for any enlightening comment.
Open up an update-script and your dilemma will be solved
Sent from my GT-I9000 using Tapatalk
Essentially, like the previous reply mentioned the android OS is heavily partitioned, but has a lot of sneaky mount points to hide this fact.
Really all a CWM flashable zip does is follow a script, easily readable in the zip, to copy files throughout the OS partition.
If you look in the zip you'll see a few things, the biggest thing here is the /System folder. It contains the entirety of the system partition that makes your ROM /Your ROM/. Also you'll see boot.img which is the kernel (and CWM). A modem.bin file is also present, but to my understanding is only flashed if one is not currently present.
When looking at CM9's zip, you'll see an updater.sh. This is the shell script that's run on using CWMs install function.
It's process checks a few environment things and installs (copys over /system) based on this.
Check out the script, it's really interesting.
Thanks to all of you
I will have a look inside a script then.
LG BIN/TOT Extractor
This is a tool for extracting LG Bin/Tot Firmware files.
I update the git a lot more than what I update the thread so check there for latest news.
Features
Split Bin file into relevant partitions
Split Tot file into relevant blocks and merge blocks into partitions
Display AP Header
Display GPT Header
Extract Header from Bin/Tot File
Features I like to implement (and probably won't get around to)
Extracting boot img (The tools currently available don't work in all cases and it's very easy to read the header since it's open source.)
Extracting ext4 partitions. So that it's easy to access the file. Theres already other tools that can do this so this isn't essential.
Mergeing tot partitions based on data from partitions itself and not GPT
Inject Alternate Data into partitions. I'll block access to X-loader,U-boot and GPT so that You can't kill your phone.
Source
https://github.com/Xonar/LGBinExtractor
Confirmed to work with
Quite a few phones.
I lost track of which ones work.
To check just run with -daph. You'll get file information if it works and either garbled data or an error message if it doesn't.
If your phones not supported follow the steps on git readme.
Thanks
SnowLeopardJB - for lots and lots of testing
navossoc - his tool that extracts kdz and wdb files
vim1 - D821 support
scotty755 - LGL22 support
tkawajir - L-04E and LG G Flex F340K support
If you feel I forgot to thank you, msg me and I'll add you.
If it can extract BIN files then yes. We believe the nandroid V30* of KU5900 that was supplied was incomplete. So If KDZ is converted to BIN and FLS (which we can), then extract contents of BIN, then you can have complete files without looking for Koreans and Chinese to relay that the nandroid was incomplete and can have untampered files.
xonar_ said:
Question to other Devs
Will you use a tool like this or am I wasting my time?
Is a tool like this allowed or would it be considered reverse engineering? (If its not allowed I'm going to stop IMMEDIATELY)
Click to expand...
Click to collapse
Yes I will. If I myself can build a program to extract this EFI partition..
It is reverse engineering, but I don't know if it's legal or not (in this case), but for me it's legal as I'm considered this to educational purpose
Many others tool was created to have purpose like this, for example http://psas.revskills.de/?q=node/5
-CMIIW-
I've attached an image of the system partition of the V20E_00 for you guys to see.
I am going to download the v30H_00.kdz today. So I'll keep you posted about how the extracting goes. I probably won't have time to check it out until the weekend so please don't hold your breath.
I've only recently managed to find the necessary information about the ext4 file system to integrate the functionality into my tool. For now Ext2Read can extract the ext4 file system just fine. I'll add that somewhere over the weekend (Provided something doesn't come up).
Could you as soon, as you are able to unpack it fully maybe upload a complete backup of the system partition and also system2, cause we think, that in the nandroid there are some files missing and we need those, to probably be able to boot that system. Great job btw
Thanks for the positive feedback.
I am getting the v30h_00.kdz in a few hours (I got a friend to download it for me, I don't have that much cap ).
There is no way I will be able to upload the file since it will be big but if it works I'll post the tool and how to do it.
GitHub is giving me an error : "Page did not respond in a timely fashion". I am going to try again tonight to post the source.
I already tried to extract the bin files, but I didn't see any pattern to know where start or ends a partition.
Some partitions you can identify by it's header and try to extract the file size from there (i did that with recovery.exe).
If you know for sure the partition name and the address, I can improve the recovery.exe to patch always the right partition.
So, what is the trick?
[]'s
navossoc said:
I already tried to extract the bin files, but I didn't see any pattern to know where start or ends a partition.
Some partitions you can identify by it's header and try to extract the file size from there (i did that with recovery.exe).
If you know for sure the partition name and the address, I can improve the recovery.exe to patch always the right partition.
So, what is the trick?
[]'s
Click to expand...
Click to collapse
The first meg of the file contains the names of the data blocks size on file,size on disk and where they start on file. I'll post exactly how it is set out later.
The data blocks aren't only partitions though for example the first one is the GPT header with it's corresponding entries and also some blocks are empty.
I recognized the start the two partitions from your tool.
Sent from my LG Optimus Black
xonar_ said:
The first meg of the file contains the names of the data blocks size on file,size on disk and where they start on file. I'll post exactly how it is set out later.
The data blocks aren't only partitions though for example the first one is the GPT header with it's corresponding entries and also some blocks are empty.
I recognized the start the two partitions from your tool.
Sent from my LG Optimus Black
Click to expand...
Click to collapse
You are talking about the first 1MB from BIN? right?
They are using little endian or big endian to represent the numbers?
The name of the sections I already knew, but never found the initial offset.
I will try to take a look later.
[]'s
navossoc said:
You are talking about the first 1MB from BIN? right?
They are using little endian or big endian to represent the numbers?
The name of the sections I already knew, but never found the initial offset.
I will try to take a look later.
[]'s
Click to expand...
Click to collapse
Yes the BIN. They are using little endian. All the offsets and sizes are in LBA's (512 bytes in this case) with LBA 0 starting at 0x100000.
Sent from my LG Optimus Black
Source of Bin Fls Extractor (So far)
GitHub isn't working out as planned. The client stopped downloading in the middle and I don't want to waste more cap so here is the source as an attachment.
This is still a work in progress and is only confirmed to work with v20E_00 South Africa.
Linux users can just mount the *.img file of system to access it. Windows users have to use a tool like Ext2Read. Mac users I'm not sure : Google it.
EDIT : I wont be able to get the v30 kdz for another day unfortunately. Feel free to try and change my tool to work with it.
EDIT2: These sources are old. I'll upload my fixed ones later. Reads in chunks and works on P970 and KU5900 ( I don't have any other files to test it with but it should work with almost all BIN files extracted from kdz files )
xonar_ said:
GitHub isn't working out as planned. The client stopped downloading in the middle and I don't want to waste more cap so here is the source as an attachment.
This is still a work in progress and is only confirmed to work with v20E_00 South Africa.
Linux users can just mount the *.img file of system to access it. Windows users have to use a tool like Ext2Read. Mac users I'm not sure : Google it.
EDIT : I wont be able to get the v30 kdz for another day unfortunately. Feel free to try and change my tool to work with it.
Click to expand...
Click to collapse
Nah! The damn trick was the 512 bytes + 0x100000 base.
I never thinked about it...
I take a look at your code, I understand the whole concept now.
I have successfully extracted the system.img and system2.img from the V30H_00.kdz
Nice, maybe later I can do some modifications on recovery.exe, so they can find always the correct partition for recovery.img. (without the user choose one)
[]'s
navossoc said:
Nah! The damn trick was the 512 bytes + 0x100000 base.
I never thinked about it...
I take a look at your code, I understand the whole concept now.
I have successfully extracted the system.img and system2.img from the V30H_00.kdz
Nice, maybe later I can do some modifications on recovery.exe, so they can find always the correct partition for recovery.img. (without the user choose one)
[]'s
Click to expand...
Click to collapse
Nice! Great job you guys. :good:
navossoc said:
Nah! The damn trick was the 512 bytes + 0x100000 base.
I never thinked about it...
I take a look at your code, I understand the whole concept now.
I have successfully extracted the system.img and system2.img from the V30H_00.kdz
Nice, maybe later I can do some modifications on recovery.exe, so they can find always the correct partition for recovery.img. (without the user choose one)
[]'s
Click to expand...
Click to collapse
can you upload system files asap?
George Jetson said:
can you upload system files asap?
Click to expand...
Click to collapse
http://forum.xda-developers.com/showpost.php?p=31443301&postcount=270
Thanks to navossoc there
navossoc said:
Nah! The damn trick was the 512 bytes + 0x100000 base.
I never thinked about it...
I take a look at your code, I understand the whole concept now.
I have successfully extracted the system.img and system2.img from the V30H_00.kdz
Nice, maybe later I can do some modifications on recovery.exe, so they can find always the correct partition for recovery.img. (without the user choose one)
[]'s
Click to expand...
Click to collapse
That's good news.
I won't be able to work on the program during the rest of this week. With the system files extracted there's nothing that needs to be urgently done.
Next Step is to to try and build the BIN from other files. I think I can improve on your recovery.exe to add su binary and apk aswel (Might take a bit longer since I need to extract the ext4 partition, add su then put it back together )
Well, it's just a beta, because it use too much ram to write the files.
I need to read the file in chunks, but, for now it's a good prototype, we can using it.
extract.7z
Code:
CRC32: 2199d10f
MD5: 5b8d8031ff5d66ec2832d182e98505be
SHA-1: b6d729a20d4370e25ebc4eddfc27e25673b1d2f2
To use the tool is just run...
Code:
extract.exe filename_AP.bin
It should work on any bin file, tested on P920, P970 and KU5900.
Please report any error.
[]'s
Thanks navossoc its working well on ginger p970 bin file.
Great stuff thanks alot! You to make a great team.
Sent from my LG-P920 using xda app-developers app
Now how can we make a new bin file with that img files?
Hi,
I hope this is the write location for my post.
I have a HTC ONE rooted, android 4.3
I have a problem with my GPS: it doesn't lock any satellite. Reading on forum, I found that the problem may be the setting of gps.conf file in /system/etc.
In fact, checking it, I found that the NTP_SERVER set was for north.america, while I'm in Europe.
I would like to modify or replace it, but I'm experiencing some problem. Using Root Browser it seems to be able to modify it, but after rebooting the device it is exactly the same before the editing. I tried using other editors as ES File Explorer, but when I try to modify the file, it says "read only file system".
It makes me thing that also the other editor is not able to modify the file, since after reboot it is actually un-edited.
What do you think? how can I actually write in file system and actually modify gps.conf?
Thank you in advance
Let me add another detail: I tried to create a new empty file in the same folder with Root Browser. It seems to be able to create it, but after rebooting the device it desappears..so I guess I actually can't modify/write in the file system..
aerosmike said:
Hi,
I hope this is the write location for my post.
I have a HTC ONE rooted, android 4.3
I have a problem with my GPS: it doesn't lock any satellite. Reading on forum, I found that the problem may be the setting of gps.conf file in /system/etc.
In fact, checking it, I found that the NTP_SERVER set was for north.america, while I'm in Europe.
I would like to modify or replace it, but I'm experiencing some problem. Using Root Browser it seems to be able to modify it, but after rebooting the device it is exactly the same before the editing. I tried using other editors as ES File Explorer, but when I try to modify the file, it says "read only file system".
It makes me thing that also the other editor is not able to modify the file, since after reboot it is actually un-edited.
What do you think? how can I actually write in file system and actually modify gps.conf?
Thank you in advance
Let me add another detail: I tried to create a new empty file in the same folder with Root Browser. It seems to be able to create it, but after rebooting the device it desappears..so I guess I actually can't modify/write in the file system..
Click to expand...
Click to collapse
You need an unsecured kernel (/system writable) to write to /system partition of the htc one, not only root.. Otherwise, all changes will be reverted at reboot like you are experiencing.
Kernels for htc one here
And note that modifying/deleting files in /system will probably prevent you to install future ota unless you revert the change you have made. There is a md5 checksum of many files in /system before the ota installs. If the md5 cheksum doesn't match then the ota will not install. This might not apply to the .conf file you want to edit but just in case, make a backup of that file before. So if the next ota fail, you'll know why.
alray said:
You need an unsecured kernel (/system writable) to write to /system partition of the htc one, not only root.. Otherwise, all changes will be reverted at reboot like you are experiencing.
Kernels for htc one here
And note that modifying/deleting files in /system will probably prevent you to install future ota unless you revert the change you have made. There is a md5 checksum of many files in /system before the ota installs. If the md5 cheksum doesn't match then the ota will not install. This might not apply to the .conf file you want to edit but just in case, make a backup of that file before. So if the next ota fail, you'll know why.
Click to expand...
Click to collapse
Thank you very much
Long story short, had to send the phone in for repair, so I did the obligatory backups and unroot/reflash of factory images.
I don't have TWRP, too much hassle together with magisk for taking OTAs, so I took my backups (/data, /data/media) with tar/split/gzip.
Did my due dilligence to make sure the backup was good - resulting tar file extracts perfectly fine on my linux desktop.
Got my phone back, rerooted, ready to restore now. However, on the device, it stops extracting about 20 files in with 'invalid tar format'.
Tried again with busybox tar, and this time I get 'invalid tar magic'. Normally this suggests the tar is corrupted, but that doesn't explain why it's fine on my desktop. Note that the desktop archive I extracted is identical, e.g. it is the same one copied from the SD card I'm trying to restore now. What gives, since it's the same tar that created it in the first place... I've tried multiple versions/copies (this was a split archive since it was over 4GB in size - so I even recombined it on my host PC and pushed it to internal storage over ADB.) gzip has no issues with the outer compression (e.g I can gunzip the tar.gz fine) so the file itself doesn't seem corrupted.
Any suggestions on how I can get my /data back? Unfortunately I cannot just copy the files extracted on my desktop as this would mangle the permissions... and manually trying to fix them for the umpteen-hundred various folders is not practical...
I guess I'm hoping someone in the know might be able to point me to a different version of tar, or another tool (already tried cpio -H tar, not supported on android) that would extract things successfully.
I managed to get things to work by using a later version of tar from https://forum.xda-developers.com/android/software/utils-data-recovery-tools-testdisk-t3709380
However, I've now hit a new issue. After extracting to /data/data, or /data/app, the files are there, but vanish after a reboot, so the restore is incomplete.