Related
Is there a way of creating and deploying an wp7 app that would be only available to our company agents.
As far As I understand this you can only deploy any app via the Market Place - this is useless for any internal business application.
Do I need to wait for better mobile device management or is there away around this ?
Any pointers appreciated guys.
Two ways to do it, the way I see it...
1. Add the program to marketplace, but require an registration number to be inputted in the program for it to work.
2. Side-load it
tiwas said:
Two ways to do it, the way I see it...
1. Add the program to marketplace, but require an registration number to be inputted in the program for it to work.
2. Side-load it
Click to expand...
Click to collapse
2 won't work, as it could be redistributed.
1 might, but we all know how well registration models work (cracks)
this might be a job for phone-home drm.
tiwas said:
Two ways to do it, the way I see it...
1. Add the program to marketplace, but require an registration number to be inputted in the program for it to work.
Click to expand...
Click to collapse
This would probably be the best, especially considering that your agents probably need to login anyway.
But I think that you won't pass certification if they can't test the app.
I don't know what your company does, but maybe you could release an app that is many targeted at your customers and everyone could use. This app could then have a hidden setting to enable special functions after a agent has logged in.
Microsoft are planning on supporting this in the future, their current suggestion, IIRC, is to use some sort of login though.
WP7 desperately need a 3g to wifi tethering app like myfi. I used to have an iphone but switched WP7 and now I need a 'myfi' like app badly.
Can someone some building this app ASAP.
at present it's not possible to even build one as there aren't any APIs for it. I'm sure this has been asked quite a few times on this forum already... please search... rather than just continually asking what people deem as a common requirement. also search the pinned threads as they're a good place to start for missing functionality...
There are APIs. Samsung phones can tether so yh APIs are there. WP7 is just CE with some changes/additions. Microsoft just isn't allowing access to the APIs...
Sent from my HD7 using Board Express
I would think that OEMs have a different set of APIs which provide them with native capabilities. I doubt the OEMs are writting their apps in just C# otherwise MS would have released those APIs as well.
also to note, those phones that can tether is done through the diagnostics, which would imply that they should be already in all windows phones and just dormant. i highly doubt it's specific to samsung phones. it may be that we only know how to do it with samsung phones now.
The Gate Keeper said:
I would think that OEMs have a different set of APIs which provide them with native capabilities. I doubt the OEMs are writting their apps in just C# otherwise MS would have released those APIs as well.
Click to expand...
Click to collapse
That's my point. The APIs exist, as does the base Windows CE system.
We just don't have the development tools nor do we have access to that level of the system to be able to write those applications ourselves.
We're limited to sandboxed Silverlight-based applications, but Microsoft and OEMs can use Native Code and APIs we don't have access to.
They exist, we just don't have access to them. Apple does the same thing with iOS.
Thanks for agreeing with me, though
also to note, those phones that can tether is done through the diagnostics, which would imply that they should be already in all windows phones and just dormant. i highly doubt it's specific to samsung phones. it may be that we only know how to do it with samsung phones now.
Click to expand...
Click to collapse
Which also means WP7 supports tethering. The functionality just isn't exposed to users in the general user interface, that is why you have to dig for it. The same thing is true for Sideloading XAPs, among other things.
It's there. The OS is totally capable of it. WP7 did, in fact, inherit a ton of functionality from Windows Mobile. The difference is that the new UI doesn't expose it to the user, and applications (and the system) are managed in a totally different way.
There's a huge difference between "does not exist" and "exists, but functionality is not exposed in the UI."
Windows on a PC can access drives, etc. by device name, but that is not exposed in the UI - for example. The same is true for many features in WP7 that are there by virtue of it being based on CE and tied (although Microsoft would want you to think differently) to Windows Mobile. They just chose not to expose this functionality.
Not saying it's totalyl based on WM, since that's obviously untrue. If that was the case stuff like full Exchange support, Video support for MMS, etc. would be working.
But the fact that this stuff is there and they're dragging their feet to allow users to use it is what's keeping lots of users off of WP7 at the moment. It's taking them too long to make changes that seem too simple... Maybe for the sake of security, I don't know. They haven't really been transparent with early adopters, IMO.
EDIT: Also, you can call Native Code from managed languages (C#, VB.NET, Java, etc.), so I'm pretty sure they are writing their apps in C# and only calling native code/libraries when they need to. Writing it in straight C/C++ is [potentially] more dangerous than using a Managed Language with Interop. I can't see Microsoft going for that.
As I briefly posted on my blog Monday, Mango will no longer support the deployment of XAPs containing the ID_CAP_INTEROPSERVICES flag. This means you won't be able to deploy your web servers, root tools, and other assorted unsupported hackery.
With our sanctioned, dirt cheap unlock service around the corner, trying to jailbreak NoDo (without upgrade hacks) is a waste of time. I believe the ROI on time spent on hacking this interop limitation is much greater.
This limitation is implemented in PacmanInstaller.exe (on the phone); it scans the manifest for the flag and bails with HRESULT 0x81030120.
As Mango FFUs haven't been released yet, I haven't tested upgrade path 'hacks'; worse, this behavior doesn't appear to be reproducible in the emulator limiting current testing to those w/ Mango phones. (That should change in the next few weeks, hopefully.)
I'm interested to see what ideas you guys have!
How does Microsoft even explain this? What's the point in allowing your unlock officially and then blocking the very functionality we unlock devices for?
Maybe this is a temporary problem?
As far as Microsoft is concerned the new Unlock variant is for people who want to develop for their devices but without intention to publish the results to the Marketplace, e.g. people who want to play around with things.
If you're a Nokia Dev today you get the unlock for free - allowing people to access undocumented APIs is not what Microsoft wants to happen but more to make people experiment with the platform and then perhaps publish their work to Marketplace later on - but that would not be able to happen if those experiments used COM-Interop which is not allowed on the Marketplace.
Well, this way, from an end user perspective, unlocking is useful only for piracy. Getting sideloading without extended capabilities is a weird proposition.
Re hacking Mango, I guess people need to get it on their phones somehow to begin with.
In the other thread I requested that everyone who upgrades makes a wireshark log and post it here, so we can tear it apart. I also left some instductions there.
Plz also let know if apps with native code survive the upgrade and if the chevron unlock with prevent relock survives the update.
Ciao,
Heathcliff74
mfw i already found out a possible solution how to bypass this.
>NoDo needed before Mango.
No trolling. Also, cant say it here on xda, then the Microsofties will pick it up and block...
>Trusted people i can tell, sry.
Thanks for sharing this secret, but up to this moment, Ansar way (flashing stock ROM, then using advanced configuration utility to avoid relocking) is the only effective way.
One could write an application for NoDo, for example a ChevronWP7 Homebrew Enabler, that uses native APIs to modify manifests of homebrew applications found on the phone. Then upgrade to Mango.
There are lots of upgrade scenarios but we have to remember -- new phones will only ship with Mango.
yeah lets tell rafael and his ms homies how the people here try to hack mango, so that he can tell ms to fix it before mango released to everyone.
I hope you wont tell a thing in the public @ fiinix, jaxbox, heathcliff
diboze said:
rafael and his ms homies
Click to expand...
Click to collapse
Really? Rafael informs us of an important issue that we should try resolving, and your response is "OMG he's in bed with Microsoft let's ostracize him"? That saddens me.
@arktronic: please...you cant be this naive...
I won't dignify that with a response.
Oh wait...
There seems to be a way ... for current NoDo users. It is similar to what happened going from original 7008 to NoDo ... in terms of unlocking. I will stop there.
I'm curious, is the ID_CAP_INTEROPSERVICES merely a flag that the xap contains native code, or does the executive actually forbid the application from running native code unless the flag's present?
i.e. could we modify the xap to remove this flag, but still run the native code app on the phone?
elyl said:
I'm curious, is the ID_CAP_INTEROPSERVICES merely a flag that the xap contains native code, or does the executive actually forbid the application from running native code unless the flag's present?
i.e. could we modify the xap to remove this flag, but still run the native code app on the phone?
Click to expand...
Click to collapse
The flag must be present.
diboze said:
yeah lets tell rafael and his ms homies how the people here try to hack mango, so that he can tell ms to fix it before mango released to everyone.
I hope you wont tell a thing in the public @ fiinix, jaxbox, heathcliff
Click to expand...
Click to collapse
You're an idiot.
Here are some things to consider then:
Can something be done to the XAPs to allow the flag? Signing? Other XML file modifications that, in turn, would allow the flag to be used?
Can something be done to the system? A registry change perhaps?
Have any new flags been added to Mango that might also allow low-level system access?
It seems more complicated that just the flag.
Homebrew apps or resigned apps (like Scansearch, or HTC apps) won't run, but official manufacturer apps (Scansearch on LG, HTC apps on HTC) run fine.
So it seems to depends on some certificate.
Also, installing an apps then upgrade to Mango keeps the app on the phone, but it won't allow you to launch it (no error, just launch and quit).
(nico) said:
It seems more complicated that just the flag.
Homebrew apps or resigned apps (like Scansearch, or HTC apps) won't run, but official manufacturer apps (Scansearch on LG, HTC apps on HTC) run fine.
So it seems to depends on some certificate.
Also, installing an apps then upgrade to Mango keeps the app on the phone, but it won't allow you to launch it (no error, just launch and quit).
Click to expand...
Click to collapse
Ah, thanks for testing that. So that means installing an application then upgrading won't be as easy as it sounded.
One test would be to sign a XAP and place your root certificate in the CA store (with Heath's toolset).
diboze said:
yeah lets tell rafael and his ms homies how the people here try to hack mango, so that he can tell ms to fix it before mango released to everyone.
I hope you wont tell a thing in the public @ fiinix, jaxbox, heathcliff
Click to expand...
Click to collapse
I too hope everyone will be a selfish bastard and will never get anything done.
Arktronic said:
Here are some things to consider then:
Can something be done to the XAPs to allow the flag? Signing? Other XML file modifications that, in turn, would allow the flag to be used?
Can something be done to the system? A registry change perhaps?
Have any new flags been added to Mango that might also allow low-level system access?
Click to expand...
Click to collapse
I'm trying some things with the package manager. I haven't got anything yet, but I got some ideas I yet have to try. I'm working on flagging an app as "not being sideloaded".
(nico) said:
It seems more complicated that just the flag.
Homebrew apps or resigned apps (like Scansearch, or HTC apps) won't run, but official manufacturer apps (Scansearch on LG, HTC apps on HTC) run fine.
So it seems to depends on some certificate.
Also, installing an apps then upgrade to Mango keeps the app on the phone, but it won't allow you to launch it (no error, just launch and quit).
Click to expand...
Click to collapse
Ok. So it looks like the package-manager doesn't allow the interop-flag for apps with a full install-cycle through side-loading. The flag is probably allowed for upgrades and marketplace-installs (including DRM licenses). And the PolicyEngine (runtime system) requires the dll's to be signed properly or else it will deny interop to native code.
WithinRafael said:
Ah, thanks for testing that. So that means installing an application then upgrading won't be as easy as it sounded.
One test would be to sign a XAP and place your root certificate in the CA store (with Heath's toolset).
Click to expand...
Click to collapse
Please refer to the opening post of this thread. For the purpose of code-signing the certificates in the "Code Integrity" store are used. The certificates in that store would probably need a signing-root in the CA store. The means that you have to create a certificate that has the properties of a "Code Integrity" certificate AND the properties of a "CA" certificate and then add this cert to both "Code Integrity" and "CA" stores. Then use the private key to sign all the dll's.
If you look at the certs in the "Code Integrity" store, then all, except the one used for LPC singing have this:
Key Usage: Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing (86)
Enhanced Key Usage: Code Signing (1.3.6.1.5.5.7.3.3), Unknown Key Usage (1.3.6.1.4.1.311.10.3.14)
If you look at the certs in the CA store, then you see that they all have:
Certificate Signing, Off-line CRL Signing, CRL Signing (06)
That means that you have to create a cert with:
Key Usage: Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing (86)
Enhanced Key Usage: Code Signing (1.3.6.1.5.5.7.3.3), Unknown Key Usage (1.3.6.1.4.1.311.10.3.14)
Than add this to "Code Integrity" and "CA".
You have to create the cert with OpenSSL. You can't create such a cert with Visual Studio tools.
I already created such a cert. I will create a new version of the WP7 Root Tools and sign the dll's with this cert. And I will make an option to install/uninstall the public cert in "Code Intergrity" and "CA". I advise everyone who wants to try this to first make a backup! Then, when you have this version of the WP7 Root Tools installed and you used it to install the certificates too, then you should try to upgrade to Mango and see if the WP7 Root Tools are still working.
I will let you know when I got this new version of the WP7 Root Tools ready.
Ciao,
Heathlciff74
Full Article
http://justinangel.net/Win81APIs
Bluetooth 4.0 RfComm and GATT support
Point of sale: Barcode scanners and Magnetic card readers
Smart Cards
Lock screen Image Apps
VPN support for Metro apps
Scanner APIs and apps
Support for any External / USB device
Native PDF rendering in apps
Multiple screens projection support in apps
XAML/WinJS: New resolution scaling support / Super-high resolution tablets
Camera: Low-lag cameras / HDR
New Metro App Types: Appointments, LockScreen, Contacts and GeoLoc
New App Type: GeoFenced activation
New App Type: Lock screen call
New App Type: Appointments Provider
Text-to-speech
Read-write access to Camera roll, Saved pictures and playlists
XAML/WinJS: new SearchBox control
XAML/WinJS: Hubs for SemanticZoom
XAML: DatePicker and TimePicker
XAML: Flyout, MenuFlyout and SettingsMenuFlyout
XAML: AppBar simplification
XAML: DataBinding Improvements
Globalization: Currencies, Numeral systems and Numerical formatters
Other minor but important Win8.1 features
Be aware: these are new WinRT APIs, not Windows RT features. WinRT != Windows RT (I usually abbreviate the latter as "WRT" to avoid confusion and for similarity with things like WP8).
With that said, since WinRT is the only official API for developing WRT apps, and since Win8.0 and WRT_RTM support the same WinRT APIs, it's reasonable to assume that the same APIs are coming to WRT and therefore apps using these API features will be available on WRT devices.
Another interesting point is that WP8 uses WinRT as well (though only a subset of it). Hopefully at least some of these new APIs also become available on WP8.1; the obvious candidates are things like alarms and Bluetooth and such, though it'd be great to get *any* kind of VPN support in there...
"Support for any External / USB device"
Does that sound like unsigned (or testsigned, whatever) kernel mode code to anyone else?
Edit: Should probably read the thread closer, this is WinRT stuff.
It's not kernel mode. More accurate would be the ability to write (sandboxed, low-privilege) user-mode drivers using WinRT. That's still cool - it's the first official driver API of any kind, and from a security standpoint I'm way more comfortable about installing WWinRT apps than actual NT drivers - but it probably won't help with unlocks. It does mean you can talk directly* to USB devices, though, which is cool in many ways.
Given the ability to handle unrecognized devices, I'm guessing that apps will be able to register for specific USB IDs (in the same way that they can register for URI schemes and file extensions now) so that the app will auto-start when you connect a device, or so you can search the store for apps which can handle a specific device. This is big. The lack of third-party NT drivers for obscure hardware on RT has been an impediment (one of many) to progress on the platform. Asking people to write their own drivers is probably not going to fly for really complex hardware unless it's also quite popular, but I can see people doing things like writing an ADB app; there's no reason I know of why that needs to be a kernel driver.
* I'm assuming that the new WinRT APIs basically call into a generic NT driver that does the actual device IO. So, it's not literally directly talking to the device in the sense of sending bits down the USB port from your software, but it's still a lot closer to the metal than we could officially get before.
GoodDayToDie said:
* I'm assuming that the new WinRT APIs basically call into a generic NT driver that does the actual device IO. So, it's not literally directly talking to the device in the sense of sending bits down the USB port from your software, but it's still a lot closer to the metal than we could officially get before.
Click to expand...
Click to collapse
Yes, it is probably just a Metro wrapper around the old well-known WinUSB API: http://msdn.microsoft.com/en-us/library/windows/hardware/ff540174(v=vs.85).aspx
And there is a strange question in the article:
Despite the plethora of new VPN APIs, an open question remains as to whether WinRT Win8.1 apps will work by default on VPNs.
Click to expand...
Click to collapse
VPN works fine on RT. At least I can connect to our company VPN with the built-in client and access all our internal resources, for example Sharepoint from the Internet Explorer.
Confusion of "Windows RT" and "WinRT" again*. VPN works "fine" on Windows RT, or on Windows 8, for desktop apps. However, WinRT apps, on either Win8 or WRT, are known to have problems tunneling through VPNs. These new APIs will hopefully help with that, but the question remains whether WinRT (Metro) apps will work *by default* over a VPN, or not.
* I swear, the entire Microsoft branding department, or at least any of them who can't provide proof they didn't argue against this idiocy, need to be stood up against a wall, slapped in the face, by everybody who ever got those two mixed up, and then fired. Much like Windows Phone... at least the complete retard who came up with "Windows Phone 7 Series devices" got the boot, but the result was merely slightly less awful and it hasn't gotten better since.
Being able to write drivers in WinRT level sounds very interesting indeed. I wonder how much integration into the OS will those drivers have, especially, if they are to remain active even when the parent app is not running.
I just hope they bring the entire IO interface of .NET on WinRT. That way we would be able to write drivers from scratch if we really wanted to...
I just want to access to COM ports. Seriously that was a dumb decision on microsofts behalf to block it. Only security threat it poses Tcp also poses so that can't be the reason.
I guess with raw usb access you can try a custom driver to a usb adaptor.
hi
We are developing a Phonegap (Cordova) application to target all major mobile platforms (IOS/Android/Windows Phone/Blackberry). I proposed to my company to make use of something like phonegap as we do not have the resources to spend on dev's learning Xcode (Swift) etc.
There are now a couple of concerns arising though.
We plan on building an app for each platform, but our clients each want their own app or version of the app with their branding, logos etc. So essentially we will have the same app but with different branding for each client on the App store which as stated below is strictly prohibited.
Client A app - (Available to their customers)
Client B app - (Available to their customers)
I quote from Apple's website
"Repeated Submission of Similar Apps
Submitting several apps that are essentially the same ties up the App Review process and risks the rejection of your apps. Improve your review experience — and the experience of your future users — by thoughtfully combining your apps into one."
Will our app(s) be rejected? This is my first concern. Secondly, we plan on developing the android/Windows application but don't have access to a MAC-based intel machine and Xcode, so we will make use of Phonegap Build to build for IOS. We are planning on using aggressive advertising in our apps specifically aimed at that particular client. Is it possible to do custom advertisements with Phonegap and Phonegap build for all the platforms?
I am absolutely new to mobile development, so any help would be greatly appreciated.
i dont think there will be a rejection from apples side in your case. in most cases you wont be uploading different apps for different clients in same developer account.
cordova is the best way to do it since you dont have acceaa to mac machines. you can use cordova remote builds.
try using a better html5 framework with cordova like sencha touch or jquery mobile etc