To make WSO2 IOT work with Android in COPE mode, I've installed the org.wso2.iot.system.service with agent.
When I try to enroll Android, it works but system application appears and I see nothing. And I can't enter a PIN code. I have to enter it manually in the app.
The device is enrolled and seems to sync but operations do not work. Ringing sometime loop, reboot does not work (still IN PROGRESS State), wipe does not work, and system service (see capture) appears on every sync.
I generated apk in debugCOPE mode, but adb logcat does not show anything
adb logcat org.wso2.iot.agent:V *:S
--------- beginning of main
--------- beginning of system
--------- beginning of crash
How did you sign system service app? Do you have your own ROM?
As stated at
WSO2 signing system service app
"system app is targetted towards original equipment manufacturers"
According to the product documentation
https://docs.wso2.com/display/EMM330/Integrating+the+Android+System+Service+Application
you should have firmware signing key.
Related
We have to install our CA certificates on end user iOS devices manually or pushed the certificates though MobileIron service for our users. After successful installation of CA Certificates only, our App Users can benefit our services.
As of now i don’t see any option to install CA Certificates on iOS device which is located in AWS Device Farm before running my appium tests.
is there any way to to add and active certificate?
We have to install our CA certificates on end user iOS devices manually
Can you use remote access for testing? You should be able to manually interact with devices. Though admittedly not sure of what is required to install a certificate. I would be worried about the relatively thin cleanup process Device Farm does.
https://docs.aws.amazon.com/devicefarm/latest/developerguide/post-test-and-cleanup.html
Note
It is possible for data to persist between sessions in some cases, especially if you make use of the device system outside the context of your app. For this reason, and because Device Farm captures video and logs of activity taking place during your use of each device, we recommend that you do not enter sensitive information (for example, Google account or Apple ID), personal information, and other security-sensitive details during your automated test and remote access sessions.
This article suggests that this would need to be done using the settings app. If automation is needed then the Appium tests can automate the settings app as discussed in this other article(not tested).
https://appiumpro.com/editions/66
I believe the latest appium xcuitest driver has released support for installing certificates on iOS devices provided you have certain command line tools installed.
https://github.com/appium/appium-xcuitest-driver#mobile-installcertificate
I want to develop a receiver for Google Glass which will detect the WiFi state of Glass and depending on that state show some information to user.
The receiver will listen for android.net.wifi.WIFI_STATE_CHANGED so that I can catch the event and after that check the status of the internet. It will not only detect the internet availability but will also show if Glass is timing out when pinging any specific IP address from any apps of glass.
I have tested the receiver on another Android device and it's working fine. But now I want to test the app on Glass. In order to test, I want to disable WiFi; however, Glass only shows options in settings for forgetting the current WiFi network and connecting to a nearby network.
How can I disable WiFi on Glass temporarily?
From default settings of glass its not possible to disable WiFi. To do the things you have to follow some instructions and install android default launcher and settings so that you can get the settings UI as your android device and do the rest of the desire works.
I am describing the whole process here :
At first you have to download these two apk.
Settings.apk - http://goo.gl/EqV8u
Launcher2.apk - http://goo.gl/ytfSn
After that you have to install these two apps into your glass by ADB :
1. adb install Settings.apk 2. adb install Launcher2.apk
Please be careful not to check the “Use as Default” box or you will not be able to access your Glass Settings until you uninstall Launcher2.apk.
After complete installing go to your settings and select launcher. After selecting android default launcher you will get the setting UI as like as your android device. Now you can do whatever you want like WiFi enable/disable, Bluetooth enable/disable and etc. But there have some issues which not working like Bluetooth Tethering, Data Usage , Airplane Mode and some more features.
Details process of using the settings and launcher and not working features.
If you want to uninstall the installed app at first see your app packages name and delete the app from the devices using below script :
adb shell pm list packages [see all of your installed app list]
abd shell pm uninstall -k com.packagename [your app by specific package name]
After above script you will get your previous glass settings.
Here is the excellent video where all these process has been described in nice way.
Voiding Your Warranty: Hacking Glass
Well as you already know we cannot disable/enable wifi and bluetooth through the native settings application(and I really don't know why). But what we know is that Google Glasses is a bit special Android device on which we can do a lot of stuff that can be done on a regular android device(such as a phone). Among "the stuffs" that can be done is enabling/disabling wifi and bluetooth programatically! In order to do that you must create your own small project and include the following lines:
WifiManager wifiManager = (WifiManager) this.getSystemService(Context.WIFI_SERVICE);
wifiManager.setWifiEnabled(true);
wifiManager.setWifiEnabled(false);
boolean wifiEnabled = wifiManager.isWifiEnabled();
//Disable bluetooth
BluetoothAdapter mBluetoothAdapter = BluetoothAdapter.getDefaultAdapter();
if (mBluetoothAdapter.isEnabled()) {
mBluetoothAdapter.disable();
}
after running your small application that disables wifi and bluetooth you can navigate to your glass settings and see that both wifi and bluetooth are OFF. If you access one of them it asks you to turn them back on. At least it works for Google Glass 19.1 (this is my current version).
I made an app that should let you toggle wifi on and off right from the menu.
Either say "okay glass, power options" or navigate to the card under the "okay glass" menu structure.
Working on bluetooth for later. Based the app on the link below.
my app
https://github.com/afzaman/Power-Options-GoogleGlass
resources:
http://javatechig.com/android/how-to-turn-off-turn-on-wifi-in-android-using-code
So I've got my live card working with the v12 GDK. It responds to a voice trigger and then sits there until the user stops it.
However, I can't determine how to create an always present live card which always remains on the left side of the timeline. Some apps already do this, the Settings app and Weather app, for instance. But I've been unable to make the same happen for my app; I can't find any hook on Glass start like the GlobalAlarmReceiver for normal Android apps.
Am I missing something?
To make a live card that will remain in the timeline even if the user reboots the device, you may want to try the techniques described here to register a broadcast receiver that detects when the system is booted and you can start your service from there.
Your users will still need to use a voice trigger to start it once after installing it, though (either that, or reboot their device, which is even less desirable). This is because on Android, the ACTION_PACKAGE_ADDED broadcast that gets sent when an application is installed doesn't get sent to the application that was just installed.
I have a service (C++) that during its startup might sleep for 10 minutes (error case).
in 2003 - it worked fine, when I migrated the code to 2008 product, Windows Services notify me that the service could not start (my application still alive - but from windows perspective after 1 minute it claims there is a problem..)
-> Though the code was migrated to newer version no change in code flow
-> there is only one thread that starts everything.
-> I can't start the application if this error occurs (I must sleep).
-> Is there any change in 2008 behavior?
Thanks.
There are changes in how session-ids are maintained. The interactive logged-in user would get session-id starting with 1 (In Windows 7/2008), which used to be 0 for previous versions of Windows.
Along with that there are restrictions on how services can interact with the desktop. If service creates/shows windows, it will NOT be rendered to session that belongs to current user, but it would be shown via session-id 0' desktop.
You may check this discussion
I'm am developing a Firefox extension which interfaces with an underlying Windows service (which I have already made).
During the development so far I encountered one bug in the installer program (which installs the FF extension AND the service). This was due to the security model on Vista requiring elevated privileges to be able to install and start the service. I adjusted the installer and now it installs fine (just with additional Vista'esque warning dialogs being displayed to end-users - which I can live with !)
I am now in the process of developing an XPCOM component that will install along with the XUL stuff I have already made. There will be a XUL javascript interface to the XPCOM which will try to do things like stop and start the service (e.g when user-configuration data is changed).
My question: Since FF will normally be run under a user account, will I run into any difficulties on Vista or other Windows flavors trying to start or stop my own service via XPCOM?
(When users run the installer I don't mind security dialogs popping up in Vista. But I certainly don't want this to happen whenever they try to change their info in the XUL interface.)
What is the correct way to go about this?
Yes, if your service is running as an Administrator then the Firefox process, running as a normal user will not be able to start or stop it. However, it appears that you can use the "sc" command to set access controls on your service from your installer, which means you can allow non-admin users to start and stop your service.
You'll need to use "sc sdset", which is documented (lightly) here:
http://technet.microsoft.com/en-us/library/cc742037%28WS.10%29.aspx
However, to use that, you'll need to read up on the "Security Descriptor Definition Language", which looks kind of complicated:
http://msdn.microsoft.com/en-us/library/aa379567%28VS.85%29.aspx
This blog entry appears to have some human-readable information on it:
http://blogs.dirteam.com/blogs/jorge/archive/2008/03/26/parsing-sddl-strings.aspx