Forward-Locked Apps? - Nexus One General

I have a question that is purely out of curiosity. I'm not a developer, nor do I have any desire to become one... at this time.
In the process of answering questions for my father about his new Android phone, I came across the Android Developers website. Being the infinity curious person that I am, I started to browse through it and came across something that I was particularly curious about, the "Forward-Locked Application" market filter. It states that an application in the market can be set to not be visible to developer devices and unreleased devices. What I'm curious about is why would a developer not want their app to not be visible to said devices? Wouldn't it be to their advantage to allow their app to be visible, installed, and possibly tested if the owner of the developer phone or new unreleased phone so chose to do, after all, this is potentially new hardware that the app developer may not have support for in their app. Now not being a developer myself, I'm sure there are valid reasons for the filter and I am just curious as to what they may be.

Because you haven't tested your app on a new OS build, and want ensure compatibility before offering it for sale. Other reason is that the new OS build either obsoletes, duplicates, or just plain breaks your app. An example would be the updates to the calendar API's in Android 2.2. Every calendar widget in the market that tied into the built-in calendar app ceased to function because the way it interacted with outside apps had changed.

So the lock is not in reference to developer or unreleased hardware, it pertains to developer or unreleased software or OS?

They would check build/version number in the build.prop or whatever they use... It's just like how FroYo builds couldn't see protected apps while it was in pre-release.

garfnodie said:
So the lock is not in reference to developer or unreleased hardware, it pertains to developer or unreleased software or OS?
Click to expand...
Click to collapse
yes this is correct. The developer phones have different software that allow native root access and this would be defined in the build.prop . That would also allow people to rip applications and pirate them.
That switch is mainly a quality assurance/anti-piracy measure.

ATnTdude said:
Because you haven't tested your app on a new OS build, and want ensure compatibility before offering it for sale. Other reason is that the new OS build either obsoletes, duplicates, or just plain breaks your app. An example would be the updates to the calendar API's in Android 2.2. Every calendar widget in the market that tied into the built-in calendar app ceased to function because the way it interacted with outside apps had changed.
Click to expand...
Click to collapse
Actually, those apps that broke, broke because they were using private APIs. As explained, if you stick to public APIs your app should not break when updating OS iterations because ALL APIs are frozen as soon as a release is cut.

Here's another question then, are app's allowed to do automatic bug reporting back to a developer with out the user consent, or even with the users consent. It seems to me that say Google is testing Android 3.0, and one of their in house testers decides to install your app, but your app does not support 3.0 for whatever reason, if there is automatic bug reporting, you could be made aware of a potential incompatibility with a new API and have time to fix it long before the new OS is ever released. This all could never happen though if you have the market filter set.

garfnodie said:
Here's another question then, are app's allowed to do automatic bug reporting back to a developer with out the user consent, or even with the users consent. It seems to me that say Google is testing Android 3.0, and one of their in house testers decides to install your app, but your app does not support 3.0 for whatever reason, if there is automatic bug reporting, you could be made aware of a potential incompatibility with a new API and have time to fix it long before the new OS is ever released. This all could never happen though if you have the market filter set.
Click to expand...
Click to collapse
bug reporting is going to be a new feature of 3.0. I dont think many if any apps have their own built in bug reporting. Also it really is on the developers side if their app doesnt work with new OS revisions. They should program their apps in such a way that they wont have to make drastic changes for updates. Google also give plenty of time for developers to make fixes before the first iterations of the new update goes out (almost 1 month in the case of froyo)
however some developers just dont care (e.g Co-Pilot)

Related

Necessary Changes in The Android Market..

If this isn't in the right place, please move it mods.
Basically I think that the market is a bit incomplete.
There are changes I'd like to be made and i've voiced my concerns with google.
Now I need the community backing to actually see these things implemented.
To read about the suggestions and comment, visit this link
http://www.google.com/support/forum/p/Android+Market/thread?tid=3c9422da6b79a597&hl=en
I try and address problems with the market and even underlying Android issues that have yet to be resolved.
Add your input and they'll have to listen.
Good idea... You might also add to the list a way to delete apps from download that won't be used anymore. I have three in my download that I will never install again and can't get them off the list. Imagine a few of those in there and it starts to take up alot of space with apps you aren't interested in anymore.
I posted a reply there as it seems to have gotten some attention there. Some of the issues are already in feature request on android issues, I linked to them. Starring the issues increases chances someone will take care of it.
Suggestion added Jeffro.
Thanks for posting Areinu!
If I could make suggestions for Android Market:
(1) Fix all this missing protected apps for new device / firmware quickly
http://forum.xda-developers.com/showthread.php?t=665742
This is silly issue and will only hurt Android platform. This will greatly discourage Android developers for making good apps.
I want to support Android, I want to make it success! I can do this by spending money on Android apps, but I simply cant because of this issue.
And I am afraid this will repeat once new firmware released.
Take a look how long this issue is ... ridiculous
(2) Remove restrictions on countries for purchasing apps
Right now, certain countries like Sweden for example cannot even see the apps!
(3) Add ability to FILTER apps TITLE
I want to "hide" all those WALLPAPERS, SEXY whatnot.
Android is nice, really nice platform. But this Android Market issues are blocking its success.
here in Denmark we can't even see non-free apps in the ma market. because of this, users of ex. iPhone won't even try the platform. its sad really.
Sent from my HTC Legend using the XDA mobile application powered by Tapatalk
Filtering is very much needed. I tend to view the 'just in' apps, but lately its just a list of MMCANDROIDs latest releases of boarderline under age Asian girls. Its really annoying that you cant block out the stuff you have no interest in.
I'm adding them as they come.
Post a comment on the page to make sure Google eventually sees it.

Protecting Privacy - Compiling TaintDroid into Kernel to find leaky apps

Most people don't yet know that many Android software leak all sorts of information to the internet with only scant user acknowledgement (basically what you accept when you install the app).
Due to this and the fact that there are already privacy information harvesting apps for Android on the marketplace - a team of security experts have created TaintDroid:
What is TaintDroid?
From the project's web page: "A realtime monitoring service called TaintDroid that precisely analyses how private information is obtained and released by applications "downloaded" to consumer phones."
From: http://appanalysis.org/index.html
How can I install TaintDroid?
As TaintDroid is currently compiled into the kernel, you cannot easily install it, but you have to cook your own kernel. Instructions (for Nexus 1) are available at the project web site: http://appanalysis.org/download.html
How does TaintDroid work?
Here's a video demonstrating how TaintDroid works once it is installed and configured:
http://appanalysis.org/demo/index.html
Why would you want to install this?
There can be many reasons for installint TaintDroid:
- You want to learn about privacy features and play with Android kernel
- As it is currently impossible to differentiate between innocent and sneaky Android apps based only on what access rights they request, you may want to dig in deeper
- You are worried about what apps are doing behind your back and you want to know which apps to uninstall
- You want to help create Android a more secure and privacy-protected platform, instead of the swiss cheese it currently is
What can you do?
As compiling kernels is mostly beyond the reach of mere mortals currently, consider cooking TaintDroid into your kernel, if you are cooking one yourself and offering it available for others to try and use.
Hopefully increased awareness and usage will bring this program eventually into other modders and perhaps even Google's attention and something more easily accessible is offered for the public at large.
BTW, I'm just a user, interested in getting TaintDroid on my own Galaxy S. I'm not affiliated with the research program, but I like what they are doing. This information is purely FYI.
+1 for the idea
Sent from my GT-I9000 using XDA App
+1
Since we cannot expect information gatherer Google to come up with a good privacy protection mechanism soon I think we are forced to take measures ourselves.
I also learned that several of my bought applications are constantly forcing me to enable synchronisation and/or 3G internet. They either randomly uninstall (Asphalt 5), their icons disappear (for example: Mini-squadron) or won't start, with (Schredder Chess) or without a message. Angry Birds Beta2 lite (free game) and Hungry Shark are 2 more examples. So much for an incentive to buy games...
It would be great if applications used a well-defined mechanism to check their validity on-line, and not have this sneaky, lingering attack from all sides to any privacy or battery consumption aware user.
I can not cook Kernels, but this is something i want to use.
Not that i am worried, but i dont know what apps are sending when you open them. Thats something i want to know!
I am sure i am not the only one.
+1
Yes please... This should be in all android phones... as a security option you could turn on!!!
Antonyjeweet said:
Not that i am worried, but i dont know what apps are sending when you open them. Thats something i want to know!
Click to expand...
Click to collapse
And do some of these applications only send stuff when you open them?
--
From a user perspective it currently is really difficult to judge applications that need to start at boot-up and deal with many facets of your computer (Launchers, tools combining lots of divers features).
Do you know some ROM where Taindroid is included?
I've posted in hardcore and laststufo kernel threads to ask if they could add it.
We just need more people wanting it so they think about adding it
exadeci said:
I've posted in hardcore and laststufo kernel threads to ask if they could add it.
We just need more people wanting it so they think about adding it
Click to expand...
Click to collapse
glad you did that
+1 support the idea. hope some of our hardworking kernel builders will add this in.
My concern is how much another real time service will affect battery life. For people trying to make the leanest, fastest kernel I'm not sure it's viable.
I have been wanting TaintDroid built into android by default since the day it was announced, but I really do not think google cares about this, so please, please ROM cookers out there (Maybe Doc?), lets add this into our galaxy S roms.
Well, this seems to work only on android 2.1
Make it so.
+1
Combined with walldroid (or other firewall) this could put back power into users hands. Would really love to see this inside hardcores kernel. Maybe as an option for the stable releases?
+1
This should be the next standard in aAndroid
idea about spoofidroid application
how about a program to spoof or make the phone send fake:
GPS location,
IMEI,
phone number,
simcard id,
etc... information to applications that ask without permission.
this way you can feed these application with information they want but without breaking your privacy. (both end sides are more than happy)
-----
nice option to have:
1) enable/disable auto generate different id every time.
2) allow list / ban list of application to have real or fake id.
3) enable/disable notify for application request.
-----
there are all ready applications that fake your simcard PLMN mobile network codes without the need of kernel rights, but you need to enable disable the flight mode to restore the default code.
===========
good luck to spoofidroid or similar applications.
Jumba said:
My concern is how much another real time service will affect battery life. For people trying to make the leanest, fastest kernel I'm not sure it's viable.
Click to expand...
Click to collapse
I hope there will be developers out there who prioritize privacy/security over speed/battery and storage usage.
I'm the project lead of the TaintDroid system. We are currently working on a few extensions of TaintDroid but unfortunately are short on engineering resources to port TaintDroid onto other systems than Nexus One that we originally developed. We'd greatly appreciate it if XDA developers would take on this effort! Many ongoing projects would hugely benefit from having easy-to-run TaintDroid ROM available for many different devices and upcoming Android systems let alone user benifit.
Thanks,
Jaeyeon
Research Scientist @ Intel Labs Seattle
Ettepetje said:
I also learned that several of my bought applications are constantly forcing me to enable synchronisation and/or 3G internet. They either randomly uninstall (Asphalt 5), their icons disappear (for example: Mini-squadron) or won't start, with (Schredder Chess) or without a message. Angry Birds Beta2 lite (free game) and Hungry Shark are 2 more examples. So much for an incentive to buy games...
Click to expand...
Click to collapse
beta2 lite? i think that was malware, make sure it came from rovio otherwise it's fake and you should delete it.
It's really scary to see with the lookout app how many apps can access to your imei, telephone number "Read Identity Info", can access your contacts, track your position, and can send out all this data.
Here a HTC Desire user, asking for some privacy.
Best regards!

[Q] Syncing apps to multiple devices

I just bought a Xoom tablet and so far love it. I also own an Inspire 4G which is rooted and has many apps installed. I noticed soon after first sync that the apps from my phone are now on my tablet. I assume they are they apps listed in the Market which is ok except that it seems that they are "small screen" versions if there is such a thing. Is there a way to block or stop syncing to certain devices while allowing others? Am I clear whith this question? Do large format apps exist? Will the market auto download the correct version of the app depending on the device?
Just started to get up to speed with Android on my inspire, now comes another learning curve!!!!
Thanks in advance.
For most apps, there is only one version which the author can update to include our tablet (16:10) format. It's not that "small" versions are being downloaded, it's just that the version doesn't yet take full advantage of the extra screen size on our tablets. It's worth searching though, because some apps may have a larger (or tablet-specific) version abailable. Or, you may find another developer has a similar app optimized for the tablet. But, for the most part, the apps come in one flavor and as the author has time (or need), they can/will update the app for Honeycomb support.
Hope this helps to answer at least part of your question...not sure about stopping the process once it has started. I know that the first time you setup your account on some android devices, they will start downloading any apps you have in your library. My Xoom didn't though... Probably because I canceled the initial setup purposely then did it manually later. Doing it manually will bypass the app download as I recall.
As always... Great support on this community driven site!!! Thanks.
I suppose I will next look to perhaps rooting, although, as yet I see little need. Haven't noticed the bloatware that so burdened my Inspire4G.
I think there is also a "compatibility" setting on the Xoom that you can uncheck...in Applications??? that will allow the apps to show full screen, though they may be jaggy. Search for it...it might work for some of your "Must Have" apps=win!
Also, the market should show you a tablet specific selection of apps.
Good luck.

ExtensibilityApp class in WP 8.1 Silverlight

Hi all,
If you've read the text that USED to exist here before, scratch that. Big Thanks to @Sunius1 for clarifying what I thought was a win. Due to this, I DID find something interesting in regards to the ExtensibilityApp class (Windows.Phone.System.LockscreenExtensibility.ExtensibilityApp). I happened to also find a hidden capability "ID_CAP_SHELL_DEVICE_LOCK_UI_API" (Seems to be a locked CAP because it only works on Emulator. I get a deployment error on my if I try including this capability). I suspected that these two worked together, but I wanted to make sure of this.
Before we get started, read through the documentation from this site: http://msdn.microsoft.com/en-us/lib...lockscreenextensibility.extensibilityapp.aspx.
We have the following methods:
BeginUnlock
EndUnlock
GetLockPinpadHeight
IsLockScreenApplicationRegistered
IsSystemOverlayApplicationRegistered
RaiseToastNotifications
RegisterLockScreenApplication
RegisterSystemOverlayApplication
UnregisterLockScreenApplication
UnregisterSystemOverlayApplication
EDIT: After the release of the Live Lock Screen app, my speculations about the ID_SHELL_CAP_DEVICE_UI_API capability and the ExtensibilityApp object were correct. Thanks to @jessenic for finding out a good bit of info on this with me.
It seems that in order to get this working, we have to add an Extension to the WMAppManifest.xml
<Extension ExtensionName="LockScreen_Application" ConsumerID="XXXXX" TaskID="_default" ExtraFile="Extensions\\LockAppExtension.xml" />
In the LockAppExtension.xml:
<?xml version="1.0"?>
<x:Extension xmlns:x="urn:LockApp">
<AppID>AppNameForLockScreen</AppID>
</x:Extension>
As usual, Microsoft doesn't really give us much in terms of documentation.. Probably because it isn't meant to be used by the normal developer Confirmed: For now we have to actually ask for permission in order to use the cap. As to whether we'll get that granted? Who knows....
All of these methods have no parameters at all, but I can almost guarantee this has to do with having an application that can control the lock screen.
This thread will be for efforts in breaking this open and seeing whether we can create lockscreen applications..
Homebrew Lockscreen Apps:
Lockscreen App by @-W_O_L_F-
There are actually two Windows.winmd files in Windows Phone SDK, one for Silverlight 8.1 apps and one for Jupiter 8.1 phone apps (located in C:\Program Files (x86)\Windows Phone Silverlight Kits\8.1\ and C:\Program Files (x86)\Windows Phone Kits\8.1\). There's only one the phone. And some APIs support only one app type (it's phone limitation it seems: faking .winmd file results in Platform::InvalidOperationException, saying you cannot use that API from this app type). That explains why the one on the phone has more APIs available than either of for single app type.
As for LockscreenExtensibility - it's documented, just not available for Jupiter apps:
http://msdn.microsoft.com/en-us/lib...ows.phone.system.lockscreenextensibility.aspx
Sunius1 said:
There are actually two Windows.winmd files in Windows Phone SDK, one for Silverlight 8.1 apps and one for Jupiter 8.1 phone apps (located in C:\Program Files (x86)\Windows Phone Silverlight Kits\8.1\ and C:\Program Files (x86)\Windows Phone Kits\8.1\). There's only one the phone. And some APIs support only one app type (it's phone limitation it seems: faking .winmd file results in Platform::InvalidOperationException, saying you cannot use that API from this app type). That explains why the one on the phone has more APIs available than either of for single app type.
As for LockscreenExtensibility - it's documented, just not available for Jupiter apps:
http://msdn.microsoft.com/en-us/lib...ows.phone.system.lockscreenextensibility.aspx
Click to expand...
Click to collapse
Well that is very good to know! Thanks for the clarification. The best part is that I was actually able to compile without receiving an error (somehow).
I found something that may be of use in order to get the LockscreenExtensibility working (I just tried on a Silverlight 8.1 app and got access denied).
<Capability Name= "ID_CAP_SHELL_DEVICE_LOCK_UI_API"/> <----. Can't be used OOTB
EDIT: I just tested this in the Emulator and it really IS the capability that the LockscreenExtensibility needs in order for it to work.
snickler said:
I found something that may be of use in order to get the LockscreenExtensibility working (I just tried on a Silverlight 8.1 app and got access denied).
<Capability Name= "ID_CAP_SHELL_DEVICE_LOCK_UI_API"/> <----. Can't be used OOTB
EDIT: I just tested this in the Emulator and it really IS the capability that the LockscreenExtensibility needs in order for it to work.
Click to expand...
Click to collapse
I assume this is the thing Rudy Hyun used to create the lockscreen app at Build?
TheInterframe said:
I assume this is the thing Rudy Hyun used to create the lockscreen app at Build?
Click to expand...
Click to collapse
I speculate that this is what he's using. I bet there's more going on that we have yet to figure out. It also could be that the base class EXISTS, but the full implementation isn't available yet. Who knows.
snickler said:
I speculate that this is what he's using. I bet there's more going on that we have yet to figure out. It also could be that the base class EXISTS, but the full implementation isn't available yet. Who knows.
Click to expand...
Click to collapse
Ah, Yes that makes sense. I wonder if there are any other "half-baked" API's in the SDK?
Edit: I Know it sounds stupid but honestly I think we should have a thread dedicated to finding odd API's (Just found one: Windows.Phone.System.SystemProtection, nothing terribly useful though)
TheInterframe said:
Ah, Yes that makes sense. I wonder if there are any other "half-baked" API's in the SDK?
Edit: I Know it sounds stupid but honestly I think we should have a thread dedicated to finding odd API's (Just found one: Windows.Phone.System.SystemProtection, nothing terribly useful though)
Click to expand...
Click to collapse
there are also some hidden APIs in the current SDK for 3D Touch-enabled Apps!
From WP Central:
Some of the features include APIs for gestures, side interactions and even heat maps.
Crazy stuff.
Believe it or not, some of these APIs for developers are in the current SDK, they're just not visible. What this mean though is developers will have access to this 3D Touch technology for their apps. It also means that Microsoft will have a small batch of third-party apps supporting this 3D Touch technology on launch day.
Click to expand...
Click to collapse
source: http://www.wpcentral.com/microsofts-next-flagship-windows-phone-november-3d-touch
Yea, even though those 3D touch APIs may be available, they're not particularly useful, as they require special hardware to work.
Sunius1 said:
Yea, even though those 3D touch APIs may be available, they're not particularly useful, as they require special hardware to work.
Click to expand...
Click to collapse
That is true. Sort of of a side question though, has anyone made a OEM account and looked over the API documentation there? There maybe some useful things we could learn about WP and maybe further a jailbreak for all WP devices....
TheInterframe said:
That is true. Sort of of a side question though, has anyone made a OEM account and looked over the API documentation there? There maybe some useful things we could learn about WP and maybe further a jailbreak for all WP devices....
Click to expand...
Click to collapse
API isn't much useful as long as you cant really use most of functions due to policies.
ultrashot said:
API isn't much useful as long as you cant really use most of functions due to policies.
Click to expand...
Click to collapse
Ah, Yes that makes sense....
http://www.wpcentral.com/joe-belfiore-announces-new-updates-sheds-details-lock-screen-app
Sounds like there will be a dev preview update to enable lockscreen functionality quite soon. Joe also mentioned keeping the lock screen in memory. So 512 MB devices won't get the functionality soon....
Good stuff. Another question: can apps show the action center? Because I want code an app to show notifications on lockscreen. Thanks
Marocco2 said:
Good stuff. Another question: can apps show the action center? Because I want code an app to show notifications on lockscreen. Thanks
Click to expand...
Click to collapse
something to force the volume/music control on the lock screen to automatically open would be really useful as well
Updated first post with some more data since the Live Lockscreen App debuted yesterday. There's more I didn't get into, but I want others to dig in and find out
I suppose we can only speculate how it works at this point, but if I had to guess, it goes like this:
1. You have 2 projects in your LockScreenApp solution, one for the application to register the lockscreen, and the second one for the actual lock screen application.
2. The former would use ExtensibilityApp APIs to register the the second one, coupled with the manifests so it's all "valid".
3. The second application is just a another app that is able to process input and draw whatever it wants on the screen. That would explain why there's a delay at it starting when you press lock screen button while the phone is sleeping (probably it's a time for .NET to startup? Direct3D app should be able to start much faster).
Although this is only speculation, I think this makes sense, because that's how background tasks work on Windows, at least. I wonder though, why Microsoft is not releasing the APIs to be used in public - are they afraid somebody will make a lockscreen application that will drain the battery fast or something?
Sunius1 said:
I suppose we can only speculate how it works at this point, but if I had to guess, it goes like this:
1. You have 2 projects in your LockScreenApp solution, one for the application to register the lockscreen, and the second one for the actual lock screen application.
2. The former would use ExtensibilityApp APIs to register the the second one, coupled with the manifests so it's all "valid".
3. The second application is just a another app that is able to process input and draw whatever it wants on the screen. That would explain why there's a delay at it starting when you press lock screen button while the phone is sleeping (probably it's a time for .NET to startup? Direct3D app should be able to start much faster).
Although this is only speculation, I think this makes sense, because that's how background tasks work on Windows, at least. I wonder though, why Microsoft is not releasing the APIs to be used in public - are they afraid somebody will make a lockscreen application that will drain the battery fast or something?
Click to expand...
Click to collapse
I don't think its that but most likely the fact that the API is un-optimized, some of the facts you stated (i.e. Slow start up, documentation is lacking) etc... The fact the OS needs to be updated to show a section telling the user what lock screen app has taken over (since the setting page doesn't now)
Edit: Remember what Joe said about keeping the lockscreen in memory and 512MB devices might not be supported for that reason? Yeah seems like they aren't doing that since you can see the resume time for the lo screen is wayyy to much
Sunius1 said:
I suppose we can only speculate how it works at this point, but if I had to guess, it goes like this:
1. You have 2 projects in your LockScreenApp solution, one for the application to register the lockscreen, and the second one for the actual lock screen application.
2. The former would use ExtensibilityApp APIs to register the the second one, coupled with the manifests so it's all "valid".
3. The second application is just a another app that is able to process input and draw whatever it wants on the screen. That would explain why there's a delay at it starting when you press lock screen button while the phone is sleeping (probably it's a time for .NET to startup? Direct3D app should be able to start much faster).
Although this is only speculation, I think this makes sense, because that's how background tasks work on Windows, at least. I wonder though, why Microsoft is not releasing the APIs to be used in public - are they afraid somebody will make a lockscreen application that will drain the battery fast or something?
Click to expand...
Click to collapse
You are correct. Two projects: One is the settings page, which is the main entrypoint of the app when it's opened from the start menu and the second one is the actual lockscreen app.
The settings page uses the ExtensibilityApp APIs to register the second one as a lock screen application. That second application is another 8.1 Silverlight app that uses a LockScreen_Bridge WinRT component that has native access to read what is shown on the lockscreen from the WP Settings item.
It then uses some storyboards to make it do different things as you're swiping up and down on the LayoutRoot grid. It does use a timer so that's where that little lag comes from.
The only background stuff it's doing is latching on to system events ("Start button being touched for example").
I can see where MS would be protective of this. They DID say that they would be releasing a public version of the API at some point. I'm hoping it's not one of the situations that leaves it public only when they've approved you to be able to use it.
It does suck that it's restricted to 8.1 Silverlight though. I could see some Music Apps wanting to take advantage of the lockscreen like this.
snickler said:
You are correct. Two projects: One is the settings page, which is the main entrypoint of the app when it's opened from the start menu and the second one is the actual lockscreen app.
The settings page uses the ExtensibilityApp APIs to register the second one as a lock screen application. That second application is another 8.1 Silverlight app that uses a LockScreen_Bridge WinRT component that has native access to read what is shown on the lockscreen from the WP Settings item.
It then uses some storyboards to make it do different things as you're swiping up and down on the LayoutRoot grid. It does use a timer so that's where that little lag comes from.
The only background stuff it's doing is latching on to system events ("Start button being touched for example").
I can see where MS would be protective of this. They DID say that they would be releasing a public version of the API at some point. I'm hoping it's not one of the situations that leaves it public only when they've approved you to be able to use it.
It does suck that it's restricted to 8.1 Silverlight though. I could see some Music Apps wanting to take advantage of the lockscreen like this.
Click to expand...
Click to collapse
Quite interesting...!
The API in itself is quite powerful, custom lockscreens with weather animations are possible! http://wmpoweruser.com/wp8-1-live-l...amazing-lock-screen-weather-animations-video/

[Q] is there a patch for this bug 13678484 (fake id)

can anyone make a patch for all variants of hd2 roms from gb up i used the bluebox app to check if my phone was vunerable for this bug 13678484 (fake id) and my daily driver barebone cm7 v2b was, and id say all roms developed for hd2 are vunerable have searched the net for how to patch this vunerability but cant find the info abywhere this is something i think all xda devs for this device will have to sort out as we cannot get help from carriers on this as this is what advice is given "contact your carrier or phone vendor for patch. if anyone has advice on how to sort this out would be very thankful i think xda should run a piece about this vunerability and what steps are being taken by all devs on xda to patch this vunerabilitu for older handsets likemy hd2.
Bluebox Security revealed a significant security flaw that affects all Android devices since version 2.1. Our hyperbolic title mocks the fact that he had little to ignite the Internet powders. If the fault is real, it should take a step back and put the case in context instead of screaming panic for nothing.
A serious flaw that affects a large number of terminals
Very schematically, the fault Fake ID allows malware to authenticate using the signature of a known application to hide its true origin. The firm provides an example of a virus masquerading as an Adobe Systems and Google software which would be able to become a Trojan horse or steal data used by Google Wallet acquiring the necessary permissions without using the user.
The flaw is serious. However, Google has already been made ​​aware, he has already released a patch he sent to his partners, he corrected the flaw in Android 4.4 KitKat, he scanned the Google Play and can say that no application in its store uses this vulnerability. Finally, Verify Apps, which monitors the behavior of applications on an Android device, is also fixed and can detect an application attempting to exploit Fake ID.
A patch already in place and a flaw in a very limited scope that still show that Google still has work to do in terms of security
In short, it is true that it is possible to be a victim of this fault, but it requires a terminal that has not been updated, download an application containing malware does not come from Google and Play Verify Apps have disabled or have an Android version of which is free. Suffice to say that the cases in question are very limited.
This flaw shows that Google still has work to do in terms of its security strategy. Last month, we décriions lax features the Play Store. Today, we are dealing with a flaw of a limited scope, but was discovered by analyzing the shortcomings of the source code of the operating system.
This flaw shows that Google still has work to do in terms of its security strategy. Last month, we décriions lax features the Play Store. Today, we are dealing with a flaw of a limited scope, but was discovered by analyzing the shortcomings of the source code of the operating system.[/QUOTE]
while the info you have given is fine and i thank you for it, but there are other app stores people use beside google play store and reading up on this bug it is still possible their phones could become compromised downloading apps from them?
A Big Big Thank You
Just an update: opssemnik backported the fake id xposed module and it works perfectly with gb roms a big big thank you to him. he also supplied a link in the comments on http://www.xda-developers.com/android/fight-fake-id-vulnerability-xposed/ So once again a big thank you to opssemnik

Categories

Resources