Database Develop

More Cupcake questions

"cupcake" development branch
A link to this was posted on the G1-Hackers mailing list. I haven't seen it here yet so I figured I would share. You can find the original post at http://source.android.com/roadmap/cupcake.
---------------------------------------------------------------------------------
"cupcake" development branch
From http://source.android.com/roadmap:
During Android's transition to anopen-source project, some development has continued to happen in aprivate branch. We are working to move the rest of these changes intothe open as soon as possible, and all future open-source work willhappen in the public git repositories. All changes that have alreadybeen submitted to the public repositories will be merged into the newercode base, so nothing should be lost.
The Android team has begun pushing these changes to the public git repositories, in the "cupcake" branch.
About this code drop:
The "cupcake" branch is a read-only mirror of the private Android branch.cupcake is still very much a work in progress. It is a development branch, not a release.
Thefirst drop is a large roll-up commit of all of the changes sincerelease-1.0. We will transition to regular, smaller roll-up drops,ultimately pushing individual commits.The cupcake branch willbe merged into the master branch, so that all of the public patches canbe used with the new code base. None of the commits in the publicrepositories will be lost, unless they no longer make sense or areobsoleted by the new code base. Due to the United States' holidayseason, though, this may not be finished until early January.
To check out the cupcake branch:mkdir cupcake # create a new client directory
cd cupcake
repo init -u git:/android.git.kernel.org/platform/manifest.git -b cupcake
repo sync
Notable changes introduced in cupcake:
Applications
MMS
New features
Save attachments from MMS.
Significant bug fixes
Faster conversation list scrolling
Email
Significant bug fixes
Accounts that were marked "never check" are not auto-checked.
Date & time displayed using user preference (e.g. 24 hr vs. AM/PM).
cc: displayed in message view.
Relaxed POP3 parser rules so it works with non-compliant email servers.
Password quoting bugs in IMAP. Makes it work for users with funny chars in their password (e.g. spaces).
Various sources of errors in auto & manual account setup.
Improvements on how we report various connection errors. Makes it much easier for user to diagnose failed account setups.
New-mail notifications for POP3 accounts.
Properly recover from POP3 connection failures, so that the next connection has a chance of working properly.
Remove automatic accounts setup entries that were broken or nottestable. Minor fixes to a few of the remaining entries. Improvementsto warning dialogs used for a few special cases.
New accounts are now set to check every 15 minutes (instead of defaulting to "never").
Fixed a bug causing approximately 1 in 25 outbound messages to freezeup the IMAP connection (to a Gmail based server) when transferred tothe Sent folder. This broke the entire connection so new messagescould not be downloaded either.
Unit test framework so Email can be extended & tested more reliably.
Fix IMAP manually-created accounts so message delete works properly.
Alarm Clock
Significant bug fixes
Alert now plays audio/vibe directly, rather than through AlarmManager.AlarmClock alert starts playing audio/vibe in its IntentReceiver,rather than on activity start. These changes should prevent alarms frombeing blocked by modal dialogs.
Package Installer
Significant bug fixes
Bugs related to replacing existing applications.
Settings
New features
New menu option to list running processes in Settings->ManageApplications.
Music
New features
Music playback fades in after suspending for phone call.New media search intent allows for 3rd party apps to launch or respondto media searches based on artist, album, or title.
Affects: MusicPlayer, YouTube, Browser applications.
Browser
New features
Updated WebKit browser core, synced with Nov 2008 WebKit version.
Support for new, optimized JavaScript engine (SquirrelFish).
Copy/ paste is enabled in the browser. To copy with touch, press and holdthe shift key and select the text. Releasing the shift key or endingthe touch drag copies the text. To copy with the trackball, press andhold the shift key, move the cursor to the selection start, click thetrackball, and move the trackball to the extend the selection.Releasing the shift key, or clicking the trackball a second time,copies the text.
Find is enabled in the browser. To find text, choose it from the menu and type the text to find.
Drawinghas been sped up substantially by supporting partial contentinvalidates and partial screen invalidates. Pages with animations are5x faster.
VoiceDialer
New features
VoiceDialer supports 'open app' command
Camera/Gallery
New features
Video recorder mode
Share intent for videos
Video thumbnailsLocal file playback
Download manager
New features
Support for HTTP codes 301, 302, 303 and 307 (redirects).
HTTP code 503 is now handled, with support for retry-after in delay-seconds.
Downloads that were cleanly interrupted are now resumed instead of failing.
Applications can now pause their downloads.
Retry delays are now randomized.
Connectivity is now checked on all interfaces.
Downloads with invalid characters in file name can now be saved.

"cupcake" development branch continued
Framework
New features
Support of touch events in WebView.New JavaScript engine (SquirrelFish) in WebView.
Input method framework, for soft keyboards and other on-screen inputmethods. Includes new APIs for applications to interact with inputmethods, and the ability for third party developers to write their owninput methods.
Access to the raw audio data for playback and recording from application code.
New PendingIntent.FLAG_UPDATE_CURRENT option.
Support for top-level boolean resources.
Tactile feedback to the LockPatternView. Tactile feedback can beenabled/disabled by going to Settings > Security & location andthen checking/unchecking "Use tactile feedback". Note that this can beused independently of the visual feedback of the lines ("Use visiblepattern"). Thus it gives users a middle ground between showing thelines on the screen and having no feedback at all.
PackageManager changes to support un-installation ofpartially installed applications. Added new flagPackageManager.GET_UNINSTALLED_PACKAGES to include partially installedapps in all relevant PackageManager api's. ManageApplications screennow lists such partially installed apps and the user can uninstallthese applications completely.
Support third party updates of system applications. Newmenu options in Settings->ManageApplications to list updated systemapplications.
Framework support to list current running processes. New API in ActivityManager.
Framework feature to declare required configurations by applications.New manifest attribute uses-configuration in android manifest.
Hardware accelerated video encode (video recorder) in opencore.
Simplified SREC speech recognition API available.
Streaming audio I/O for applications.
Significant bug fixes
Fixed issues with saving state in the view hierarchy, so that you canproperly subclass from something like TextView and create your ownstate that inherits from that provided by TextView.
TextView now implements onKeyMultiple(), so that flinging the trackballwill result in accelerated scrolling. This required some changes tomovement methods, and included some improvements to the accelerationcomputed when flinging.
Framework bug fixes in PackageManager to share/un-share permissions for applications with shared uid's.Significant rework of Settings->ManageApplications Performance and UI enhancements.
Anumber of settings in android.provider.Settings.System were moved toandroid.provider.Settings.Secure. Only system software can modify thesesettings. Additionally, a new permission, WRITE_SECURE_SETTINGS, isrequired to access these settings. The old constants in Settings.Systemhave been deprecated. It is possible to read settings values viaSettings.System using the deprecated constants. However, attempts tomodify these settings via Settings.System will result in a log messageand the setting value will be left unchanged.Many bug fixes in the media framework
Bluetooth
New features
Support for A2DP & AVRCP profiles.
Significant bug fixes
First connection after pairing always fails on many carkits.
Mini Cooper and some late model BMW cars fail to use Bluetooth or take 2 minutes for Phone Book transfer.
System software
New features
New kernel based on Linux 2.6.27.
Improvements to the wakelock API.
Work to transition to the USB Gadget Framework underway.
Basic x86 support.
Radio & Telephony
New features
SIM Application Toolkit 1.0.
Green CALL button is no longer a shortcut for "add a new call". Thishas been a rarely used feature and confusing if triggered accidentally.
Longer in-call screen timeout when using the speakerphone.
"Show dialpad" / "Hide dialpad" item added to the in-call menu, to make it easier to discover the DTMF dialpad.
Significant bug fixes
An obscure case where the Phone UI could cause the device to not go tosleep on its own. This would happen if user bails out of the in-callscreen by hitting HOME, followed by the call disconnecting remotely. Don't allow a single tap to open the in-call dialpad. Itis now required to touch and drag it. This makes it much harder toaccidentally open the dialpad by touching the screen with your face.
Developer Tools
New features
Enable handset manufacturers to extend the Android SDK with add-ons. SDK add-ons will include:
systemlibraries to let developers use additional APIs provided by handsetmanufacturers or from other 3rd party vendors that handsetmanufacturers chose to include
emulator system images,skins, and hardware configuration to let developers test theirapplications on their Android implementation
This is work-in-progress. Please note that the latest Android SDK (Android 1.0 SDK, Release 2) is not compatible with the SDKplugin in the new branch, please use ADT 0.8.0. SDK add-on support is planned for future SDK release.
Build System
New features
The functions in build/envsetup.sh should be much more useful

nice, this is some secret undercover stuff that is much needed!! you all rock!
hbguy

I'm wondering would it be available to install for non-jailbraked phone?

worry said:
I'm wondering would it be available to install for non-jailbraked phone?
Click to expand...
Click to collapse
We are talking about Android source code here. It would need to be compiled appropriately to even flash to any phone. Your phone would still subject it to the same key test before it will flash it. So, No this won't work... Yet. Hopefully we will find a way to sign these images with the OTA keys instead of just test keys as we do now.

"Chicken Soups for Andy Phones"

Yes, I am aware of you should compile it first.
So you are saying, since it is not officially signed by google, you'll be able to install it only on dev or has-proper-boot-image phones?

wait, how do we get all these updates in the future though? sdk?
also what you mean as finding a way to sign these images with ota keys instead of just test key? meaning with jf's mod rc30 we could get these update?
hbguy

man, well these were a few of the things that i wanted to see changed its good that they are keeping in touch with the ppl runnin the app. this is very compelling information. can i suggest and addendum to the title, something alluding to the "update" nature of this dev team. i dont think theres a date, but ill def be willing to pick a G1 back up for that, esp if they managed to make a few of the processes faster.

hbguy said:
wait, how do we get all these updates in the future though? sdk?
also what you mean as finding a way to sign these images with ota keys instead of just test key? meaning with jf's mod rc30 we could get these update?
hbguy
Click to expand...
Click to collapse
Cupcake can't be built to run on Dream hardware yet. Not to worry as an OTA RC with the cupcake code drops should be available by year's end or early Jan 09.

Support third party updates of system applications. New menu options in Settings->ManageApplications to list updated system applications.
Click to expand...
Click to collapse
I haven't had a chance to look into it too much but, depending on the applications and files made accessible, this looks very promising. Things like the autorotating browser, maybe even skinning, could potentially be "legitimized" and no longer require root.

so how would one go about compiling to run on the dream?

korndub said:
so how would one go about compiling to run on the dream?
Click to expand...
Click to collapse
Right now...... You wait. There isn't 100% of the code here. Nothing specific to the dream hardware etc. I am hopeful we will be seeing things come soon though.
As far as what I meant about the keys... Right now in order to be able to flash an update that is signed with test keys, aka the keys we have right now, you need to use an exploit to gain root access and modify the keys the system looks for when updating. There are two possible ways that I see to get OTA RC30 flashed with with an unofficial image. The first way is for some ingenious person to find an exploit that can be used to obtain root again and therefore be able to change the keys the system looks for. The other option would be for someone to come up with a way to sign the image with the OTA keys.

kronarq said:
Right now...... You wait. There isn't 100% of the code here. Nothing specific to the dream hardware etc. I am hopeful we will be seeing things come soon though.
As far as what I meant about the keys... Right now in order to be able to flash an update that is signed with test keys, aka the keys we have right now, you need to use an exploit to gain root access and modify the keys the system looks for when updating. There are two possible ways that I see to get OTA RC30 flashed with with an unofficial image. The first way is for some ingenious person to find an exploit that can be used to obtain root again and therefore be able to change the keys the system looks for. The other option would be for someone to come up with a way to sign the image with the OTA keys.
Click to expand...
Click to collapse
kronarq is there a way to merge the existing source with the cupcake to fill in the parts that are missing?

Anyone else having problems pulling the source with repo?

hbguy said:
nice, this is some secret undercover stuff that is much needed!! you all rock!
hbguy
Click to expand...
Click to collapse
This was not "undercover" work. Google wanted to be able to work on stuff, yet release the G1 with a semi-stable firmware.
kronarq said:
We are talking about Android source code here. It would need to be compiled appropriately to even flash to any phone. Your phone would still subject it to the same key test before it will flash it. So, No this won't work... Yet. Hopefully we will find a way to sign these images with the OTA keys instead of just test keys as we do now.
Click to expand...
Click to collapse
This won't be the case. This is an official Google release, meaning when they merge them together in January, they will release an OTA update with all of these features.

I'm hoping there will be an OTA update with all these new goodies, but just because google is rolling "cupcake" into the open-source project, that does not mean that it will get rolled out to our G1's. That's up to T-Mobile and HTC. Let's just keep our fingers crossed.

Ok, maybe I'm missing something, but where are people getting the idea that this is not dream specific? From how I read it these are all things that are being built into the main source and as such will be compiled as an ota as other updates have been done in the past. Someone enlighten me here as I'm just not seeing the "specific" requirements people are putting on this? I'm no coder, but it doesn't look like anything more then just enabling what was already there or planned on being there. [/rant?]

MMTest97 said:
Ok, maybe I'm missing something, but where are people getting the idea that this is not dream specific? From how I read it these are all things that are being built into the main source and as such will be compiled as an ota as other updates have been done in the past. Someone enlighten me here as I'm just not seeing the "specific" requirements people are putting on this? I'm no coder, but it doesn't look like anything more then just enabling what was already there or planned on being there. [/rant?]
Click to expand...
Click to collapse
Agreed... everything that is dream specific is either on the android git repository or can be extracted from stock G1 Firmware

MMTest97 said:
Ok, maybe I'm missing something, but where are people getting the idea that this is not dream specific? From how I read it these are all things that are being built into the main source and as such will be compiled as an ota as other updates have been done in the past. Someone enlighten me here as I'm just not seeing the "specific" requirements people are putting on this? I'm no coder, but it doesn't look like anything more then just enabling what was already there or planned on being there. [/rant?]
Click to expand...
Click to collapse
Everything in the open source repository should be non-device specific (with the obvious exception of stuff like binary drivers). The repo will build an emulator image. To build for dream, there are some additional instructions. However the cupcake branch cannot be built for Dream at this time, so it is definitely not Dream-specific.
Datruesurfer said:
Agreed... everything that is dream specific is either on the android git repository or can be extracted from stock G1 Firmware
Click to expand...
Click to collapse
The differences between G1 and the repo extend beyond just Google-proprietary apps. There are subtle differences in the framework too.

Proper Gnu Tools ?

I'm just curious about something.
I recently moved from the iPhone to a Nexus One.
While I noticed there are a lot of ROM cookers etc (thanks for your great work guys) the development community seems kind of thin?
For example, on the iPhone there are full sets of all GNU tools. Anything you can use in Linux/Darwin they have for iPhone. There is a full apt packaging system will full console tools. The full OpenSSH suite has been made supporting all the wireless administration that I've come to love on my phone. Basically, it makes it feel like a full computer in my hand.
Now, I love this Nexus One, but I wasn't sure what the reasoning behind no one out there doing development on this kind of stuff. You'd think a phone running Linux with all code available would attract hordes of eager coders.
Instead we get weird crap like "dropbear" that has to be recompiled yourself to even work right, and even then...haha.
Not much as far as package management in the console, and our tools come from Busybox! Just seems very odd to me, but there must be reasons that I am not seeing.
This post is really not meant as an insult because I love this OS so far etc, but it just really suprised me that full sets of standard tools are not available.
Anyone know why?

Because you have to replicate the entire standard GNU/Linux userspace, which is a bear. Most of the work is done on the Android userspace instead, and you can find the fruits of those labors on AOSP Gerrit (http://r.android.com/) and the CyanogenMOD repository (http://github.com/cyanogen/android_vendor_cyanogen).
The best bet for getting a standard GNU/Linux userspace is to just boot Debian.
For future reference, this is probably not considered the correct forum for this discussion (probably Android General or the generic Android Development, not too sure.)
EDIT: Just to address some more specific points, Android has a package manager (those .apk files you see everywhere) and Busybox makes the most of the limited internal memory and provides enough tools to manage the Android userspace.

Sorry I thought the development forum would be the right place.
The iPhone 2g/3g have only 128mb of memory, and since gnu tools aren't resident in memory there is no problem having a full compliment of them on the phone.
The problem with debian is it is not really a nice UI for a phone. It would just be nice to have my phone, plus having the GNU tools underneath.
It isn't like its a dealbreaker, it just struck me as odd that all the proper tools have been built for the iPhone, and using it really feels like a full computer you're SSHing into, where as an open source Linux based OS on android basically is lacking all of it, minus the limited functionality provided by Busybox and Dropbear (like..dropbear really?).
These things have more memory and comparable processing speed to computers running windows 98 and early XP, so there is no reason not to have everything available to you when you need it.
I'm kind of a sideline commenter here as I'm not a coder, but it just struck me as odd.
Thanks for your reply!

anethema said:
Sorry I thought the development forum would be the right place.
Click to expand...
Click to collapse
NP, it's side discussion though. "Here's a complete set of native GNU tools" would be a dev forum topic.
anethema said:
The iPhone 2g/3g have only 128mb of memory, and since gnu tools aren't resident in memory there is no problem having a full compliment of them on the phone.
Click to expand...
Click to collapse
Nonono, not RAM. Flash memory. iPhone has tons of it. G1 (where most of the developers got started, mind you) has very little. Further, the partitioning left limited room for additional binaries. There's some ways around that (symlinks, mostly), but they aren't elegant, and are subject to wiping at inopportune times if you aren't careful.
anethema said:
The problem with debian is it is not really a nice UI for a phone. It would just be nice to have my phone, plus having the GNU tools underneath.
Click to expand...
Click to collapse
I'm curious about your use case. "It would be nice" is, well, nice, but is there a need you have that the existing tools aren't fulfilling?
anethema said:
It isn't like its a dealbreaker, it just struck me as odd that all the proper tools have been built for the iPhone, and using it really feels like a full computer you're SSHing into, where as an open source Linux based OS on android basically is lacking all of it, minus the limited functionality provided by Busybox and Dropbear (like..dropbear really?).
Click to expand...
Click to collapse
I'm not sure what's with the Dropbear hate. There are not many use-cases for SSH servers on a phone, so few people have worked on it. I'd think the Android-phone-powered robot guys are the most likely to need it. But again, Dropbear is going to perform a whole heck of a lot better on a G1 than OpenSSH, and the G1 is the origin of all this stuff.
Remember, Android is explicitly not GNU/Linux. You might call it "Android/Linux." The fact that the Android userspace is open-source means that the alternate (and exciting new) userspace is attracting development, instead of people trying to port GNU just so they can use their closed-source iPhone. This is, in fact, a Good Thing, because it can result in improvements for all Android users (via contributions to AOSP), not just that subset of geeks (read: us) who mod their phones.
Understanding this difference is key to understanding the development pattern. People aren't working on the GNU userspace for Android phones because the Android userspace supplants it. The tools we have do what is needed, nothing more. In fact, `am' and `pm' are more useful in the Android context than anything that's left out of Busybox.
anethema said:
These things have more memory and comparable processing speed to computers running windows 98 and early XP, so there is no reason not to have everything available to you when you need it.
Click to expand...
Click to collapse
Back to my use case comment above. What is it that you need?
anethema said:
Thanks for your reply!
Click to expand...
Click to collapse
No problem, it's a good discussion.

I guess it is basically that you don't know what you need until you need it. I treat my phones like this basically like little computers. Certainly on a laptop/desktop no one would bother questioning why you need general tools you use to get jobs done.
For the iPhone there was a need for unique certification to apples push servers so phones that were basically 'tricked' into activating could still get push messages via these servers.
I wrote a tool called Push Doctor with phone based scripts and with a donor style one server side. Basically I was generating these certificates and people could download them. The whole thing on both side is just a bunch of shell scripts. One running on the phone, one on my and cert donors computers. Now this may or may not have worked in busybox as I haven't tested it, but I just mean you never know what you are going to use stuff for, and having a nice standard set of tools across all Linux platforms can be nice to have for this reason.
As far as the space issue, I think that whole thing seems crazy as well. You're right there is a ton of space on the iPhone, but the G1 came out after it, and the Nexus One long after it, so its too bad 'space' is still an issue these days requiring ugly hacks to circumvent.
Regardless the tools could be distributed as part of several core apk's which people could install if they wish.
Like I said above, these are hardly embedded devices anymore. It's not like there's 4kb of ram and 5 mips CPU.
As far as dropbear, it isn't that I hate it, I just think even the G1 has comparable speed to the first iPhone (not in the Graphics/UI but certainly as far as the CPU is concerned) and running something as insignificant as OpenSSH should not be an issue. I've never personally heard of dropbear, and have no idea what their security track record is, but I do know OpenSSH's. It is a VERY widely used package with a lot of eyes on it making sure it is doing what it is supposed to be doing.
Apparently the default dropbear will authenticate any password if you enable passwords and you have to build your own from source run about 50 commands, all to get it going.
Where is the APK for a working dropbear, or apt-get install dropbear? Can you even have APK's for system level packages? Everything I seem to find tends to be a custom download from someones site whcih you have to 'push' to your phone, try to follow some 50 step guide to hopefully get going, etc.
I am loving a lot of facets of this OS, I'm just curious where the community is to work on this stuff, get it going, and make it easy. Android isn't really -that- young.

anethema said:
For the iPhone there was a need for unique certification to apples push servers so phones that were basically 'tricked' into activating could still get push messages via these servers.
I wrote a tool called Push Doctor with phone based scripts and with a donor style one server side. Basically I was generating these certificates and people could download them. The whole thing on both side is just a bunch of shell scripts. One running on the phone, one on my and cert donors computers. Now this may or may not have worked in busybox as I haven't tested it, but I just mean you never know what you are going to use stuff for, and having a nice standard set of tools across all Linux platforms can be nice to have for this reason.
Click to expand...
Click to collapse
Market Enabler is in that class of application, and, like other "rooted" apps relies on shell calls to Busybox on the backend--ugly, but keep in mind this is an attempt to explicitly defeat the Android security model. BB is sufficiently standard and POSIX conformant that it hasn't posed any difficulties for these kinds of applications.
anethema said:
Where is the APK for a working dropbear, or apt-get install dropbear? Can you even have APK's for system level packages? Everything I seem to find tends to be a custom download from someones site whcih you have to 'push' to your phone, try to follow some 50 step guide to hopefully get going, etc.
Click to expand...
Click to collapse
So-called "native"--that is, ARM binary--applications aren't supported by the Android platform in the conventional way. In mid-2009, Google released the Android NDK which permits ARM binary libraries to be intermingled with Android applications via JNI. Since Android is explicitly intended to be compile-once, run-anywhere (which is why apps run on a VM), this is only recommended for computation-heavy code. However, the Mozilla project is using the NDK to directly port legacy code (Firefox/Fennec) with a thin Java interface to the Android system, so such a thing is possible.
This doesn't really make sense for the GNU toolkit, though. The SSH case; you could certainly set up an SSH server to run as a system service using NDK+JNI to connect any SSH library you like. The fact that this has not happened leads me to believe that there is little demand.
In general, the needs of existing developers appear to be met by the tools available.
Based on everything you've mentioned--you may want to take a look at the Android Scripting Environment.

Xposed - Legacy thread. Don't panic, Xposed is still here.

General information on Xposed has been moved to this thread: http://forum.xda-developers.com/xposed/xposed-installer-versions-changelog-t2714053
The FAQ has been moved to this thread: http://forum.xda-developers.com/xposed/-t2735540
Questions, suggestions, bug reports and so on can be posted in the Xposed General forum (for the installer/framework/development only) and in the Xposed Framework modules forum (for anything module-related).

Sounds interesting.I hope that you make a apk that simplifies things for simple user like rom control in AOKP
Keep up the good work my friend

That's great, decompiling/compiling apks is not really my cup of tea lol thanks rovo89

May be useful for my themes, keep working on it

Very interesting... Will try soon.

This looks like a really great idea and could help reduce the need for dev's being pestered by users for mod's every time a new rom is leaked/released, well done sir, hope to see this take off

I will definitely have a swing at this over the next few days. This looks like fun!
**This message will self-destruct**

Thanks for the "thanks" everyone. I decided to create an installer first before looking into the other things. This way, I hope a few people can test whether it works on their device (see first post for the APK).
Some notes about this:
The installer holds the app_process executable and the XposedBridge.jar as assets and can install it to the correct locations (root permissions required!).
It will automatically create a backup of /system/bin/app_process at /system/bin/app_process.orig, which can be restored either via the app or via shell (e.g. adb, works in recovery as well).
I have only tested it on ICS (LPQ Stock). Honestly, I do not have the time to test it with anything below that. If somebody wants to do this, I can help you to get started with the code. app_process was not changed very often, so chances are rather good that it will work with only few changes.
The installer requires SDK15 (4.0.3) for the same reason.
Improvements for any part of the code are welcome! It should be easy to use for both users and developers.
(Un-)Installing the installer app alone does not change anything (at least not now). Please use the buttons inside the app.
The next step should now really be to load modules dynamically, I hope I can use standard installable APKs for that (although the framework will probably request enabling confirmation for technical and security reasons).

siberian tiger said:
I hope that you make a apk that simplifies things for simple user like rom control in AOKP
Click to expand...
Click to collapse
From what I read, Rom Control seems to be something like the Settings app for ROM-specific stuff? I am not so sure yet whether I want to implement generic settings in the framework.
Having a standard interface for setting loading/saving (like or using Android's Shared Preferences) would probably make sense. But the settings themself can be very different from module to module, so I would rather let those bring their own settings menus.
What I did though was to implement an installer. My idea how it should ideally work for end users:
Install the Xposed Installer
Click the "Install/Update" button in the installer
Install one or more modules
Configure the modules (if necessary)
Have fun!
Where "install" would mean that you can download the app from the Play Store or a website and install it with the usual package manager. At least for steps 1 and 2, this is working already. For the others, I have to see.

Dynamic module loading is implemented now as well. Modules are normal apps with a special metadata tag and an asset describing which classes to load. You can look at my modifications for examples how this works. I think it is quite simple to develop and use.
I feel that Xposed is quite stable right now. It should be very easy to install both the framework and the modules without any knowledge about modding.
Also for developers, creating a new module is not too complicated. If anyone wants to give it a try, I'm happy to help you getting started. I'm convinced that Xposed is great alternative to APK modifying, but it will not work without developers creating modules for it.
Speaking of modules, I have published one for the famous CRT off effect: http://forum.xda-developers.com/showthread.php?t=1583963
The source code is also available at Github. See how it has less than 40 lines (and only about 10 LOC)? I think that this is awesome!

I was not able to install it as normal app hence pushed them to system/app using root explorer.
It works perfectly on XXLPS SENSATION ROM ICS V 3.2
Sent from my GT-I9100 using Tapatalk

OK you got me interested
What is currently holding me back is a lack of "documentation" about how to go about doing things...
Is there any reference info (even source code comments) that I should have a read of?
Or perhaps a little worked-through guide as to how you made the screen-off or red-clock one, complete with the "thinking" behind it all, just to learn the thought process.
This seems potentially hugely useful for me, just need to know what it can do!

Diliban said:
I was not able to install it as normal app hence pushed them to system/app using root explorer.
Click to expand...
Click to collapse
Really? Oh. Did you get any error message? I assume you have allowed installation of non-market apps?
@pulser_g2: Feedback taken! Until now, I focused on bringing Xposed to a level where it is actually doing something useful for end-users.
As there are some steps that can not be documented easily in the source code (e.g. how you mark an app as Xposed module), I will recreate a tutorial how you can create the clock example. I will try to give many details not only what to do, but also how you can know that you need to do this.

TUTORIAL - How to create an Xposed module
The tutorial has been moved to https://github.com/rovo89/XposedBridge/wiki/Development-tutorial

this is one of the most amazing projects made lately.
You are unleashed the best way to handle mods and possible some hacks.
very great work, robo89

Great concepts mate. Very powerful.
Wouldnt this also expose a device to malicious coders?
If a device has this implemented then is it possible that a simple theme could contain something nasty.
Not trying to stop progress of this project just throwing this out there for consideration.
----------------------
GTI9100 KK5

aceofclubs said:
Wouldnt this also expose a device to malicious coders?
If a device has this implemented then is it possible that a simple theme could contain something nasty.
Not trying to stop progress of this project just throwing this out there for consideration.
Click to expand...
Click to collapse
This is an absolutely valid thought.
In a way: Yes, it is easier to do something malicious with this. With great power comes great risk. The thing is: How would you prevent that? I couldn't think of any way once a module has been loaded, because a) how do you identify something malicious and b) how can you block it when it could just circumvent the security measure taken?
So what I did was to require that you enable a newly installed module in the installer. This at least avoids that you install any normal app and it contains a hidden Xposed module.
And not trying to play this question down, but you could insert malicous code in a theme also when you post a new framework.jar or SystemUI.apk. You could just change the smali code, compile it and you have similar power. For example, modifiying the constructor of the Activity class would also get you into any app and you could as well do whatever you want. You wouldn't even find these modifications because of the hundreds of classes in the Android framework. In this point, Xposed modules are easier to check, because they will usually contain just one class with very few and short methods.
Or take Superuser. Yes, it is asking you every time whether you want to execute this command. But the command can as well be a script that could replace files as the root user. Same for the kernel. In any case, when you modify anything in your phone, there is a risk that it is malicous.
As I said, I'm not denying that there could be a misuse of this project. But I do not see a chance to prevent it without blocking even simple real-life modifications. If anybody has ideas, please let me know.

rovo89 said:
This is an absolutely valid thought.
In a way: Yes, it is easier to do something malicious with this. With great power comes great risk. The thing is: How would you prevent that? I couldn't think of any way once a module has been loaded, because a) how do you identify something malicious and b) how can you block it when it could just circumvent the security measure taken?
So what I did was to require that you enable a newly installed module in the installer. This at least avoids that you install any normal app and it contains a hidden Xposed module.
And not trying to play this question down, but you could insert malicous code in a theme also when you post a new framework.jar or SystemUI.apk. You could just change the smali code, compile it and you have similar power. For example, modifiying the constructor of the Activity class would also get you into any app and you could as well do whatever you want. You wouldn't even find these modifications because of the hundreds of classes in the Android framework. In this point, Xposed modules are easier to check, because they will usually contain just one class with very few and short methods.
Or take Superuser. Yes, it is asking you every time whether you want to execute this command. But the command can as well be a script that could replace files as the root user. Same for the kernel. In any case, when you modify anything in your phone, there is a risk that it is malicous.
As I said, I'm not denying that there could be a misuse of this project. But I do not see a chance to prevent it without blocking even simple real-life modifications. If anybody has ideas, please let me know.
Click to expand...
Click to collapse
It is so refreshing to see someone take such a mature approach as this.
I greatly appreciate your time on that tutorial, and I will take a proper read through it while working it out myself later... (on vacation right now, this seems like a good thing to try if it rains )
Regarding security, I guess you could add a way to protect WHAT was being edited... Such that your package needed to declare edit access to package X and Y, and if it doesn't have permission, it can't do it... This way, if I want to interfere in Gmail, the user must agree, and he/she will say "well... Why is my no battery sound tweak touching gmail?" But this obviously doesn't help for frameworks and services where they are all in the one file... :/

pulser_g2 said:
Regarding security, I guess you could add a way to protect WHAT was being edited... Such that your package needed to declare edit access to package X and Y, and if it doesn't have permission, it can't do it... This way, if I want to interfere in Gmail, the user must agree, and he/she will say "well... Why is my no battery sound tweak touching gmail?" But this obviously doesn't help for frameworks and services where they are all in the one file... :/
Click to expand...
Click to collapse
Maybe.. I could rather easily implement something in hookMethod that checks the method to be hooked against a whitelist defined in an asset in the module (which could of course contain wildcards). Then when you enable a module, I could display this whitelist, with a warning if it includes some very central classes/packages/methods (but how to create such a list?).
However, this cannot control the following:
What you do inside the handling method. If you change anything in SystemUI (and that might be only the battery icon or the clock color), this method will be executed in the context of the SystemUI, which has a large set of Android standard permissions.
Calling any methods of the framework and modifying any available variables, as this can be done via standard reflection.
Basically anything that is not handled through XposedBridge, but using standard techniques.

Wanted to install the framework, but i am getting:
sh: /data/data/de.robv.android.xposed.installer/cache/install.sh: no such file or directory
What am i doing wrong ?

Xposed API changelog / developer news

This thread is intended for module developers. Make sure you follow it (i.e. subscribe) to be informed about any API changes and additions.
I will announce changes before the release if they might make existing modules incompatible.
If you're interested in more details, you can follow the GitHub repositories:
https://github.com/rovo89/XposedBridge/commits/master
https://github.com/rovo89/Xposed/commits/master
https://github.com/rovo89/XposedInstaller/commits/master
Here you can also download the API jar file that you need to reference from your project. Make sure you read the development tutorial to understand how it works. Especially make sure that the classes are not included in your APK, but only referenced.
Note that I will only post the latest API version here to drive the adoption of updates.

This is on pretty short notice, but I have removed the method AndroidAppHelper.getActivityThread_mPackages(): https://github.com/rovo89/XposedBridge/commit/892ba9195da5516dd79f175ac95be2b313c8f8ca
It had been used internally some time ago. I scanned the modules which have been uploaded to the repository and didn't find any which uses this method.
Apart from that, I'm planning to make Xposed for command line tools (e.g. am and pm), implemented via IXposedHookCmdInit/initCmdApp(), optional and disabled by default. It is currently used only by App Settings (but unnecessary and therefore removed in the next version) and NFC LockScreenOff Enabler (I will contact the authors).
As the low usage shows, this feature is hardly needed, so there is no need to load Xposed every time such an app is started. It also avoids the additional log entries, which could be confusing for some users. Actually it is so rarely used that I might not even offer a setting in the UI for it, just a command file for experts. I will not remove it completely as it's useful for low-level framework development (I can quickly test whether my native code changes work without having to reboot).

Xposed 2.6 will bring support for replacing dimensions defined in code (instead of merely forwarding to your own resources): https://github.com/rovo89/XposedBridge/commit/48227c5b0a7ae3e3f81d76ad3bbaf017dc95614c
The new API will be published once that version is out. Until then, it would still be possible to make adjustments of the API. If you think anything should be changed, please let me know as soon as possible.

Ok devs, 2.6 beta1 is out, and so is the new API (version 52).
Here are the relevant XposedBridge changes to version 42 (internal changes/optimizations are not listed):
The resources API can be disabled via a debug setting in the UI. If your module implements IXposedHookInitPackageResources, it will not be loaded because it likely depends on this API. You can also check (but don't change) the status via XposedBridge.disableResources if you use the API in other ways.
Hooking abstract methods (including methods declared in interfaces) will throw an IllegalArgumentException now. The callback was never executed for them anyway. This change avoids debugging effort on your side because you will notice it immediately.
It's now possible to create a DimensionReplacement object and use it to replace "dimen" resources with values calculated at runtime. Previously it was only possible to forward such resources to your module. Example in the commit message: https://github.com/rovo89/XposedBridge/commit/48227c5b0a7ae3e3f81d76ad3bbaf017dc95614c
Removed AndroidAppHelper.createResourcesKey() methods and AndroidAppHelper.getActivityThread_mPackages() - weren't used by any module in the repository.
Fix delayed configuration update for forwarded resources. That's only of interest if your replacement resource contains variants for different qualifiers that might change at runtime (e.g. drawable-land/drawable-port). https://github.com/rovo89/XposedBridge/commit/1c81954e295cdda191cf8a1cf33d21d7c5ea334d
New findConstructorExact() / findAndHookConstructor() methods, similar to the one for methods: https://github.com/rovo89/XposedBridge/commit/a233fa0bc9499eadbe2efc0b49fc3f4a46264614
IXposedHookCmdInit is deprecated now, initCmdApps() won't be called anymore unless an undocumented file has been created. Only two modules used it, both got rid of it without any loss of functionality. This also averts situations like this where logging for tools like am/pm masks errors for Zygote.
Due to some internal changes, the constructor of XResources isn't called anymore (a good thing!), which breaks some features in App Settings (a not so good thing). That's because it relied on updateConfiguration() being called twice, so it could retrieve the package name in the second call and do its changes. A fix for that is on the way, using a new method (getPackageNameDuringConstruction()) added in the last minute, which returns the package name for a very specific situation. You will probably not need it.
Apart from that, there is now an official way to open a certain section in the installer:
Code:
Intent intent = new Intent("de.robv.android.xposed.installer.OPEN_SECTION");
intent.setPackage("de.robv.android.xposed.installer");
intent.putExtra("section", "modules");
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
Possible values for "section" are currently: install, modules, download, logs, settings, about.
You can for example use this to send the user to the module section if you find out that your module isn't active yet. The best way to find out is something like that:
Code:
// in your Activity, call it to find out the activation status
private static boolean isModuleActive() {
return false;
}
// in handleLoadPackage()
if (lpparam.packageName.equals("your.package.name")) {
// don't use YourActivity.class here
findAndHookMethod("your.package.name.YourActivity", lpparam.classLoader,
"isModuleActive", XC_MethodReplacement.returnConstant(true));
}
Do NOT try to read - or even change - the internal files of the Xposed Installer to get this information or force your module to be activated. Not only can this break anytime, it will also be bad user experience and a security threat if your module is active without explicit selection in the app. You will probably see your app removed from the repository if you break the rules.
If you have any questions or remarks, please let me know. And if you haven't subscribed to this thread yet, make sure to do so now in order to stay up-to-date with new developments.

IllegalAccessException if you use reflection yourself
One additional change in the new version was the removal of a hack that nuked some access checks in Dalvik by making them return "true" every time. After some of the other internal changes, some of the processing that required this hack was no longer necessary. With some more refactoring, I was finally able get rid of this hack. That's good because it caused crashes on some badly built ROMs (incorrect smali hacks), but also in some rare cases in normal apps: https://github.com/rovo89/XposedInstaller/issues/89
However, some modules relied on the deactivation of these access checks. Now they get IllegalAccessExceptions when trying to access e.g. private fields or methods.
Does this mean that Xposed used to cause security issues on the whole system? After all, it meant that any app could access things that they couldn't access otherwise, right? So it destroyed Java's security system!
The answer is: No, that wasn't a security issue! The Java access check system is actually optional. When you get a field/method/class via reflection, you just need to call setAccessible(true) on it to disable the access check. Example in XPrivacy: https://github.com/M66B/XPrivacy/co...430849f#diff-a350382a0ec1158ad9769d07bd754a63
Note that this is only needed if you use reflection yourself, e.g. with getDeclaredMethod() / getDeclaredField(). The methods in XposedHelpers call setAccessible() on the result before returning it to you.

2.6 final comes with XposedBridge v54.
The only changes relevant for developers are the addition of XSharedPreferences.hasFileChanged() and XSharedPreferences.getFile(), and a fix for replaced animation/xml resources. If you're using the latter and want to avoid that someone with the buggy version 2.6 beta1 runs into issues with your module, consider bumping the minimum required Xposed version to 54.

In Lollipop, there were a few architectural changes in Android. I hinted one of them in the Q&A:
The most significant one is that the code for system services has been moved to a separate file. For most of the affected modules, this can be solved by a little refactoring (moving code to a different place).
Click to expand...
Click to collapse
In detail, this means: If you want to hook a system service like PackageManagerService, you can no longer do that in initZygote(). Instead, move your code to handleLoadPackage() and check for dummy package "android". Make sure you use lpparam.classLoaders when looking for classes and hooking methods. This way has worked in older Android versions as well, so you don't lose backwards-compatiblity.

I'll just repeat here what I wrote in the official announcement thread, as it'll be helpful for all module developers:
rovo89 said:
After a long time with mainly bug fixes, version 81 focuses on improvements for developers:
There is a proper API now. Previously, I basically published the sources of XposedBridge.jar, which included many internal classes/methods that modules shouldn't use. Hiding them makes it easier to find the correct methods to use and also makes it easier for me to change implementation details.
The API is published on Bintray/JCenter, so it's easy to use, especially with Gradle/Android Studio. Full explanations here: https://github.com/rovo89/XposedBridge/wiki/Using-the-Xposed-Framework-API
100% of the API are documented with Javadoc now: http://api.xposed.info/
Apart from that, downloads have moved to http://dl-xda.xposed.info/framework/ and are GPG-signed now. You can verify them against this key (fingerprint: 0DC8 2B3E B1C4 6D48 33B4 C434 E82F 0871 7235 F333). That's actually the master key, the files are signed with subkey 852109AA.
There are no real changes for end-users in this release, nevertheless I would recommend that at least developers test their modules with it.
Click to expand...
Click to collapse

tag organization system

let me start off by saying that the xposed framework is absolutely awesome but if you've noticed recently just the amount of modules have just gotten a bit unruly I suggest adding some sort of tag system to help organize all the modules
for example some the tags could be device specific modules, type of module, android version etc.
ie. I would disable any tags with sense or touchwiz because I do not on that device and those modules wouldn't work on my device

This is a frequently suggested feature and I think it's valid, but everytime I asked for someone to develop this idea further, replies stopped...
Before thinking about an implementation, it's necessary to find out which kind of categorization makes sense for most modules. There are more than 350 of them now and many of them have different requirements and purposes. Tags make only sense if they are understood and used consistently. Just giving developers the choice to create and assing tags won't work, there need to be clear guidelines, ideally even a predefined set of tags. These guidelines need to be drafted by someone, but I'm too busy to do the major work of it. If some people want to volunteer to analyse the existing modules, look for similarities (and differences) between modules, assign tags to them to get a feeling what's needed and propose guidelines, be my guest. You can use this thread for discussion and coordination.
Just to give you some examples which this isn't trivial:
- Some modules work for basically every ROM and devices.
- Others just work on certain ROMs on certain devices (the device alone is rarely a limiting factor).
- Others will work on a certain type of custom ROM (e.g. CyanogenMod-based) on different devices, but sometimes there might be a version limitation.
- Some modules can work on Sense and TouchWiz - so if you hide all TouchWiz modules, but want to see Sense modules, special filter logic is required.
- Some modules target a certain app.
That's just the works-or-not section, which I suggest to start with. Purposes of modules are even more segmented.

rovo89 said:
This is a frequently suggested feature and I think it's valid, but everytime I asked for someone to develop this idea further, replies stopped...
Before thinking about an implementation, it's necessary to find out which kind of categorization makes sense for most modules. There are more than 350 of them now and many of them have different requirements and purposes. Tags make only sense if they are understood and used consistently. Just giving developers the choice to create and assing tags won't work, there need to be clear guidelines, ideally even a predefined set of tags. These guidelines need to be drafted by someone, but I'm too busy to do the major work of it. If some people want to volunteer to analyse the existing modules, look for similarities (and differences) between modules, assign tags to them to get a feeling what's needed and propose guidelines, be my guest. You can use this thread for discussion and coordination.
Just to give you some examples which this isn't trivial:
- Some modules work for basically every ROM and devices.
- Others just work on certain ROMs on certain devices (the device alone is rarely a limiting factor).
- Others will work on a certain type of custom ROM (e.g. CyanogenMod-based) on different devices, but sometimes there might be a version limitation.
- Some modules can work on Sense and TouchWiz - so if you hide all TouchWiz modules, but want to see Sense modules, special filter logic is required.
- Some modules target a certain app.
That's just the works-or-not section, which I suggest to start with. Purposes of modules are even more segmented.
Click to expand...
Click to collapse
For the Xposed modules index thread, I'm using 9 categories to separate modules by their function, and additional tags for modules that are specific to an Android version or vendor.
If you find that that makes sense and if you'd like to use it, I can share a CSV file (which is easily usable with Python, which is why I picked it) that should have the necessary info to easily add it to your server's data "automatically" (by writing a hopefully short script) (fields include, among others: tags and package name for each module).
I realize this needs discussion and will take a good amount of time and effort, but I'm just offering the index right now should you want to take a look at it. Also, if you think I/the community can make your life easier by categorizing modules with additional tags, I'm sure many will step up to help.

That is so kind of you! Thats awesome
I will also say that I wasn't very clear. (What it became is way awesome)
I meant only like an automatic way to get ones that won't work with my device to be hidden
My scenario for this was I have an aosp gpe tablet. And when I'm brousing modules I don't want to scroll past 6 experia mods that don't apply to me.