Related
OK - I keep a selection of apps on my card, so if I have to reinstall there they are. However, when you install java apps, they vanish from that folder. Where do they go?
Java applications are run in an "application" conveniently named "Java". It's found amongst the other application, start it and launch your java applications from it!
I could be wrong here but I think he is asking, when they are installed, where are they installed to, not how do you run them. Where do the physical files that the java app runs reside once installed.
I to would like to know this as well.
Yeah that's pretty much it - it's a bit irksome because I have a folder on my card called "wm6 programs", which contains the apps I reinstall if I have to do a hard reset, the problem is that Java apps disappear from that folder once you have installed them. So the only way around it is to keep another copy and then copy the file when you want to reinstall it - thus always leaving you with a copy.
read my MIDlet bible.
here is the helpful link to it
http://forum.xda-developers.com/showthread.php?t=339579
As much as it is great piece of work you have done there, I have no interest in midlets and java other than where they are installed to, is there any chance you can inform me as to the installed files location. I read through a lot of what you wrote but cant see anything about file locations other than main memory or storage card.
Thanks in advance
funem said:
here is the helpful link to it
http://forum.xda-developers.com/showthread.php?t=339579
As much as it is great piece of work you have done there, I have no interest in midlets and java other than where they are installed to, is there any chance you can inform me as to the installed files location. I read through a lot of what you wrote but cant see anything about file locations other than main memory or storage card.
Thanks in advance
Click to expand...
Click to collapse
depends on the JVM you use, as is also explained in the main chart ( http://www.winmobiletech.com/092007MidletBible/CompatibilityAndMain.html ) of the bible, in the "Where are deployed MIDlets kept?" row. Did you thoroughly check out that row? It does list all the specific directories.
I will have another look, to be honest I got a headache reading the thing, hats off to you though its a pretty comprehensive bit of documentation.
funem said:
I will have another look, to be honest I got a headache reading the thing, hats off to you though its a pretty comprehensive bit of documentation.
Click to expand...
Click to collapse
Yeah, I know one needs a LOT of time and patience to understand my roundups & bibles - after all, I write them with the aim of including all the information a user would ever need (just like the question of data directories in your case).
Hi everyone, as many of you guys have noticed, the newer firmwares do not come with the Amazon MP3 application. For those of you who want this, here is a tutorial on installing.
First, download the com.amazon.mp3.zip file uploaded, and place it on your desktop. DO NOT OPEN IT OR EXTRACT IT. Change .zip extension to .apk. For those of you who do not know how to do that, hit Start> My Computer> Organization> Folder and Search Options> and Uncheck "Hide Extentions for Known File Types". Then, delete the .zip extension and type in .apk. Have your G1 ready and plugged in, as you will be using ADB to install this program.
Open up command prompt and type:
cd desktop
adb install com.amazon.mp3.apk
exit
It should now be installed!
For those of you who do not have ADB installed for whatever reason, place the com.amazon.mp3.apk onto your SDcard. Then, using a file manager on your G1 (I use OIfilemanager) navigate to the location where the file is placed and install.
Also, the com.amazon.mp3.apk can also be extracted directly from RC and JF 1.4x builds.
NOTE TO MODS: I understand that Amazon MP3 is not an open source application. Therefore, if for any reason if you guys do not feel that uploading this apk is allowed, feel free to remove this post.
Paying $1 per mp3 can add up over time
With RC 33 i wanted to removed this program, now that JF 1.50 removed automatically, do you believe that i will tried this? But thanks anyway...
PS- People DL music MP3's on theirs PC' for free, Amazon Sucks!
Sometimes I find Amazon MP3 useful for previewing a CD while I am at the library.
By the way, there is no need to distribute the apk here when anyone can just extract it themselves legally from an official update.zip
jashsu said:
Sometimes I find Amazon MP3 useful for previewing a CD while I am at the library.
By the way, there is no need to distribute the apk here when anyone can just extract it themselves legally from an official update.zip
Click to expand...
Click to collapse
Yeah I understand that, I'm just saving them the trouble of having to do it themselves. However, when you say "legally" do you mean distributing this apk is illegal? If so I will remove it.
SolemnWishing said:
However, when you say "legally" do you mean distributing this apk is illegal? If so I will remove it.
Click to expand...
Click to collapse
It's not expressly forbidden. The general stance on xda is as long as the software in question isn't payware, then it is okay (of course a mod is free to make a judgement otherwise). However, everyone should have a RC33 or somesuch build lying around that they can extract the file from themselves anyway.
Seems that most folks don't appreciate the usefulness of Amazon MP3 as a source of track preview. I just wish that it still integrated into ShopSaavy and CompareEverywhere. Used to be you could scan a barcode of a CD and it would pull up the CD on Amazon MP3. If anyone knows how to make this work with current software versions, let me know.
Thank you for the explicit directions. This worked great on my G1 and my friend's using a mac.
Well, I guess that means we will wait for a mod to say something... next in line.. PDFviewer.
Okay, PDFviewer will not work on my JF1.50 build. Just for fun I also tried to push the H build camera and the H build dialer. The pushed camera resulted in the camera app disappearing all together along with the camcorder, gallery and picture frame widget. The H build dialer caused the phone to be completely unresponsive.
Remember, always use a Nandroid backup when attempting risky procedures
SolemnWishing said:
Well, I guess that means we will wait for a mod to say something... next in line.. PDFviewer.
Okay, PDFviewer will not work on my JF1.50 build. Just for fun I also tried to push the H build camera and the H build dialer. The pushed camera resulted in the camera app disappearing all together along with the camcorder, gallery and picture frame widget. The H build dialer caused the phone to be completely unresponsive.
Remember, always use a Nandroid backup when attempting risky procedures
Click to expand...
Click to collapse
If you want to extract features from Haykuro's H build for 1.50 installation, I suggest you hook up ddms so you can get realtime debugging and see what libraries/functions are being called that are causing problems. It should work in the emulator too.
By the way PDFViewer's dependencies have been well established, but the program checks some unknown properties of the build and will refuse to run for non-HTC builds. Decompiling the dex might lead to clues as to what it is and how to workaround it or patch the apk. I'm actually hoping it will just run unmodified on the official T-Mo 1.5 rom expected any day now.
jashsu said:
If you want to extract features from Haykuro's H build for 1.50 installation, I suggest you hook up ddms so you can get realtime debugging and see what libraries/functions are being called that are causing problems. It should work in the emulator too.
By the way PDFViewer's dependencies have been well established, but the program checks some unknown properties of the build and will refuse to run for non-HTC builds. Decompiling the dex might lead to clues as to what it is and how to workaround it or patch the apk. I'm actually hoping it will just run unmodified on the official T-Mo 1.5 rom expected any day now.
Click to expand...
Click to collapse
hehehhe! We can always dream can't we...
lol HTC dream.. well, I do not know how to work apps, or port them or anything, so that is pretty much out of the question. Ill just stick with the obvious ones.
Much thanks!! I wanted Amazon back.
thanks
works on JF flawless. no issue yet. Thanks.
I installed the Amazon MP3 apk night before last and found that the search function wouldn't open its search box. I uninstalled and then pushed it to /system/app via adb and now it works just fine. FWIW, I have apps on SD (the symlink version).
That is good, and does anyone know if the Teeter game from the original Haykuro H build requires some sort of special resource or something? As the game installs, but force closes on startup.
thank you very much for this... anybody got a fix for myfaves???
jashsu said:
If you want to extract features from Haykuro's H build for 1.50 installation, I suggest you hook up ddms so you can get realtime debugging and see what libraries/functions are being called that are causing problems. It should work in the emulator too.
By the way PDFViewer's dependencies have been well established, but the program checks some unknown properties of the build and will refuse to run for non-HTC builds. Decompiling the dex might lead to clues as to what it is and how to workaround it or patch the apk. I'm actually hoping it will just run unmodified on the official T-Mo 1.5 rom expected any day now.
Click to expand...
Click to collapse
hehehe. the properties aren't unknown. It's a library, and 2 framework files.
TheDudeOfLife said:
hehehe. the properties aren't unknown. It's a library, and 2 framework files.
Click to expand...
Click to collapse
So you have PDFViewer working without the "Only for HTC devices" nag screen?
Haha mind enlightening us??
someone run some diffs on thedudes libs and framework files =P!
Hi All,
Here is my second contribution to the Android community, android2sd!
I tried to make the installation a bit more straight forward and the readme very verbose.
There is NO going into recovery and wiping of the Android to install this construct. (Of course you can if you want to have a clean slate to build from but it is by your choice only!)
Remove .zip from filename, then unrar (sorry to zip users, zip was too big) the package and copy the android2sd.sh install script to the Android say /data/local and make executable with something like chmod 0750 and copy the android2sd.img install image to the sdcard. (Detailed instructions are in the readme file.) Once the install is complete, you can delete both install files.
Execute the script {where ever you installed it}ie:
/data/local/android2sd.sh and follow the instructions.
Included are several of my scripts (updated from the ones in data2sd) and the rules still apply, adjust or remove as you see fit. The readme explains them all.
I have noticed an improvement in speed based on the install, but you can judge for yourself and tweak as you see fit!
The construct uses Overlay Profiles to overlay the Android system and thus any changes to the Android once loaded, are actually done to the overlay profile thus you have like a safe mode which is the untouched Android under the overlay.
Hope you find it useful!
Darkstrumn
Darkstrumn said:
Hi All,
Here is my second contribution to the Android community, android2sd!
I tried to make the installation a bit more straight forward and the readme very verbose.
There is NO going into recovery and wiping of the Android to install this construct. (Of course you can if you want to have a clean slate to build from but it is by your choice only!)
Remove .zip from filename, then unrar (sorry to zip users, zip was too big) the package and copy the android2sd.sh install script to the Android say /data/local and make executable with something like chmod 0750 and copy the android2sd.img install image to the sdcard. (Detailed instructions are in the readme file.) Once the install is complete, you can delete both install files.
Execute the script {where ever you installed it}ie:
/data/local/android2sd.sh and follow the instructions.
Included are several of my scripts (updated from the ones in data2sd) and the rules still apply, adjust or remove as you see fit. The readme explains them all.
I have noticed an improvement in speed based on the install, but you can judge for yourself and tweak as you see fit!
The construct uses Overlay Profiles to overlay the Android system and thus any changes to the Android once loaded, are actually done to the overlay profile thus you have like a safe mode which is the untouched Android under the overlay.
Hope you find it useful!
Darkstrumn
Click to expand...
Click to collapse
Damn man. Good work.
sounds interesting, what is this all about?
brilliant?!? I think.
So basically, this is a non-destructive method that enables us to run new roms on the G1 without flashing? Am I reading this right? If so... wow.
edit: or, erm... maybe not... i think i've been up too long. Gonna have to watch this thread to get a better grasp on this. interesting nonetheless.
Rename To RAR
Darkstrumn said:
Remove .zip from filename, then unrar (sorry to zip users, zip was too big) the package and copy the android2sd.sh install script to the Android say /data/local and make executable with something like chmod 0750 and copy the android2sd.img install image to the sdcard. (Detailed instructions are in the readme file.) Once the install is complete, you can delete both install files.
Click to expand...
Click to collapse
very interesting .. at first i failed to see this part as i'm sure many pay skip over the whole "rename to rar" thing - LOL - so this loads profiles from the SD to the phone
for anyone having trouble with the whole "rename" process try this:
http://files.lucidrem.us/jf/android2sd.rar
as i know windows with hidden file extensions does not allow a rename easily
So what exactly does this do? I see install instructions, but no description.
Overlay Profiles...
tr.slate said:
So what exactly does this do? I see install instructions, but no description.
Click to expand...
Click to collapse
Well,
I've worked up the natural progression to this XXX2SD business, and have made an Android2SD construct which can expand the Android similarly to the the previous constructs, but puts /system, /data and /cache on sd.
So let me explain the overlay thing:
An overlay profile is a snapshot of the Android file system, namely /system, /data, and /cache.
The initial profile is called 'android2sd' and is a snapshot of your android at the time of install, plus the file system structure as explained in the readme adding the mnt/ dir structure and additional scripts in bin/ (which you can remove or adjust as you need).
Typically I reckon folks would only have the one profile and under it your original Android. But you can create additional profiles and set them up however you like. The overlay is overlayed on top of the Android file system with any changes or edits to the system affecting the profile and not the Android under.
The effective change is that the /system /data/, cache are moved to the sdcard thus expanding them to however large your sdcp2 is; on a class 6 card also improving access time.
A second benefit is that the underlying Android is safe from alteration and can be booted into like a 'safe mode'. (It can also serve as the base for new profiles, or you can make new profiles from active overlays. These snapshots can serve as a form of backup, but that is a fringe benefit.
It cannot protect the Android from update.zip installs exactly, as those will modify the Android directly, but say you try a theme and it gafs your 'droid...you can reapply the firmware update to clean out the theme, then copy the desired profile back to the Android and restore the Android to the state of the profile. (I would recommend having a 'base' profile of the Android but not using that as an active profile which will thus serve as a backup) Note: To restore the Android as described above, you cannot restore using a profile with 250+ apps in /data as the Android doesn't have the space for it!
Originally I used unionfs for the overlays but it was too slow.
Hope that explains things here; the readme has far more detail.
I've gotta go, but if I see that I've been as clear as mud, I'll try to explain better when I have more time.
Hmm just out of curiosity: What are you using now? Bind mounts?
I got a little bit lost in setup, I am not sure if I had problems because I was using Cyanogens latest or something else but either way Im going back to JF to try this.
I installed it using the "-COMMIT" addition
But when I made it to installing/linking apps things wouldnt link
Maybe I will let a few other people try it first.
More info...
[email protected] said:
Hmm just out of curiosity: What are you using now? Bind mounts?
Click to expand...
Click to collapse
Yes. Originally it was to have a multi profile layered system using unionfs: union0 the ro base snapshot and union1 the rw profile containing the copy-on-write data. But as the tests went on, the unionfs was too slow to use for /data; Android is unforgiving of unresponsiveness and was ANR'ing the apps that didn't respond fast enough.
The faster bind mount means that union1 is now not used and union0 is rw.
The reason I wanted the union0,union1 path was that the union0 could serve as base and various profiles could be layered over any part of the file system granting "Lego" like flexibility in how the user could adjust their a2sdLoader.sh script (the android2sd loader which controls the overlay process).
You could have a pristine base and several "change" profiles that you layered to your liking and could change any sub layer to different effect.
While you still can under this paradigm, it is not as compact.
But the unionfs option is not completely done away with. It can still be used for the above layering but shouldn't be used for that apps and package system.
An example of the layering I'm on about:
The Android 0-layer which the base layer is a snapshot of.
The base layer is pristine (fully configured settings, but minimal apps loaded, maybe a particular base launcher layout and wallpaper).
A change profile containing my apps and package system
A change profile containing a version of etc with reconfigured bluetooth settings.
A change profile with a theme (manually installed, or snapshot to profile and restored to pristine)
Now I could take these 4 profiles and arrange several different setups:
'base' with all apps loaded, themed with custom bluetooth
'base' with all apps loaded, themed with normal bluetooth
'base' with all apps loaded with custom bluetooth
'base' with all apps loaded with normal bluetooth
'base' with all apps loaded
'base' themed with with custom bluetooth
'base' themed with normal bluetooth
'base' with custom bluetooth
'base' with normal bluetooth
...
Those would be set to serve as the ro union0 and the rw union1 which will hold the copy-on-write changes to the overlay (which preserves the sub layers)
You could have several more theme profiles and have a script that randomly chooses one at boot...
You could simply use the overlay to protect a favored configuration. Should anything untoward happen such as accidentally damaging the packages.xml file while experimenting with the system, you could simply delete the change profile, make a new blank change profile and the damaged files are undone.
The things one can do with the overlay concept are limited only by your imagination and need (and if they slow down app processing too much causing ANR's)
It vary well could if done correctly allow one to have multiple roms as profiles and switch them based on the selected profile, but I have yet to experiment on that...I reckon that is my next move! (Note that this path would have a high space cost as the roms are about 40MB zipped!)
brandenk said:
I got a little bit lost in setup, I am not sure if I had problems because I was using Cyanogens latest or something else but either way Im going back to JF to try this.
I installed it using the "-COMMIT" addition
But when I made it to installing/linking apps things wouldnt link
Maybe I will let a few other people try it first.
Click to expand...
Click to collapse
Taken from [Rom] CyanogenMod:http://forum.xda-developers.com/showthread.php?t=518851
"DO NOT RUN ANY OTHER APPS2SD APPLICATIONS ON THIS BUILD. YOU WILL BREAK YOUR SYSTEM. THEY ARE NOT NECESSARY BECAUSE THIS ROM WILL DO A2SD AUTOMATICALLY AND BETTER!"
The android2sd construct pretty much falls into the A2SD category and thus is likely the reason you had issues with the install.
My Android is based on JF 1.51... and thus your mileage will vary based on the rom you are using. I reckon with a rom derived from theh JF roms, the install may work as intended.
As I go into the next construct build process, I will see if I can't make it multi-rom compatible (to support multi-rom profiles) I'm sure it will take some time to do as I would have to use my actual Android to test with, but no worries!
Hope that helps a little. Sorry it's not better news though.
An excellent "misuse" of this concept would be to run ion (picking it for its speed and almost stock nature) with a hero overlay (picked due to known instability as we are still developing it) so that ion would serve as a "safe mode" for when you crash hero.
I have a spare phone if i crash this and a secondary sd for if that gets corrupted. Let me know if you need help testing.
twistedumbrella said:
An excellent "misuse" of this concept would be to run ion (picking it for its speed and almost stock nature) with a hero overlay (picked due to known instability as we are still developing it) so that ion would serve as a "safe mode" for when you crash hero.
Click to expand...
Click to collapse
Interesting thought, and if this could be done, I suppose it would be possible to have bluetooth working in ION while using a Hero overlay?
Request for feedback...
Hi All,
Those who've installed android2sd, how is it going?
Can you give some pros and cons of your experience so I may improve things going forward? (Hopefully no cons exists!)
I know that roms that already make use apps2sd will encounter issues as the apps2sd and android2sd function similarly and thus step on each other. I may be able to detect this condition and adjust for it going forward...we'll see.
Thanks in advance for your input!
Darkstrumn
LucidREM said:
very interesting .. at first i failed to see this part as i'm sure many pay skip over the whole "rename to rar" thing - LOL - so this loads profiles from the SD to the phone
for anyone having trouble with the whole "rename" process try this:
http://files.lucidrem.us/jf/android2sd.rar
as i know windows with hidden file extensions does not allow a rename easily
Click to expand...
Click to collapse
Thanks for putting the rar up, XDA wouldn't take the .rar and I didn't want to signup to a file-share site just yet.
And it being seemingly natural to make windows show file extensions, it didn't cross my mind to make a note about that.
Thanks again!
Darkstrumn said:
Thanks for putting the rar up, XDA wouldn't take the .rar and I didn't want to signup to a file-share site just yet.
And it being seemingly natural to make windows show file extensions, it didn't cross my mind to make a note about that.
Thanks again!
Click to expand...
Click to collapse
How come no one is trying this? It seems to me an excellent idea and would be really cool to boot mutipe roms if someone figures that out. I'm not testing this because I'm using appstosd and didn't want conflicts...but no one else with jf1.51 Rom is testing this idea?
Just curious
so wait a second. let me get this straight ... if I have a class 6 8gb card i might be able to install a hero build without rosie or widgets with the original launcher on the sd card that might actually come sorta, kinda, a little close to a speed that might be bearable? at least for like 5 minutes?
Can this be adapted to install bigger roms such as hero without the dangerspl .
XD
Ill try this with ion later tonight
wow this is beautiful work! now to test it!
Im trying so hard to understand this lol.. Correct me on my errors but from what i read this is my hypothesis on what i think this does..
This is like a apps2sd but with data and that type thing from the build we are using? And you Said this takes snapshots So we can create several profiles of the phone? Like for example have a profile with some apps loaded and another profile with all removed and be able to switch between them at will?
The answer is simple: do not include any non-open source apks or code that you have not explicitly received permission to distribute.
Instead, after building your entire update.zip, strip out all the proprietary software. Then, create a .bat and/or .sh file that will perform the following tasks:
- Download the official update.zip from the google.com site.
- Extract the required apks, obexes and jars.
- Add them to the correct locations in your update.zip
- Sign the update.zip (so include signapk.jar with your script)
- Rename the file update.zip
Name your zip as "incomplete-update.zip" (or something of the sort) and include your completer script with the file. Users will run the script and receive a complete update.zip as you had intended to distribute. THAT'S IT! A completely license-abiding way to distribute cooked "roms" without infringing on Google's licenses.
I wish google or HTC would contact me, I would say huh, what, me no speak spanish.... lol
Only if that would actually stop lawyers. God I hate lawyers. If that defense worked MMOGlider.com would still be working.
TheArtiszan said:
Only if that would actually stop lawyers.
Click to expand...
Click to collapse
It would, atleast in this case.
TheArtiszan said:
Only if that would actually stop lawyers. God I hate lawyers. If that defense worked MMOGlider.com would still be working.
Click to expand...
Click to collapse
Glider actually had a detrimental effect to the community, these mods don't. Horrible comparison.
afflaq said:
Glider actually had a detrimental effect to the community, these mods don't. Horrible comparison.
Click to expand...
Click to collapse
One man's detriment is another man's free market. It's a tough question.
Disclaimer: I hated MMOGlider and the people who use it, and wish they would've died in car crashes.
jashsu said:
The answer is simple: do not include any non-open source apks or code that you have not explicitly received permission to distribute.
Instead, after building your entire update.zip, strip out all the proprietary software. Then, create a .bat and/or .sh file that will perform the following tasks:
- Download the official update.zip from the google.com site.
- Extract the required apks, obexes and jars.
- Add them to the correct locations in your update.zip
- Sign the update.zip (so include signapk.jar with your script)
- Rename the file update.zip
Name your zip as "incomplete-update.zip" (or something of the sort) and include your completer script with the file. Users will run the script and receive a complete update.zip as you had intended to distribute. THAT'S IT! A completely license-abiding way to distribute cooked "roms" without infringing on Google's licenses.
Click to expand...
Click to collapse
This would work. But, it seems to me you could also take a similar approach that works like this:
1) Strip the proprietary code out of the update before signing.
2) Sign and distribute the update.
3) People install the update and return to the recovery screen.
4) Drop into terminal mode and run a script that downloads and installs the missing proprietary code in the proper places.
5) Reboot and enjoy.
Any reason that wouldn't work equally well (but be somewhat simpler)?
stellarman said:
This would work. But, it seems to me you could also take a similar approach that works like this:
1) Strip the proprietary code out of the update before signing.
2) Sign and distribute the update.
3) People install the update and return to the recovery screen.
4) Drop into terminal mode and run a script that downloads and installs the missing proprietary code in the proper places.
5) Reboot and enjoy.
Any reason that wouldn't work equally well (but be somewhat simpler)?
Click to expand...
Click to collapse
It doesn't seem like it would be a good idea to boot into the OS with major parts missing (esp stuff like framework.apk). However, if it can be worked around then yes, that would be a method too. Any variation on the theme of "partial update.zip plus files from a locally downloaded official update" would be good.
Is it more work to do this than just to distribute a fully complete (but not license compliant) update.zip? Yes. But it not only protects the cook from being C&D'd, it also helps to legitimize the "ROM" cooking scene.
You are still distributing the the unlicensed files, you are just providing a different way to distribute them. instead of including them directly in your ROM, you are supplying a script that adds them to your ROM.
Man all this is too much.... I might get rid of my G1. Google is always trying to ruin the good things for us. -__-"
jashsu said:
It doesn't seem like it would be a good idea to boot into the OS with major parts missing (esp stuff like framework.apk)
Click to expand...
Click to collapse
The framework.apk is APL and part of the Android source. To see what you get without the Googlebits, just run the emulator.
I think the easiest is to have the updater copy the proprietary bits from the phone to your SD card, perform update, then copy back. then reboot.
jashsu said:
It doesn't seem like it would be a good idea to boot into the OS with major parts missing (esp stuff like framework.apk). However, if it can be worked around then yes, that would be a method too. Any variation on the theme of "partial update.zip plus files from a locally downloaded official update" would be good.
Is it more work to do this than just to distribute a fully complete (but not license compliant) update.zip? Yes. But it not only protects the cook from being C&D'd, it also helps to legitimize the "ROM" cooking scene.
Click to expand...
Click to collapse
Read my post again. I am not suggesting that you try to boot without the parts. I am saying to use the terminal WITHIN Recovery. Do the step of re-adding the proprietary bits BEFORE you leave Recovery and reboot.
Actually people, let's not forget that perhaps Cyanogen had to modify some closed-source apps like Market and Camera on several occasions, right? To avoid crashes due to resource-id changes?
So just downloading older binaries might not always work?
--Tim
I sent a twitter to Cyanogen about this last night. Downloading every time would be slow and a waste of bandwidth. I think you could do it one of two ways.
1) add a script to cm-recovery that is executed with ALT+G the extracts the apks, etc from an official google dist file on the sdcard and copy them to the proper locations.
2) add a script (which does the extraction, etc. from a zip on the sd) someplace into update.zip. cm-recovery looks for that script and if it exists then it will automatically execute after the normal update routine is complete
3) a combination where the script is in update.zip but the users has to hit ALT+G to execute it.
I think #2/#3 would be most flexible because you wouldn't have to change recovery image for different ROMs and all ROM developers could have a custom script in their update.zip to fit their needs.
rewrite those applications if they haven't already been rewritten in one way or another many dialers, a couple marketplaces, youtube, all the apps could be developed just like messenger and browser come on lets just get around google and create the missing apps
kanstin said:
I sent a twitter to Cyanogen about this last night. Downloading every time would be slow and a waste of bandwidth. I think you could do it one of two ways.
1) add a script to cm-recovery that is executed with ALT+G the extracts the apks, etc from an official google dist file on the sdcard and copy them to the proper locations.
2) add a script (which does the extraction, etc. from a zip on the sd) someplace into update.zip. cm-recovery looks for that script and if it exists then it will automatically execute after the normal update routine is complete
3) a combination where the script is in update.zip but the users has to hit ALT+G to execute it.
I think #2/#3 would be most flexible because you wouldn't have to change recovery image for different ROMs and all ROM developers could have a custom script in their update.zip to fit their needs.
Click to expand...
Click to collapse
Anything that requires a user to press more keys is dumb. The problem Google has is that their apps are being redistributed by rom makers.
Lets take a look at how Google circumvents the same restrictions for HTC binaries: http://source.android.com/documentation/building-for-dream
Remember they are advocating circumventing HTC's proprietary licenses by running a script to copy these files. We need to do the same thing, and as long as we are coping the files, using the phone as the SOURCE, the process can be transparent to the user.
Edit:
Also has anyone thought about the fact that HTC proprietary files are being redistributed also? The phones are UNUSABLE without these files.
fauxhawk said:
Anything that requires a user to press more keys is dumb.
Click to expand...
Click to collapse
Yeah, it is dumb. Option #2 runs the script automatically and and Option #3 requires pressing ALT+G. Option #3 is in case the lawyers get really nasty; there is no way they can say that option is in violation because it requires user intervention (pressing ALT+G).
would this approach at distribution impact the optimization and tight fit of the ROM?
This is pretty much the same idea I had last night.
http://forum.xda-developers.com/showthread.php?t=564303
camalot said:
You are still distributing the the unlicensed files, you are just providing a different way to distribute them. instead of including them directly in your ROM, you are supplying a script that adds them to your ROM.
Click to expand...
Click to collapse
But you are not distributing these files. The update.zip you supply has absolutely no intellectual property which you are not entitled to distribute. Even the script, the IPR for it would be with the dev who write it. Now it might well be illegal - and personally I'd debate whether it is, but let's leave that for now - to *RUN* that script. But that's not the dev's concern and everything he supplied would be his own IPR.
Say you had a friend who worked for Google. It's the same as the difference between this friend emailing you a copyrighted MP3, versus you using Google to search for the same MP3 and then clicking on a link that appears. In the latter case Google hasn't distributed anything - they've merely provided the means for you to find the file on-line. YOU are then the one who breaks the law by downloading it. In the former case, it's your friend - and possibly Google as the people who provide the email system - who break the law.
Any dev who provided a script to download what is needed from a place on the internet and extract them from a zip would be very difficult to C&D.
Hi there. I've just migrated to Android from WinMo and have a few questions. Firstly, where can I find the ROM apks? In which folder are they stored? I'm particularly interested in the HTC Desire's FM Radio app. Is there anyway I can track what commands does it send to the FM Radio device so I can make a custom Radio app? And as far as those apps run on the Dalvik VM, can the code be partially decompiled? I know it's a long shot for a newbie, but at least it would be an interesting thing to attempt. I got used to dlls in Windows and have almost no experience with Linux, so I know it would be hard. Anyway, any help or suggestions will be much appreciated
Edit:
----------------------------------------
So here are the files I succeeded in decompiling: HTCRadio.rar (18.7 MB)
In case anybody needs them
The archive contains HtcFMRadio.apk, HtcFMRadio.odex, their decompiled resources and classes in smali format and the com.htc.resources framework
I will try to make sense of them, but I'm almost certain I'll fail
martintzvetomirov said:
Firstly, where can I find the ROM apks? In which folder are they stored?
Click to expand...
Click to collapse
/system/app for system apps, and /system/framework for frameworks: Java runtime, Android libraries, etc.
martintzvetomirov said:
And as far as those apps run on the Dalvik VM, can the code be partially decompiled?
Click to expand...
Click to collapse
http://code.google.com/p/smali/ - Dalvik bytecode (dis)assembler
http://code.google.com/p/android-apktool/ - decodes app resources (they are compiled/optimized to binary form), simplifies working with decoded files, uses smali
Thanks, mate! That's a really good start point for me
EDIT: I successfully decompiled the resources and the classes. I've added a link in my fist post in case someone searching in Google for that comes accross this topic
Ok, from what I've seen HTCRadio.apk has registered a service called FMRadioService and luckily its android:exported is set to true. Does it mean that I can call this service from my app and get something useful from it? And if yes, how can I call a service for which the only thing I know about is its name? Cheers
EDIT: I successfully invoked the Remote Service and I think implemented the aidl correctly. Now it's time to figure out how to make it work