Is it possible to activate Xposed-modules automatically rather than checking them to be active in the Xposed GUI? Is the enabled status of the modules stored somewhere easily accessible (on a rooted device)...?
You can achieve this by modifying the conf/modules.list file in the Xposed Installer data directory, simply add the path of your APK file to the list.
You should also modify the shared_prefs/enabled_modules.xml file, so that your change is reflected within Xposed Installer (otherwise, the module will be enabled but will show as disabled within Xposed Installer).
The device needs to be rebooted after the change.
Note that this requires root access, since the file is located in the internal data directory of another app. I strongly recommend just going the normal way and opening the Xposed Installer app, and let the user enable the module themselves:
public static boolean startXposedActivity(Context context) {
Intent intent = new Intent("de.robv.android.xposed.installer.OPEN_SECTION");
intent.putExtra("section", "modules");
try {
context.startActivity(intent);
return true;
} catch (ActivityNotFoundException e) {
return false;
}
}
Related
As per Microsoft Intune Documentation.
When an app receives MAM policies for the first time, it must restart to apply the required hooks. To notify the app that a restart needs to happen, the SDK provides a delegate method in IntuneMAMPolicyDelegate.h. refer here
I have implemented the same in Xamarin.
var authResult = await adalHelper.Authenticate();
if(authResult != null && !string.IsNullOrEmpty(authResult.AccessToken)){
var enrollmentDel = new EnrollmentDelegate(this);
IntuneMAMEnrollmentManager.Instance.Delegate = enrollmentDel;
IntuneMAMPolicyManager.Instance.Delegate = new EnrollmentPolicyDelegate();
IntuneMAMEnrollmentManager.Instance.RegisterAndEnrollAccount(authResult.UserInfo.DisplayableId.ToLower());
}
EnrollmentPolicyDelegate:
public class EnrollmentPolicyDelegate : IntuneMAMPolicyDelegate
{
public override bool RestartApplication
{
get
{
var returnedVal = base.RestartApplication;
return returnedVal;
}
}
}
As per documentation, I am supposed to use this property to know when I need to restart the application
I need your help to figure that out. When and at stage, and where I use this property to decide. For me it never gets called.
If you read the document of restartApplication in IntuneMAMPolicyDelegate.h, it says:
This method is Called by the Intune SDK when the application needs to restart because
policy has been received for the first time, or if we're handling a
mam-ca remediation and are restarting as a part of a SW because we
need to remove an existing user.
In my understanding, the method is managered by Intune SDK and you just need to return ture/false to determine who should handle the restart.(That means you don't have to use this property to decide)
Returns TRUE if the host application will restart on its own.
Returns FALSE if the host application wants the Intune SDK to handle
the restart
And I checked some samples, they return false to let the Intune SDK to handle the restart. You can see the source code in Chatr-Sample-Intune-iOS-App and Wagr-Sample-Intune-iOS-App.
I'm trying to build a simple web browser using BrowserComponent. Are there any options to check when a user clicks on a "download" button (how to detect download)? When developing directly with Android, there is an event "onDownloadStart". Is there something similar?
Thanks
We don't support that behavior as it isn't portable. Androids download facility stores files "elsewhere" and requires some additional permissions. Instead you can intercept the URL navigation logic and decide whether you want to perform a download or not, you can then use something like the Util download methods to perform the actual file download.
e.g.:
bc.addBrowserNavigationCallback(url -> {
// *** WARNING: this code runs off the EDT and must not block!!!! ***
if(shouldIDownloadThisURL(url) {
String file = getStorageFileNameForUrl(url);
Util.downloadUrlToStorageInBackground(url, file,
ev -> fileDownloadCompleted(file));
return false;
}
return true;
});
I am developing a mobile application using Xamarin.Forms
I had the following Home page contains login info:
How can we have the application to automatically save the user name, so that they do not have to type it in each time (as in a browser)?
You can use Properties dictionary in Xamarin.Forms Application class. And let the Xamarin.Forms framework handle persisting user name between app restarts and pausing/resuming your app.
Save user name by writing it to Properties dictionary
var properties = Xamarin.Forms.App.Current.Properties;
if(!properties.ContainsKey("username")
{
properties.Add("username", username);
}
else
{
properties["username"] = username;
}
Then, when your login screen is about to appear (for example in OnAppearing method) check Properties for user name:
var properties = Xamarin.Forms.App.Current.Properties;
if(properties.ContainsKey("username")
{
var savedUsername = (string)properties["username"];
}
If it's not there, then it means that this is first time when user log in into your application.
A very similar question was posed just a few days ago - my answer on that question also applies to your question: The best way to save Configuration data in Xamarin.Forms based app?
Essentially, you want to store the information using the native settings functionality. I would advise against using Application.Properties for now. It is currently not reliable on Android, and in the past has had other problems. The nuget package referenced in my linked answer is a better approach and will save you some headache in the future.
The right way to be done is through the App settings plugin
https://github.com/jamesmontemagno/Xamarin.Plugins/tree/master/Settings
What i did in my application is.
1) Installed Plugin.Settings from nuget
2)Added to Helpers->Settings.cs (autogenerated file by plugin) the following
public static class Settings
{
private static ISettings AppSettings
{
get { return CrossSettings.Current; }
}
private const string UserNameKey = "username_key";
private static readonly string UserNameDefault = "demo";
public static string UserName
{
get { return AppSettings.GetValueOrDefault<string>(UserNameKey, UserNameDefault); }
set { AppSettings.AddOrUpdateValue<string>(UserNameKey, value); }
}
}
3)In order to keep the username in the Application Context set
Settings.UserName = ViewModel.Username;
4)When you login screen starts
string username = Settings.UserName;
The answer is simple: persistance. Servers do this by setting cookies containing the data (or reference to it) that they want you to see when rendering the form field.
In order to do this in an app (with Xamarin for instance), you need to store the user's data into a file or database somewhere. Since you're using Xamarin you can probably use some sort of ConfigurationManager to keep track of this.
Obviously you could just create a config file in the local storage you have for your app (I don't think you need permissions to create files in that space).
When you have the info stored somewhere, just retrieve it and set the input's value to it.
I'm writing an application that will run on the Okuma control and have application settings.
Since one of the conditions is that application's settings must be easily backed up, I'm keeping them in the application directory. It works on the control because applications go to the D: but if someone installs the application on a PC on the C drive, the application can't access it's own application directory and it gets errors.
Conditions:
Windows 7
P300 control
Application being installed to D-drive
Has to work if someone installs to the C-drive on a PC
Is there a standard spot to put all application settings?
Continue to keep your application settings and other data in the application's install directory. There is no need to change the directory locations just for a "PC only" install.
The solution to file access issues is to change file permissions during install.
For example, this answer someone posted using WIX installer.
A similar question is answered here.
You could use code similar to this to change permissions during install (when the user has admin privileges)
using System.Security.Principal;
public static void SetPermissions()
{
String path = GetPath();
try
{
// Create security idenifier for all users (WorldSid)
SecurityIdentifier sid = new SecurityIdentifier(WellKnownSidType.WorldSid, null);
DirectoryInfo di = new DirectoryInfo(path);
DirectorySecurity ds = di.GetAccessControl();
// add a new file access rule w/ write/modify for all users to the directory security object
ds.AddAccessRule(new FileSystemAccessRule(sid,
FileSystemRights.Write | FileSystemRights.Modify,
InheritanceFlags.ObjectInherit | InheritanceFlags.ContainerInherit, // all sub-dirs to inherit
PropagationFlags.None,
AccessControlType.Allow)); // Turn write and modify on
// Apply the directory security to the directory
di.SetAccessControl(ds);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
}
I am using WiX Burn to install per-requisites of our project, and I have used ManagedBootstrapperApplicationHost to have a custom UI. I am checking for the Windows Installer version and installing it as a prerequisite, but it requires a restart.
How can I handle a restart in code?
I tried checking it in the following code but the e.status value in case of a restart is also 0.
Code
private void PlanComplete(object sender, PlanCompleteEventArgs e)
{
logger.LogInfoMessage("-------------->> "+ e.Status.ToString());
if (Hresult.Succeeded(e.Status))
{
this.root.PreApplyState = this.root.State;
this.root.State = InstallationState.Applying;
WixBA.Model.Engine.Apply(this.root.ViewWindowHandle);
}
else
{
this.root.State = InstallationState.Failed;
}
}
The engine will return if a restart is required in the ApplyComplete() callback to your bootstrapper application. You can either decide at that moment to accept the restart and return Result.Restart from the ApplyComplete() callback.
Alternatively, you may want to prompt the user on a finish dialog or something to give them an option to accept the restart or not. In that case, you can return Result.Restart from the Shutdown() callback and the engine will do a restart after your bootstrapper application exits.
I tend to do use the second option most often in my bootstrapper applications.