Related
"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.
One of the things that I have been feeling is that the custom ROM community is growing at very high rate.
Going by the stats counters of various ROMs, we can peg CM, AOKP and Paranoid at 8mil, 4mil and 2mil each. There is also 1mil users of the mashup PAC-Rom.
Considering Omni is a huge project, this will race up to few millions soon. With a diaspora of 15-20 million users out there, we pretty obviously have a niche market of apps for these custom ROMs out there in the wild. In fact there are a lot of apps which are made specifically for custom ROMs.
For people who want to develop apps for these devices though, they are constrained to work with the AOSP SDK. But the custom ROM community has over the years made the the Settings and all Provider databases run on steroids with huge additions to them which can be brilliantly used to make more powerful apps.
Building an the SDK is in fact trivial
Code:
. build/envsetup.sh
make -j8 PRODUCT-sdk-sdk dist
or another way is
Code:
. build/envsetup.sh
lunch mako-userdebug
make -j8 sdk
The guys over there at Replicant already do make their own SDK with every release they make. I personally feel since at omni we are doing a great job of supportting so many devices, so many features and doing it in a well maintained way, we definitely should have our own SDK too.
I am a device maintainer at AOKP, and currently I am working on creating AOKP SDK too. (It does need pruning of the whole source a lot. Since the sdk building process validates the existence of each PRODUCT_PACKAGES call and does not ignore javadocs warnings)
http://goo.im/devs/kxp/android.jar
This here is a modified android.jar that can be replaced at sdk.dir/platforms/android-18/android.jar to support building apps using AOKP's custom variables and APIs.
Also such a venture helps building and testing of ad-hoc packages like AOKP's ROMControl or omni's OmniGears on studio/eclipse.
Sounds awesome
So what would be the effect in daily omni dev?
Are there things we should consider to make creating an SDK
as easy as possible?
maxwen said:
Sounds awesome
So what would be the effect in daily omni dev?
Are there things we should consider to make creating an SDK
as easy as possible?
Click to expand...
Click to collapse
I do not have a local copy of the omni source to be honest
I will sync up omni this weekend and start off with this. Will see what problems I face, and what can be done to keep the sdk always buildable.
SDK can be built out of pure AOSP source usually always.
Modified sources like that of a custom ROM often hacks with the build system (things like BUILD_PREBUILT and overriding LOCAL_MODULE etc as you know) which makes building sdk off the source of a custom ROM not that straight forward. right now i am in fact fighting with the AOKP source and trying to figure out what are the various things that need fixings.
Also in the framework packages, presence of lint warnings and other non-standard '@modifiers' like for eg. @hid makes sdk unhappy.
Replicant is an excellent examply of an Android fork that is always buildable for both devices as well as for the sdk.
As far as release cycle is considered, we can do that something like once a month or so ? The fully built zip of the sdk is ~350mb usually.
maxwen said:
Sounds awesome
So what would be the effect in daily omni dev?
Are there things we should consider to make creating an SDK
as easy as possible?
Click to expand...
Click to collapse
I do not have a local copy of the omni source to be honest
I will sync up omni this weekend and start off with this. Will see what problems I face, and what can be done to keep the sdk always buildable.
SDK can be built out of pure AOSP source usually always.
Modified sources like that of a custom ROM often hacks with the build system (things like BUILD_PREBUILT and overriding LOCAL_MODULE etc as you know) which makes building sdk off the source of a custom ROM not that straight forward. right now i am in fact fighting with the AOKP source and trying to figure out what are the various things that need fixings.
Also in the framework packages, presence of lint warnings and other non-standard '@modifiers' like for eg. @hid makes sdk unhappy.
Replicant is an excellent examply of an Android fork that is always buildable for both devices as well as for the sdk.
As far as release cycle is considered, we can do that something like once a month or so ? The fully built zip of the sdk is ~350mb usually.
Thanks for the tip! This is actually really nice.
We might build one as part of nightlies, that could come in handy. One thing to remember though is that the APIs we add to framework aren't meant to be used by apps directly as they are highly versatile and likely to change from day to day. We also enforce permission checks on everything we do to avoid any sneaky app.
XpLoDWilD said:
Thanks for the tip! This is actually really nice.
We might build one as part of nightlies, that could come in handy. One thing to remember though is that the APIs we add to framework aren't meant to be used by apps directly as they are highly versatile and likely to change from day to day. We also enforce permission checks on everything we do to avoid any sneaky app.
Click to expand...
Click to collapse
@XpLoDWilD
The @hide identifier is there precisely for the same reason
API's that should not be generated as stubs for android.jar should be under @hide
AOSP itself used @hide to keep some api's hidden which is not supposed to be used the by the casual app developer. (for example most provider apis are hidden only in sdk)
So if there is something that is REALLY volatile or something that should not be exposed into SDK (hacked up stuff ), they can be taken of using @hide
championswimmer said:
@XpLoDWilD
The @hide identifier is there precisely for the same reason
API's that should not be generated as stubs for android.jar should be under @hide
AOSP itself used @hide to keep some api's hidden which is not supposed to be used the by the casual app developer. (for example most provider apis are hidden only in sdk)
So if there is something that is REALLY volatile or something that should not be exposed into SDK (hacked up stuff ), they can be taken of using @hide
Click to expand...
Click to collapse
Which, so far, has usually been a case of "@hide everything" for most custom firmwares so as not to cause compatibility issues.
Changing this would require some pretty serious thought and would need to be done very carefully.
Entropy512 said:
Which, so far, has usually been a case of @hide everything" for most custom firmwares so as not to cause compatibility issues.
Changing this would require some pretty serious thought and would need to be done very carefully.
Click to expand...
Click to collapse
Okay as far as providing regularly updated APIs to app developers is concerned that would involve some thing like this
lunch a buildable device (full or sdk-eng will also do, or just simple lunch omni_mako-userdebug)
Code:
mka core; mka framework;
the following files
/home/championswimmer/jb-mr2/out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/classes.jar
/home/championswimmer/jb-mr2/out/target/common/obj/JAVA_LIBRARIES/core_intermediates/classes.jar
(preferably renamed to core.jar and framework.jar) can be released then.
These, if added to external libraries in studio/eclipse (and has to be put higher in order of inclusion than android.jar from the sdk) can allow people to work using custom-added APIs of omni.
P.S. These libraries have stubs of @hide methods too. The @hide quantifier is not respected, and all APIs are exposed.
Entropy512 said:
Which, so far, has usually been a case of @hide everything" for most custom firmwares so as not to cause compatibility issues.
Changing this would require some pretty serious thought and would need to be done very carefully.
Click to expand...
Click to collapse
Okay as far as providing regularly updated APIs to app developers is concerned that would involve some thing like this
lunch a buildable device (full or sdk-eng will also do, or just simple lunch omni_mako-userdebug)
Code:
mka core; mka framework;
the following files
/home/championswimmer/jb-mr2/out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/classes.jar
/home/championswimmer/jb-mr2/out/target/common/obj/JAVA_LIBRARIES/core_intermediates/classes.jar
(preferably renamed to core.jar and framework.jar) can be released then.
These, if added to external libraries in studio/eclipse (and has to be put higher in order of inclusion than android.jar from the sdk) can allow people to work using custom-added APIs of omni.
P.S. These libraries have stubs of @hide methods too. The @hide quantifier is not respected, and all APIs are exposed.
hacked this up
http://gerrit.aokp.co/#/c/14129/
anyone can feel free to port this for omni too. should be a matter of just changing the CUSTOM_NAME variable.
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
Reposting from where I previously put this, on the suggestion that folks here might have more idea what I am talking about.
Yes, this is a question but I couldn't see that it fit in better to one of the other forums. If I am wrong please accept my apologies and redirect me, thanks.
I'm trying to work with a custom build of Android based on KitKat to incorporate a stylus, copying some of the functionality (though not code) from Samsung which sells Android-with-stylus builds for e.g. the Note 3. I'm not including details of the specific device because right now I am working on a custom dev device and my aim is to write code which is generic enough to be usable from any Android (based on KitKat). The build (written by others) already incorporates drivers and sends stylus events correctly as motion events etc. Programming at the app level I can receive onHover, onTouch, onClick etc
The specific functionality I am trying to achieve is to pick up a stylus-button-click while hovering. It's perfectly possible to do this in any app, using an onGenericMotion Listener.
However, I want to make my "stylus-action" have system-wide effect - so that anywhere (in any other app, or in the launcher or whatever) I will pick up the event (prior to any other app) and bring up my custom menu. (just like AirCommand in Samsung Note 3) I guess in my custom Android this would then make that particular action somewhat protected or unusable for other users, but I'm ok with that.
In older Android (prior to ICS) you could try something by putting up a System Overlay (i.e in regular app code, without hacking the ROM at all), but this is no longer possible.
This is not an attempt to tapjack or whatever, I understand why this functionality has been removed from the domain of the regular programmer, and I don't want to regress my ROM back to pre-ICS behaviour by allowing the System Overlay hack. Now I am programming the system (if my change is good enough I'd like to submit it back to AOSP) so I would like to know the best method to address this. Since Samsung have already done this, it must be legal (using legal in the terms of "Android will allow it"), and I want to do it right.
Is it possible to write something similar to the System Overlay when you are running from a system service? Or is there a good choke-point to capture events before they are broadcast to the current running apps?
I was looking at (sorry, not allowed to post links) AndroidXRef /frameworks/base/core/java/android/view/View.java specifically in the function dispatchHoverEvent() which looks like a promising place. My naive idea is that I would place code here checking the MotionEvent to see if the button is pressed and if it is, don't call any listeners and instead call my little menu app (or broadcast a custom message, or something anyway). However, I've never written code on the ROM level before (LOTS of experience writing app code) so I don't know if this is a really bad point or a good point to add in code. Should I be putting things at a higher level or a lower one? Will this capture all events or not? Is it all just trial and error?
If this is the wrong place to ask questions like this, please tell me where on XDA I should be asking it. If it's the right place - please answer
Thanks
Kibi
Hi,
I have created an application using Phonegap for a platform similar to Wordpress. The app allows users to login into their accounts, view personal messages, files, etc. Now, I want to publish the source code so that developers can grab their own copy of it and submit it to the PlayStore/Appstore. What I am worried about: Apps sometimes get rejected due to the fact that they are similar to another one. Is there any way to prevent this? A few colors and the site name will be changed by the site owners, but the core will stay the same. I saw many companies selling apps like I am planning to do and it doesn't seem like there are any problems. How can they make sure there is no rejection because of the similarity (in this case in my JS files)? Should I change the source code for every copy of it? (this might be pretty hard but I could change the order of my JS functions or rename some objects, randomly include some useless scripts etc) Or am I just way too worried about this?
Thanks for your help