Related
Hey all,
I am a UK vodafone customer, using an ADP G1. I currently use the JF 1.5 ADP build, and I am mostly happy with it, apart from a few things.
What I would like to do, is take the ZIP of the build and remove/tweak a few things where possible. As an example, change the dial string to be UK, add a few of my favorite apps/widgets, remove any apps I don't use etc. Nothing major.
Is it simple to do this, as I have read a lot about signing stuff and I am honestly quite confused. I am not stupid when it comes to software, but I just cant find a single resource of information to help me do what I want to do.
Could anyone offer some advice on how to go about the above, and if its easy enough then maybe we could sticky it.
Sorry if I am asking an FAQ - I did search and couldn't find anything helpful.
Rich
I'm interested in this too, but I'd base mine on the european holiday phone build which I'm currently running unmodified
if you unpack the update.zip you can change whatever you like. Then all you need to do is to zip it backup and sign it with instructions in this post.
http://forum.xda-developers.com/showthread.php?t=443713&page=21
I don't know what dial string you are refering to so I don't know about that. If you want to change specific things in the apps or appearance, then it can get complicated, you'll need to open up the apk file and use an hex editor to figure out what you want to change and change it. This is of course not so easily because most of the values that you want to change is in binary so just figuring out what string is store where is not simple.
signing is just to make sure the update.zip is not modified by a third party. we have to sign because the program that does the update verifies the signiture.
but unless you want to publish your builds, it's not necessary to modify the update.zip. just remount the system partition after the flash and do whatever changes you like.
i am afraid you have to get the source code for the phone app if you want to change the number format, but a simpler alternative is to use similar files from other builds. (there are plenty of posts explaining this.)
if you want to modify some resources (e.g. icons) of the an app, it's easy enough to do. just change the .apk extension to .zip and update the files using some archiever. but changing the UI or program function usually requires you to obtain the source code.
The phone number format contains '-' in america but not in europe. The nearest we have to the adp firmware in europe is the holiday firmware where the dailer has the correct format.
What I really want to do is add back in root so I can setup my work wifi. I think I should be able to do it so I may have a go this weekend.
For various reasons I need to change the android_id from time to time and to keep things nice and tighty, I always backup any settings before hand and restore to my original settings (android_id) when done. I wanted to have everything in one little package because plugging the commands in a terminal on the phone is not fun when the SDK is not available.
I could not find a solution for this so for simplicity, I wrote a quick bash script and decided to alter to make it more user friendly in case someone else has the need.
By default it will backup your settings.db (android_id location), generate a random letter/number 16 characters long and update the existing settings.db. You can edit the script to specific paths and even if you would like use your own hex code instead of a randomly generated one.
Anyways, from the terminal/adb this can be executed with 'sh android_id.sh'
Note: I used an array to generate the random hex. you may need to follow the steps here to obtain bash on your phone: http://forum.xda-developers.com/showthread.php?t=537827
can you explain a bit more abt the script? why is it needed to change the android_id?
nicandris said:
can you explain a bit more abt the script? why is it needed to change the android_id?
Click to expand...
Click to collapse
It's nothing too complicated..
the script provides a prompt with 3 options, backup, update and restore.
Backup does just that - it checks if the specified directory exists and if so, copies it to that location creating a backup of the original.
update checks for the settings.db in the backup location, generates a 16 character random number/letter string, updates the settings.db via sqlite and reboots the phone. Once your phone is rebooted, the randomly generated string is now your android id.
Restore deletes the altered settings.db and copies the original so the specified location reverting your phone back to it's original settings. This may or may not be necessary for some people....I'm just anal.
Why change the android_id?
I'm no stranger to Linux but am rather new to the droid. However, from what I read everybody has a unique android_id. Some apps will check the id when you register and won't allow you to register again (some games for example). Also, there are some roms will install a generic android id that multiple users may share. This can be problematic for certain apps that require a unique ID.
paxx- said:
Why change the android_id?
I'm no stranger to Linux but am rather new to the droid. However, from what I read everybody has a unique android_id. Some apps will check the id when you register and won't allow you to register again (some games for example). Also, there are some roms will install a generic android id that multiple users may share. This can be problematic for certain apps that require a unique ID.
Click to expand...
Click to collapse
thanx for the heads up! will have this on mind
Digging Deeper
paxx- said:
By default it will backup your settings.db (android_id location), generate a random letter/number 16 characters long and update the existing settings.db. You can edit the script to specific paths and even if you would like use your own hex code instead of a randomly generated one.
Anyways, from the terminal/adb this can be executed with 'sh android_id.sh'
Note: I used an array to generate the random hex. you may need to follow the steps here to obtain bash on your phone: http://forum.xda-developers.com/showthread.php?t=537827
Click to expand...
Click to collapse
I know this is an old post, But id like to know if this .sh can be added to a ROM and run after each ROM restore. The purpose is to use the same CWM backup, but during the restore process create unique android_id's.
I need to duplicate this on over 4500 devices. Pantech Element Tablet to be specific.
I would like to run several identical tablets off one Google account and manage the apps on them via a PC. When doing this it would be nice to identify which device I was selecting in the Market. If I was to alter the ro.product.devices to =TABLET 1 etc would this work? And would it have any detrimental effects? Would I need to do this before logging into Google i.e. on first boot for it to work>
And can someone recommend a free alternative to Root Explorer.
Many Thanks
All,
I am trying to test the water to see what is possible for an enterprise tablet deployment we are working on.
We are working on a dual persona device - which enables the user to switch between two android instances.
I want to be able to notify the user which persona they are using, and an ideal way to do that would be via the "System Bar" at the bottom of the screen. I am thinking of a couple of options:
1) Change the colour of the system bar
2) Add some text to the status bar (that is always there)
If I understand correctly, the settings for this menu are in SystemUI.apk, and i have pulled this using adb from the device. I believe I know how to go about changing the colour, by searching out the relevant png's and swapping them.
How would i go about implementing option 2, for example I may want the string "Home" or "Work" displayed dependant on the instance the user has loaded. Would this be a case of changing a layout XML definition? If so which one?
Regards,
Andy
Why not just use the system notification services that already exist in android? You can have persistent notification icons, text etc. and no need to build a custom ROM, just use an app.
DigitalMD said:
Why not just use the system notification services that already exist in android? You can have persistent notification icons, text etc. and no need to build a custom ROM, just use an app.
Click to expand...
Click to collapse
Good question - I am open to all suggestions - the key requirement is that an item of text would be visible at all times to the user, and couldn't be dismissed.
Wasn't looking at a custom ROM - we have to make some changes to the device anyway which need us to Root it - so was thinking while we were there to mount the Filesystem read/write and swap SystemUI.apk to solve this issue.
As I say open to good ideas.
This may be what you're looking for...
http://www.androidpolice.com/2012/11/14/android-4-2-feature-highlight-multiple-user-accounts/
LeftyGR said:
This may be what you're looking for...
http://www.androidpolice.com/2012/11/14/android-4-2-feature-highlight-multiple-user-accounts/
Click to expand...
Click to collapse
Hi, interesting but not quite what we are trying for just yet. These devices will be single user devices (currently) which we intend to run dual persona's on, essentially we will be running a micro hypervisor, that allows a user to switch between virtual OS's.
So - we are just trying to find a decent feedback mechanism to present the user with an "always visible" way of telling them which persona they are in.
patonar said:
Hi, interesting but not quite what we are trying for just yet. These devices will be single user devices (currently) which we intend to run dual persona's on, essentially we will be running a micro hypervisor, that allows a user to switch between virtual OS's.
So - we are just trying to find a decent feedback mechanism to present the user with an "always visible" way of telling them which persona they are in.
Click to expand...
Click to collapse
Ok. So I think what you are looking for is this:
* Single User sign-on - where one person (considered the owner) logs into the device.
* Switching profiles (essentially) between two user interfaces.
**Where in one environment the owner has a general setup to use as a personal device, for lack of a better term.
**And in another environment the owner has a cusomized setup that is more optimized for work purposes. Not necessarily "different than the first environment, but obvious enough that when they unlock the device they will know which environment they are in.
Basically correct?
If so, what about this as a general solution: Using multiple Launcher Apps.
Basically, use the system default as one environment. Setup/arranged for the purpose of general use. Use a second (3rd party) Launcher as the second environment. 3rd party launchers are very customizable and most are themeable. And there are a few Launcher Manager apps on the market that allow for faster switching between them. Even provide desktop shortcuts on each launcher to quickly do between. Lock the 3rd party launcher from being able to be uninstalled easily by placing it into system/app folder. And if you want to take certain functionality away, modify it so an owner can't change the theme or settings you choose for it.
LeftyGR said:
Ok. So I think what you are looking for is this:
* Single User sign-on - where one person (considered the owner) logs into the device.
* Switching profiles (essentially) between two user interfaces.
**Where in one environment the owner has a general setup to use as a personal device, for lack of a better term.
**And in another environment the owner has a cusomized setup that is more optimized for work purposes. Not necessarily "different than the first environment, but obvious enough that when they unlock the device they will know which environment they are in.
Basically correct?
If so, what about this as a general solution: Using multiple Launcher Apps.
Basically, use the system default as one environment. Setup/arranged for the purpose of general use. Use a second (3rd party) Launcher as the second environment. 3rd party launchers are very customizable and most are themeable. And there are a few Launcher Manager apps on the market that allow for faster switching between them. Even provide desktop shortcuts on each launcher to quickly do between. Lock the 3rd party launcher from being able to be uninstalled easily by placing it into system/app folder. And if you want to take certain functionality away, modify it so an owner can't change the theme or settings you choose for it.
Click to expand...
Click to collapse
Yes basically correct, but I have a solution for the device "persona" switching - imagine I am actually running two completely separate ROM's running on VM's.... so each ROM behaves as its own device, unaware of the other...
All I want to do - is add some text to the system bar that is always there....
patonar said:
Yes basically correct, but I have a solution for the device "persona" switching - imagine I am actually running two completely separate ROM's running on VM's.... so each ROM behaves as its own device, unaware of the other...
All I want to do - is add some text to the system bar that is always there....
Click to expand...
Click to collapse
Ok. Two completely separate OS running at same time. I could see that as possible, save the problem you may run into with internal space in the current format. Would you need to completely repatriation the entire device to achieve this? Or maybe you could use an AOSP base, which is considerably lighter. I'm saying two completely autonomous systems would essentially duplicate all files needed to run to make them truely separate. Actually, I think that's what you're saying...
LeftyGR said:
Ok. Two completely separate OS running at same time. I could see that as possible, save the problem you may run into with internal space in the current format. Would you need to completely repatriation the entire device to achieve this? Or maybe you could use an AOSP base, which is considerably lighter. I'm saying two completely autonomous systems would essentially duplicate all files needed to run to make them truely separate. Actually, I think that's what you're saying...
Click to expand...
Click to collapse
The implementation of the virtualised android is being done by a company for me... that isn't the issue.
I have been making some kernel mods, to beef up encryption, but also wanted while i am there to make some mods to the system bar / task bar.
Forget about the two OS issue - imagine a single device, one OS, ICS 4.0.4 - i want to add some text to the task bar (static text) how could i do it?
I was looking around for how to disable this annoying feature, and it's based around the same problem previous phones have... it's just moved.
1. Navigate to "/system/vendor/etc" and create a backup of the file "audio_ext_spkr.conf"
1.5. Seriously back it up just in case.
2. Now, use whatever method you want to get R/W access
3. Under "ring" sub-group, change the "attenuation" from the jumble of numbers to
Code:
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
3.5. You can modify the "media" and "voice" to the same value as well if you want, but it's (most likely) the "ring" sub-group you want.
I don't know how to make a flashable zip, but I can't be anymore simple than this.
great work