I looked around, and did a bit of experimentation, and discovered the following. What gets saved automatically when you exit The game saves information about which Zone and Act you've reached. It also saves information about how many Chaos Emeralds you've collected, and how many lives you have left. The game does not save your progress within an Act. Even if you've passed a "Star Post" checkpoint, it doesn't matter. When you reload your save game, you'll go back to the beginning of the Act. How to avoid losing your progress within an Act If you don't want to lose your progress within an Act: You can pause the game, and can go back to the Android home screen, and can leave the game paused for hours or even overnight. If you use too much RAM in one or more other apps, the game may be kicked out of RAM, and you may have to return to the beginning of the Act. But, if not, the game will stay in RAM, and you can resume exactly where you left off. If you have a flagship Samsung phone released in the past five years or so, you can https://forums.androidcentral.com/samsung-galaxy-s20-s20-plus-s20-ultra/995329-locking-apps-memory.html , so that it will stay open indefinitely. However if you use this ability, the game might take up perhaps 300 to 600 MB of your phone's RAM, all day, every day, even if you haven't played it for months or years. If the game crashes or is kicked out of RAM If the game crashes, or if it's kicked out of RAM while you use other apps: All new Chaos Emeralds gained, and all other progress made since the last time the game was saved, will be lost.

Just open your two saves in https://projectpokemon.org/home/files/file/1-pkhex/ . You'll need a computer to access as DeSmuMe (where DSV files are usually created) is a PC-based application, though it has been ported to Android, Wii, Nintendo Switch and various other systems. As for handling the save file itself; just use a https://play.google.com/store/apps/details?id=com.google.android.apps.nbu.files app.

My suggestion is: Do a benchmarking Open most famous schedule apps and see how they solve the problem,write positives and negatives points and each app, and try to apply in yours. Before start the devolpment try to a prototype to.

You can show number of results. Customer will be understand when the number is changed.

A Gyroscope is a device that is used to maintain a reference direction or provide stability. It's used to sense angular rotational velocity and acceleration. It is required in a smartphone, for example, to be able to record and watch 360-degree videos or photo. In a game, for example, it provides a GUI that enables a user to select menus by tilting. Image stabilization is one of the applications, and it prevents the trembling from affecting the quality of the image. It enables smooth rotations and is capable of providing precision motion. And regarding the methods that can be used to compensate the absence of a gyroscope, according to https://www.techaheadcorp.com/knowledge-center/how-gyroscope-sensor-work-in-smartphone/ : Most applications in a smartphone today, work best when there is a Gyroscope sensor in the phone. For instance, the recently popular Pokemon Go game showed how Augmented Reality adds to the experience of gaming, however, what’s interesting is, AR won’t be possible without a Gyro sensor. If your phone doesn’t have a good Gyro Sensor, the same can be enabled using GyroEmu Xposed module in any Android phone.

It appears to be a game called https://play.google.com/store/apps/details?id=com.TwoeGames.FlickMaster3D&hl=en_US&gl=US

With an online SVG optimizer = 46 kb It depends on the final destination of each image. If it were a personal project, knowing that I would only use the vector information, I would not hesitate to use a compressed PDF = 20 kb A PDF saves all vector information and vector drawing programs can open it fully editable.

You could use textfields to display the data (if it is editable). The label above the textfield would be your key ( https://material.io/components/text-fields#anatomy )

tl;dr: eSIM is probably the safest (my confidence is not too high though, read below). The basic choice is between using either a wifi hotspot and SIM/eSIM. Between those two, wifi hotspot seems to have more of an attack surface and seems to be the more common/easy attack. I am not super confident about this though. I just read a lot of Stackexchange answers on the two topics and that is my vague conclusion! I have NOT found a discussion which compares the two scenarios directly ((e)SIMvs wifi hotspot), only discussions on either separately. ESIM is safer than SIMbecause the eSIM cannot be manipulated by someone having physical access to your phone and cannot (or is lot less likely at least) be manipulated in the supply chain (delivering the SIM) which is relevant for attacks exploiting vulnerabilities of "Java Card" ( https://security.stackexchange.com/questions/77532/sim-card-malware-advice ). Also, I guess, the chance of being exposed to the type of SIMattack that allows for the Simjacker exploit (see https://www.blog.adaptivemobile.com/simjacker-frequently-asked-questions%3fhs_amp=true ) is a lot less likely with an eSIM compared to a SIM because eSIM are "new tec" and we can (hopefully) assume that phone manufacturers are aware of this exploit by now (more so than some "stone age" SIMproviders in some countries, see the Simjacker technical report from adaptive mobile which has a map with countries in which SIM providers still ship vulnerable SIM card (configurations)). With that said, regarding the most common form of SIM attack ("SIM swap attack") eSIM and SIM are no different.

Is it safe to assume that access to open ports is blocked by the cellular network's firewall? Nothing in letting the system choose the port makes the port magically blocked by firewalls. There might not even be an explicit "cellular network's firewall" in the first place. There might be some implicit protection due to the use of CG-NAT in many mobile networks - see https://security.stackexchange.com/questions/176744/why-is-nat-referred-to-as-the-poor-mans-firewall . But this is not an actual requirement for mobile networks, so there might be some which don't do CG-NAT. Or it's only done for IPv4 due to the scarcity on IPv4 addresses but not for IPv6. And, like CBHacking commented: NAT or CG-NAT does not protect against attacks from devices which are inside the same network behind the NAT. In summary - it depends on the specific mobile provider. And it might change without notice unless it is an explicitly promised feature. Thus don't rely on it.

For almost all questions asked "is it possible to hack" the answer is yes. There's questions of viability, cost, difficulty and so on, but there's rarely one scenario that is technically impossible. So instead of asking if some hack is possible, ask how likely it is. In your case, someone close to your phone could in theory break into it without even connecting to your hotspot. As Steffen commented, Bluetooth and wifi code has had vulnerabilities that would enable an attacker in radio range to compromise the OS and execute commands. Depending on the apps you have, an attacker could download files from your computer. For example, ES File Explorer had https://www.cvedetails.com/cve/CVE-2019-6447/ years ago: The ES File Explorer File Manager application through 4.1.9.7.4 for Android allows remote attackers to read arbitrary files or execute applications via TCP port 59777 requests on the local Wi-Fi network. This TCP port remains open after the ES application has been launched once, and responds to unauthenticated application/json data over HTTP. If you had the vulnerable version of ES File Explorer and had executed it at least once, anyone on your hotspot could download your files, upload files, execute apps, and install apps (if you gave ES File Explorer permission to install apps). Android has a smaller attack surface than Windows desktop, but the surface exists. It's not possible to protect every single component, and it's not possible to prevent every single attack. Some attacks will depend on installed apps, others on the installed Android version, and others on the hardware itself. And if your handset is not receiving updates anymore, you will not even know if there's any vulnerability in it. How likely is it that you got hacked? No idea. It depends on the skills of the friend using your hotspot, but I would say that, in general, the risks are pretty low.

You can absolutely have as many AVs as you want on your smartphone but if you have a working Google Play installation along with Google services and you only install applications from Google Play having any AVs installed makes very little sense aside from giving you a false sense of security. The other answer about "intercepting system calls" does not apply to Android and is patently wrong. Android does not allow apps any low level access to the system, so you can install all the existing AVs in the market but again it makes zero sense if your system is properly configured and you don't download and install random APKs from the Internet. If you do, a much better idea would be to run them through https://virustotal.com/ In Windows, yes, that's a whole different issue as Windows AVs install low-level kernel drivers and having more than one of them installed may lead to a system malfunctioning. TLDR: Android by default (from a certified vendor) is a secure OS which does not need an AV (as long as it's still supported). If it's not supported and not updated then no AV will protect you from various low-level vulnerabilities, e.g. vulnerabilities in the Linux kernel, or low level Android libraries.

Is this a valid way to do this or it contains some security flaws, if yes what security problems may arise here? You generate the secret on the users device, and then send it to the user. It's probably trivial to rewrite your application to simply tell the server a random phone number, and Yup, this number really verified just fine! This doesn't offer security, and is just a waste of time. To make this secure, the client should transmit the phone number to the server, and the server should generate a secret and send this via SMS to the provided phone number. This is not fool proof, as there's avenues for intercepting or hijacking text messages, but it will be magnitudes better than your current scheme. In addition, as pointed out by https://security.stackexchange.com/users/242928/bk2204 in a comment, Random() https://www.geeksforgeeks.org/random-vs-secure-random-numbers-java/ . It's not meant to be used for secrets, and past codes may reveal future codes, and the seed is commonly the time of the machine - which can be brute forced easily.

This largely depends on the phone and even your country. What follows might only work as described where I am, in Italy, but the concept ought to be valid planet-wide with relatively minor changes. Basically, there exist so-called "Value Added Services" that can be accessed through either javascript or HTTPS API calls, hosted on your phone carrier's website. Weather alerts, jingles, gossip news or news alerts. When I access https://(my carrier)/api/subscribe/{vendor}/{service}, the phone carrier website recognizes my IP and tracks it down to my SIM (it can do this because it is my carrier, and has all my billing information), and validates a VAS subscription on my phone bill. From then on, I'll be billed whatever and whenever the vendor and my provider agreed to (e.g. 5 Euros per week). It is mandatory for the vendor to first show me the contract, ask for confirmation and blah blah and explicitly get my consent, before redirecting me to the VAS subscription. Otherwise, the whole transaction is illegal and void, and if I realize it took place, and if I know that I can, and how, I can appeal within (IIRC) 90 days and get my money back. But of course a dishonest vendor might register as a VAS supplier with my provider, then just hide a "script src=https://..." in a web page and send it to my phone. Or to my computer connected through a WiFi cellphone router: the SIM that counts is the one on the router, the one that connected to the Internet. Hoping I won't realize, or I won't ask for my money back. Yes, you were using TOR browser, but it's possible to trick the browser into revealing the true IP. Or it can trigger a DNS request to a DNS server that is in enemy hands, using a unique domain name. Once certain having got your real IP, they can forge a request in your name (some services allow(ed?) the IP to be externally specified, so you could, maybe still can, subscribe someone else entirely). The carriers, no use saying otherwise, are in on the scam and do as little as possible to make life difficult for scammers. Rather the contrary. They can't actively promote such, but they get their piece of the action, and so they won't proactively inform you or be too keen in supplying you with the necessary defenses. What happens if you have a 2FA or similar confirmation on your SIM? Exactly what you experienced. The call goes through, but then a confirmation is asked, and since you do not recall having asked anything, you refuse it. Why does the antivirus not recognize it? Because it is not a virus, it is a Webpage request. And a legitimate webpage request at that: the antivirus has no way of knowing that you did not consent and never even knew the request was being made. Can it still happen? Yup. Of course. What to do to get rid of it? You can do nothing. Some of those requests come from advertisement javascript that might be displayed on legitimate pages you know and trust, that merely trusted the ads they are displaying. But now the useful question: How do I prevent being scammed out of my money, one subscription at a time?. You ensure that no VAS can be subscribed in your name (ask your carrier: I have "VAS block" active on all my SIMs since I, too, was burned), and activate 2FA wherever possible. If the carrier refuses or hasn't VAS block or 2FA, just change carrier.

Antivirus software on Android don't have access to TLS encrypted traffic. And there is also no way to modify the system as app or user to make TLS decryption possible. Therefore an antivirus software can not detect any data leakage to a remote server if the app uses TLS encrypted communication. If the app had been installed from Google Play store or via side loading does not matter.

Yes. Flash memory chips can be removed and read, even though the phone does not boot. If the storage is encrypted, they will obviously only read the ciphertext, not the cleartext. It may possible provide access through a USB debugging environment as well.

This is answered in the https://labs.f-secure.com/assets/BlogFiles/mwri-drozer-user-guide-2015-03-23.pdf , specifically Chapter 3.3 Identify the Attack Surface: For the sake of this tutorial, we will only consider vulnerabilities exposed through Android’s built-in mechanism for Inter-Process Communication (IPC). These vulnerabilities typically result in the leakage of sensitive data to other apps installed on the same device. We can ask drozer to report on Sieve’s attack surface: dz> run app.package.attacksurface com.mwr.example.sieve Attack Surface: 3 activities exported 0 broadcast receivers exported 2 content providers exported 2 services exported is debuggable This shows that we have a number of potential vectors. The app ‘exports’ (makes accessible to other apps) a number of activities (screens used by the app), content providers (database objects) and services (background workers). We also note that the service is debuggable, which means that we can attach a debugger to the process, using adb, and step through the code. As you can see, they are called "exported", because the app "exports" them to other applications, which can then make use of them.

I think that the question starts from wrong or biased assumptions. You are observing a true phenomenon (mobile devices hacked systematically) and try to conclude that they are weaker than desktop based on your observations. That is a known cognitive bias. Let me explain why step by step. It is easy to hack the devices No, it's not. The OSes have a security vulnerability, and someone has found a way to exploit it. What you see is the end, but not the beginning. Probably, it took months of hard work to discover that vulnerability. The fact that you can simply https://www.express.co.uk/life-style/science-technology/919343/iPhone-Text-Message-Crash-WhatsApp or just https://www.express.co.uk/life-style/science-technology/580211/iPhone-Messages-iMessage-Bug-Text-Reboot-Crash doesn't mean it's easy. It's annoyingly easy to reproduce, but not to discover Mobile devices are easier to hack compared to desktops It's not in their nature (I'll explain why), but in their market penetration. Assuming all desktop devices use either Windows or Mac OS or Linux, and all mobile devices either Android or iOS, the number of Android and iOS devices overwhelm the figures from the desktop world. And we are not still counting the server market, which shows less devices either. Fishing and hunting example: where would you go hunting? In a jungle full of fat animals, or in a dry steppe where you can't see animals for miles? Mobile devices, with their larger market penetration, are more attractive to cyber criminals, who will invest their best efforts to find vulnerabilities where they have much more chances to strike. About market shares, there is plenty of literature around. I am struggling to find a graph that depicts the boom of mobile devices vs the shrink of desktop devices over the course of the last 10 years. Desktops do not have (or have less) 0-click vulnerabilities When you use e.g. Windows (even if it is not the most updated) or Ubuntu, you do not expect that clinking an url will grant root access to your device to someone else. I'm not sure that can be said for Linux, but Windows had notably, years ago, a few dreaded 0-click exploits. I want to elect https://support.microsoft.com/en-us/topic/virus-alert-about-the-win32-conficker-worm-73e7df59-ec59-d474-bbe8-1f06b7caef60 as the most dreaded worm in the history of the Windows OS. Please, let's take a look at the Internet history to see other notable Windows viruses that required little to no interaction from the user. Conficker was particularly dreaded to me because I remember I got infected once by the very moment I connected freshly-formatted my machine to the network, because there was an infected host hitting my machine. https://en.wikipedia.org/wiki/Stuxnet is another notable computer virus affecting Windows OS without clicks This is to say that your view was particularly biased. What is a security vulnerability and where does it come from? If we managed to build desktop OS which are safe, or at least safer than android, why is it so difficult to do it with mobile phones? Computer OSes are written in the same languages as mobile OSes. This because a mobile device is effectively a computer, under the Turing Machine definition, and the hardware architecture. A mobile device misses the PCI-E and DDR slots that assemblers love since the '90s, their SoC (System On Chip) architecture allows for smaller size and higher densities, but they are no more that computers. Some models even run the same https://en.wikipedia.org/wiki/X86-64 . Software engineering practices vary a little between desktop and mobile OSes, mostly because of the variety of sensors (cameras, microphone, accelerator, GPS), but security practices in developing software are in practice the sasme. Security vulnerabilities are born from software bugs, which always existed and will continue to exist. The more complex the OS, the more security vulnerabilities exist. For this reason, Android will likely display a lot more security vulnerabilities that iOS. iOS is made by Apple, and the same code deployed to a short variety of devices. Android is open, and manufacturers notably fork AOSP (Android Open Source Project) to customize it. The more manufacturers, the more forks, the more complexity, the less security patching, the more likely for vulnerabilities on a family of devices. From https://security.stackexchange.com/a/65214 (emphasis mine) If your device is not a high end device which gets updates on a timely manner you are at bigger risk (this is why Nexus devices are the safest among android devices) You don't expect the cheapest phone maker to update the OS after launching their devices to market.

Likely. While I voted your question for closing because it it too broad for the scope of this board, let me just add a couple of considerations. Android apps are developed using either the SDK or the NDK. The SDK is an implementation of the Java Language Specification, with additional sandboxing (permission model etc). The NDK allows apps to run native code, which is essentially the usage of pointers and direct assembly instructions which would otherwise have to be emulated/interpreted by the JVM. As for the SDK, it all depends on the Windows's implementation of the Android subsystem. If Microsoft implements all sandboxing features in AOSP, we can assume the app will run with the same security features. If, for counterexample, Windows does not implement a system prompt for disk access, then the app will have right to use java.io.File APIs unrestricted. But that's a 10k feet view from the specifications point of view. There is nothing preventing Microsoft from leaving a security exploit in a sandboxed environment. That's why software is regularly patched.

Yes. Biometric authentication is not cryptographically bound to File Based Encyption (FBE). It only works in After First Unlock (AFU) state in which FBE keys are already decrypted. In AFU state, the processor's Trusted Execution Environment (TEE) reencrypts FBE keys using a Ephemeral Key (EK). EK remains inside TEE and is valid until next reboot. Reencrypted FBE keys are then cached in vold and the Linux kernel keyring. When the Linux kernel requires this key to read or write a file, it calls TEE which decrypts the cached FBE keys, derives a 64-byte AES-256-XTS key, and programs it in into the Inline Crypto Engine (ICE). Biometric authentication at locked screen only prevents access to device features and apps that require screen to be unlocked. However, password managers (or in-app biometric authentication in general) cryptographically bind successful result of biometric authentication with key decryption. Apps can ask TEE to decrypt their keys and token only when biometric authentication is successful. Biometric verification is done by vendor library inside TEE and biometric sensor is connected with TEE using SPI channel. Even with fake sensor, the authentication result is still upto TEE to decide. The sensor only sends the data. But biometrics can be spoofed so it's not a primary way of authenticating the user. Android fallsback to Lock Screen Knowledge Factor (LSKF) after every 72 hours or after every 3 consecutive failed biometric authentication (whichever happens first). https://security.stackexchange.com/a/247954/118310 https://source.android.com/security/encryption/file-based https://www.qualcomm.com/media/documents/files/file-based-encryption.pdf (pdf)