I would like to detect whether the device (Android and ios) has been previously rebooted before opening the apps. I noticed that there would be many possible ways to achieve it if we could rely on the device clock's time like what has been elaborated here. My concern would be; the device clock can be changed, and the apps can work in offline mode.
Android
My idea would be to store a boolean variable using Android SharedPreferences after device has been rebooted, and set as true. Then check the variable after user opens the apps. If true, then we can confirm that the device is previously rebooted, else not.
ios
I have no idea on how to implement it for ios, but the link above might gives me a hint.
Solution that might works in both platform (not try yet)
If RAM usage cleared after device restart, then I would assume that if RAM usage is on certain level,the device has been rebooted.
Of all the possible ways to achieve the objective, I would prefer to use existing package. But I would happy if you can give your feedbacks for the above ideas.
So my questions would be :
I hate to reinvent the wheel, so any existing Flutter package or any other library which can't be found on https://pub.dev/packages that can be used to detect whether the device has been previously rebooted before opening the apps?
Is there any other possible solution that I missed which already have in Flutter architecture to solve the issue?
Update
I've found a package called boot_completed which only supported on Android.
..and I've found an interesting feature for Android running API level 24
BOOT_COUNT. Horray!
Related
I'm currently working on an app for this kind of device:
link. I want the user to be able to set a timer to shutdown and boot (NOT reboot) at a specific time during the week.
I did a lot of researches but I have't found the answer to my question. Everybody says that's impossible to boot using a timer since the device is supposed to be off. However, in the settings of the device, there is an option "Timer Switch Machine" which allow to do that (as describe in the link above). So I think there is a way to hack this functionality throw my app, if the device is rooted. But I don't know how to do that.
Does anyone have an idea?
This functionality is not part of the AOSP. That means first you have to gain access to the source code (or alternatively talk to someone who has access to it).
You might be able to find the corresponding code by decompiling System apps (especially the app which contains the option).
Otherwise you'd have to find a contact to the developer (probably via the manufacturer).
If you have the sources, the easiest way to hook into it is normally using xposed.
But depending on the actual implementation (e.g. if it's a shell call) there might be a better way.
I'm planning to deploy an app on my android smartphone which is supposed to be used by multiple other persons. Now of course I do not want them to do things with the device they are not supposed to do so I informed myself about several different ways to make it as safe as possible (Lock-down apps, Kiosk mode, Mobile-device-management, Code-tweaks and so on).
I found some solutions that look really promising but they all share the same problem that a user could just restart the device and boot it in safe-mode where those helpful apps won't be started. However, there is one exception: I've installed a MDM app called maas360 which somehow manages to apply the restrictions that I defined even in safe-mode, for example by blocking access to the menu settings. How is that even possible? The thing is just that this is not a free app and it offers a huge variety of functions - overall it seems to be a bit excessive for my goals.
So my general question would be: is it somehow possible to restrict access to the safe-mode somehow? Maybe like a password? From what I understand it is not even possible to set a system password for Android devices that you'd have to enter once it boots (except if you set up a password for unlocking the screen first which would then be the same one... very redundant).
Disabling physical switch of volume down (in case of samsung devices) will stop access to safe mode on device. I dont find any other way to do so.
I am currently working on a research project which involves people playing games on an Android device. I am hoping to be able to write an android app that records the accelerometer and touch events. I would like my users to be able to play games such as angry birds, whilst I record their touching data.
I understand that this type of data collection is possible from inside the app, but is it possible from outside the app? (perhaps via an app running in the background?)
If this is not possible, are there alternatives? (I believe I could theoretically go into the android OS source code and make this happen?)
I understand that this type of data collection is possible from inside the app, but is it possible from outside the app? (perhaps via an app running in the background?)
For touch events, no, for obvious privacy and security reasons. It used to be possible (research the term "tapjacking"), but current versions of Android finally blocked this behavior.
For accelerometer events, you can record those, because they are the same for all apps simultaneously. Bear in mind that your sampling rate may not exactly match that of the app being used.
I believe I could theoretically go into the android OS source code and make this happen?
Yes, though you would then need to turn that modified Android into a ROM mod and install it on devices.
Apps are not allowed to do this on a secured device (ie, consumer phone/tablet that has not been 'rooted').
However, depending on your needs it may be possible with the development tools connected to a computer. If you can do some moderately annoying setup before each controlled-circumstances trial, I believe you can do it on some stock devices by using the USB cable to switch ADB into wifi mode, then monitoring input events over a wireless ADB session. See
http://source.android.com/tech/input/getevent.html
That document seems to imply that 'su' is needed (which is odd as the official 'su' isn't usable by non-root users), however it works without on many stock devices.
You'd probably also want to be running logcat to figure out what application is in the foreground.
I'm trying to develop an app that would normally be considered to be malware, but the customer's demands are very specific and logical. We have around 50-100 cheapset Android phones that are bolted down, plugged in, and the app is supposed to send some of the sensor data via tcp to a remote server. It sounds simple enough, but there are two features that I struggle with (since I'm not an experienced Android developer, and have never rooted a phone):
#1 The app should be always on. If it crashes, server should get the error report (stack trace), and the app should be restarted after 10 minutes one more time before giving up. Also, the OS could theoretically kill the app (although I did my best to minimize the memory usage). I'd like to somehow handle that as well.
#2 It would be great if the app could be remotely updated, or auto-updated, with no user interaction whatsoever (since there is no conventional user).
To implement #1, I see no other solution than to root the phone (AlarmsManager doesn't seem to work as I expected, and adding another application to take care of the first one just feels wrong). Is there anything I'm missing?
I don't know how to approach implementing feature #2 at all. If I put the app on the market and check the "keep this application always up to date" checkbox while installing it, will that work? I fear that the auto-update would not occur while the service is running, and even if it did, that the OS would not restart the service after installing the update (unless feature #1 is implemented). If I programatically download the latest .apk and open it, I still need the user to click the "Install" button. I'm even considering implementing the updateable part in some scripting language.
Is there a solution to these problems within the limits of Android API?
EDIT: Thank you all for your answers, you've been very helpful. It seems that the only way to make Android behave as a non-user piece of hardware is to root it. That's the only way to do silent auto-updates. Always on can then be implemented by enabling cron (AlarmManager apparently doesn't fire the event in case of service termination via crash, but it could be used by another trivial, non-crashable service to keep the first one running).
For #1 you can use an foreground service. I don't know how often you need to get sensor data, but what's the problem with AlarmManager? I don't see how rooting could help with #1 though. You can't really do #2 without rooting or building your firmware. If you install your app as a system app (in /system/app) you can use a hidden PackageManager to silently install the new version. Using Market/Play autoupdate should work as well, but you have no way to control the update schedule. And, yes, it won't restart your service, but if you use AlaramManager, this shouldn't be a issue.
All in all, stock Android is not exactly an embedded system that gives you full control, so depending on how much time/effort you are willing to spend, you might want to customize it somewhat (or find a custom ROM that gets close to your requirements).
Re: question #2, there are a few open-source (licensed under the Apache Software License 2.0) options you may check and see how it works.
https://github.com/lazydroid/auto-update-apk-client is the android client for the auto update service (i'm affiliated with), which is small, easy to implement and supports silent updates on rooted devices.
https://github.com/commonsguy/cwac-updater is written by Mark Murphy, however it might require you to run your own update server and I'm not sure about silent updates.
AFAIK there is absolutely no way to detect the moment when app gets uninstalled.
I am currently writing an app which should among else toggle on/off 3G data. It went ok before 2.3 with ITelephony reflection calls, but from Android 2.3 this is not possible.
So I had to resort to APNDroid-style way of adding suffixes to APNs in content://telephony/carriers. This seems to work, but I stumble on the same problem as APNDroid has: since we can't detect when the app is removed, all the suffixes will remain if the user first turns off 3G with the app and then uninstalls the app.
This is an ugly and dangerous solution, because the end user may be left with all APNs broken.
It's possible to detect uninstallation from another application, but how would one force the user to install another application to just monitor the first one? It seems there is no way from 2.3 on to write a 3G-managing app.
Any ideas?
AFAIK there is absolutely no way to detect the moment when app gets uninstalled.
Correct.
I am currently writing an app which should among else toggle on/off 3G data. It went ok before 2.3 with ITelephony reflection calls, but from Android 2.3 this is not possible.
Which means that you should not be implementing the app as an SDK application. You should have not implemented the app using "ITelephony reflection calls", either.
This is an ugly and dangerous solution, because the end user may be left with all APNs broken.
Which means that you should not be implementing the app as an SDK application.
how would one force the user to install another application to just monitor the first one?
You can't.
It seems there is no way from 2.3 on to write a 3G-managing app.
Correct.
You are welcome to try to contribute changes to the AOSP Settings application, or create a new firmware application, that offers the features you seek.