I found several topics where arises the same question, but they're pretty old and most of them don't have a definite answer, or the answer is applicable to iOS only. Also some sources say it's prohibited while other disagree.
For example, here or here about iOS.
I'm interested whether IOKit can be used for macOS applications - note! macOS, not iOS - to get only battery information.
If no, I'd like to find out, how apps like Battery Health work.
What are your guesses? Thanks.
The IOKit.framework is a reasonably well documented, public API on macOS. Many apps and most 3rd party device drivers use it. For the Mac App Store, entitlements restrictions apply.
Regarding Mac battery status, you probably want to take a look at the IOPMPowerSource/AppleSmartBattery objects. The output from running the following command on the Terminal should give you an idea of what information is available:
ioreg -w 0 -irc IOPMPowerSource
The AppleSmartBattery source code is available, that's probably your best reference.
Related
How is VirtualHere able to virtualize USB devices on macOS without requiring the user to install kernel extensions?
As far as I am aware, there's no documented way to virtualize USB devices on macOS.
The USB/IP project, for example, only supports clients on Windows and Linux.
I understand this is proprietary software but it must be using some technique available to userspace?
Thanks
Really interesting.
Seems they are using the IOUSBHost.framework, which is at most undocumented.
Using it requires getting custom entitlement from Apple:
com.apple.usb.hostcontrollerinterface, which could possibly take a lot of time.
There are some traces that it could be used to create virtual devices, but no details about it.
You could try to use tools like classdump to get some information directly from the framework, or read some headers on github.
It would be great if someone could share any information about it with community, as Apple seems to be very lazy about doing this.
I am working on an ibeacon app and I am worrying about that others might sniff the proximity UUID of my app. So i did some research and found this article: http://developer.radiusnetworks.com/2013/10/21/corebluetooth-doesnt-let-you-see-ibeacons.html
It basically stated like others that apple DOES NOT ALLOW you to do this. but then i found some mac app like this one: https://github.com/liamnichols/iBeaconScanner
I did some test and it really can show me the UUIDs. Does there has any ways to prevent even those mac or android app from getting my proximity UUID?
The "CoreBluetooth Doesn't Let You See Beacons" blog post you mention was specifically about iOS. On that platform, the operating system's public APIs do not allow you to detect iBeacons unless you know the identifier up front.
The iBeaconScanner program you reference is for OSX, which does not have the same restrictions. On OSX as well as on Android, Linux, Windows and other platforms, you can scan for beacons and read the identifiers without knowing them up front.
I once used the Android Locate app to read the beacon identifiers at the Apple Store, and then made a beacon with the same identifiers and was able to pop an Apple Store welcome message on an iPhone.
You cannot prevent other people from doing this. You need to design any system that uses iBeacon technology to take this possibility into account.
I spent 10 days trying to debug iCloud connection for my (extra cool) app coming... Its really hard to set up when you use Core Data. Now it doesn't work on device with iCloud on.
I want to ask if there is ready open-source solution to copy&paste code to my app for it finally to run?
Thanks!
***Not interested in iCloud analogs like parse, dropbox...
There's code around, but code is not the problem. In the current versions of Mac OS X and iOS, and in the current version of whatever server side code they're using, Core Data with iCloud often just fails to work. This happens even if your code is exactly right. Start with Apple's sample code (including the SharedCoreData example from WWDC 2012), and if you have specific questions, ask them. But getting the code just right is not enough. File bugs and hope that future versions of Mac OS X and iOS are better.
I am wondering what technologies are used by the new Mac OS AirDrop and if there is a way to use it on windows.
You know that AirDrop is a feature that will be introduced as part of Mac OS X Lion (version 10.7), right? That version of the OS is not even out yet, and it won't be until later this summer.
Furthermore, I assume that the handful of lucky developers who have a pre-release copy are under a strict non-disclosure agreement (this is Apple, and that's pretty standard policy in the industry anyway), which would keep them from giving any details about the feature in a public forum such as this one.
But, since I am not one of those lucky developers, I suppose I'm free to do a little speculating about how it might work. Presumably, it takes advantage of Apple's existing Bonjour network service discovery protocol (formerly known as Rendezvous) to locate other users nearby whose devices support AirDrop. The rest of the pieces have been part of Mac OS X for years, they just haven't been wrapped up in a fancy, easy to use interface (really, that's about all that software development is about nowadays). There's always been rich support for peer-to-peer networking, you've always been able to share files with other users, users have always had a public folder, etc. (This is UNIX we're talking about, after all.)
Will it work on Windows? Maybe. Apple has been surprisingly good in recent history about including its Windows brethren in on the fun—iTunes, Safari, MobileMe, etc. But it doesn't always happen right away. Rolling your own solution for Windows (or any other platform) would be pretty simple, but there's no guarantee that it will be compatible with Apple's.
Bonjour happens at layer 3, so it may be a small part of it.
The real question is how does AirDrop work at layer 2.
Airdrop was reverse-engineerd by the https://owlink.org/ folks. They implemented a free Python version called opendrop as well. The implementation is (unsurprisingly) quite hairy as you need to setup a special Wi-Fi link alongside some bluetooth voodoo, but it apparently works. Or at least it works better than whatever we had before, which was those few question around SE:
Implementing the AirDrop protocol
Is it possible to listen on the Airdrop protocol with my Ubuntu machine?
I'm looking at options to access DVB data on OS X. Initially I want to support the EyeTV DTT USB device, but in the long-run I'd like to support a number of popular devices. The problem I have is that there is no standard way of controlling such devices.
All the applications I know of that use them either hide the driver code within the application (for example EyeTV itself, all it's drivers are implemented totally in userspace and are not accessible to external apps), or they use the seemingly defunkt MMInputFamily driver (no source code availible any more, author gone walkabouts).
I've done some research and found that a number of the devices I want to support are supported within the Linux DVB project. Further research indicates that some years ago there was an attempt to abstract the linux implementation so that it could potentially be recompiled on other platforms. The idea being that efforts to support devices should be pooled and the best way to do that would be to make the current open source implementation work on multiple platforms: it seems in the end to have amounted to little however.
The idea of compiling linux drivers against other *nix type platforms has also been taken up elsewhere with some success. The approach the author took is detailed on the page I linked, it seems potentially viable on OS X as well.
At any rate, there seem to be a number of options, but no clear winner:
Find the source code for the MMInputFamily driver, try to get it working on OS X 10.6 and add support for the devices I require, referrencing the linux source code for pointers. Problem: the source code is nowhere to be found, nor is the author. Additionally it seems the author might perhaps have gone down another route had he fully appreciated the previous efforts to port the linux drivers to OS X.
Attempt to port the linux drivers to OS X in a manner similar to the FreeBSD project I linked. Problem: this is very low-level work and work in this layer is not recommended by Apple if it can be avoided.
Write a driver with OS X's IOKit: this is the preferred method for implementing drivers but I would have to do everything from scratch, clearly not a small job.
If I could I would really like to use the Linux source code, but I'm unsure if such a thing is really viable. Does anyone have any advice or ideas on the best way to proceed with this task?