I've seen instructions to disable Device Care or limit its operation, but they don't work on Android 13. I don't want some faraway Samsung executive deciding which background applications I can run or which files I can keep. I'm perfectly happy to have the phone tell me which apps are using resources, but I'm quite capable of deciding for myself whether to let them continue doing so. Some of my own apps do run a background service for a long time, because that's what I wrote them to do. I have lots of files on it, but it's the 512GB model, so I'm not running out of space. I don't want large files that I haven't used lately getting removed: they are on the device because I want them there. If I don't want files I can delete them myself: I don't use apps which create unneeded files and leave them lying around. If the built-in apps (most of which I have disabled) create files, they should clean up after themselves.
My phone is a Samsung Galaxy S21 Ultra 5G which recently upgraded to Android 13.
Related
I'm developing an application which is previewing video feeds from a capture card and/or a webcam. I've noticed a lot of errors in my console that look like:
IGIESW [path to my.exe] found in whitelist: NO
IGIWHW Game [path to my.exe] found in whitelist: NO
These repeat each time I try to activate a preview window or switch the source feed I'm trying to preview. It actually takes a few seconds each time and it really kills the responsiveness of my application. I'm also seeing a similar slowdown in other applications which are previewing and switching between sources.
I have two nearly identical machines and I only see the errors on the machine with the NVIDIA graphics card; it doesn't happen on the machine using the built-in Intel HD graphics. This lead me to believe it was an NVIDIA setting and on a hunch I tried disabling the "Share" feature in GeForce Experience and that fixed the problem! I really need to use the screen capture capability to record my application so simply leaving it disabled isn't an option.
I searched online for information about IGIWHW and IGIESW but I really couldn't find much other than a few "my game won't work" type forum posts.
I don't see any reference to a whitelist in the Share settings nor in the online help for the NVIDIA control panel. I tried adding my path to the list of paths in the Games scanning settings but it didn't help. Does anyone know where this whitelist is setup? It's strange that even though the errors seem to indicate that my app isn't whitelisted it still works (just very slowly).
I have GeForce Experience 3.6.0.74 and driver 381.65 running on Windows 10.
Somewhat related to this question I just asked, but I know it isn't good to have multiple questions in one, so making a separate question.
I know Licenses Comparison shows that it is available on all versions (even free) of Unity on all platforms in that list. However, I've found other mistakes/misleading info in that list, so I'd rather hear from someone with experience or someone from Unity.
Also, if I do end up using WWW, I'd need to use a long-polling design (where server waits several seconds, even minutes to reply). Any issues I'll run in to on different platforms?
Main platforms I know I need to target: Windows Store 8 (Surface RT), iOS, Android -- tablets and phones -- probably desktops later (Windows and Mac)
WWW reference
EDIT: I'll be using HTTP and HTTPS in case not obvious (not file: or ftp: protocols).
I have used the WWW-class on PC standalone and Android builds. It worked well with both text and textures. Only platform that requires additional tweaking, that I know of, is the web player where you have to add crossdomain-settings for fetching files.
Can a Flex application that was designed for use on a PC be run on an iPad, iPhone, or Android-based mobile device?
Seems like a simple enough question. Visiting http://www.adobe.com/products/flex.html yields a picture of a dude running a (presumably) Flex application on an Android. So at first glance, the answer would appear to be "yes." End of story.
but yet…
There is so much (mis)information out there on various tech sites that suggest Flash-based technologies simply won't run on iOS or other mobile platforms. Why is this? Perhaps they mean to say that Flex won't run "out of the box" and requires a plugin? Or do they mean it won't run at all?
Every time I think I've reached a definitive conclusion, some post on SlashDot or CNET directly contradicts it. So what's the scoop? Can one take an existing Flex application and run it on iOS/Android? (I realize there are screen size issues to consider so the app might not run effectively. I just want to know if the runtimes are available on the mobile devices to allow the Flex app to launch at all.)
Sorry for the noob question. My background is WPF / HTML5. Adobe technologies are completely foreign to me.
I wrote a lot below if you'd like to read it enjoy, if not sorry for taking your valuable bytes :) I directly answered the questions up here first:
Why is this?
It's a confusing matter read below for the why details.
Perhaps they mean to say that Flex won't run "out of the box" and requires a plugin?
Or do they mean it won't run at all?
Using the flash builder tools (the bin folder in the SDK) you can compile for native desktop application, desktop web browsers, native iOS application, native Android application. Android with FlashPlayer plugin installed will show Flash content within the web browser, iOS will only run the ones compiled with AIR, not in the the web browser but as a native app.
Every time I think I've reached a definitive conclusion, some post on SlashDot or CNET directly contradicts it. So what's the scoop? Can one take an existing Flex application and run it on iOS/Android?
Yes, if using AIR and run as a native app on all three platforms (the desktop Flex API is for the most part a superset of the web Flex API), your other points about performance and form factor are valid and should be considered though. The nice thing is you can write your model/controller code in a common library in AS3 then write separate presentation layer interfaces that all share the library.
Here's the very long version:
Using the flash compiler results in "bytecode" in the form of a file with a swf extension using the swf format, you can read a ton more about that here:
http://www.adobe.com/devnet/swf.html
To interpret the file you need some sort of run-time similar to some degree to running WPF/XAML/C# within a .NET framework context (either desktop or using silverlight on the web). In the case of adobe technologies (rough equivalence):
AS3 = C#
MXML = XAML
Flex = WPF+WCF (client side RPC not server side)
Flash Player = Silverlight
AIR (Adobe integrated runtime) = .NET
Framework Redistributable .dll(s)/.so(s) for desktop OSes
(Read this list very loosely please, I know XAML is preserved in the MSIL or whatever which is different because MXML is compiled to AS3 and only if a debug flag is set on the compiler does it include the debugging symbols, there's certainly tons of differences but I think this is an easy and correct enough model to use)
On iOS the browser does not allow for plugins in the traditional sense of netscape browser plugins or ActiveX plugins. For this reason you'll not be able to execute a plugin ie flashplayer or silverlight in the browser. Since Adobe did release a flashplayer for Android devices that does run in the browser it will work on those devices in the browser, however they have essentially thrown in the towel for supporting this long term, as they have to support the majority mobile device platform, iOS, in order to remain relevant (this was I think more a collective throwing in of the towel by Google, device manufacturers, carriers, Microsoft, all just following suit and trying to make the best business decision, WebKit and V8 or SpiderMonkey can probably do 99% of what Flash can do and better in some cases and WebKit will hopefully not splinter and will remain open source... frameworks and the browsers just need to get fleshed out and stabilized).
If the user installs AIR (or the runtime is packaged with the app) then a Flex/Flash (that is stuff coded in AS3 and/or MXML and compiled to a swf) can be transcoded/packaged to be interpreted by the run-time for that device correctly (be it iOS or Android or whatever RIM did, I don't think they have AIR for Windows Phone 7 and Win8 on ARM won't support browser plugins either). Part of the confusion is possibly from the fact that Apple denied the distribution of Apps that were "cross-compiled" which kept AIR out of the list of options for iOS for a good year, just after Adobe started announcing it was usable for that purpose (kicking Adobe while their down). Another part of the confusion probably comes from real vids of people who have 1 hacked their device or 2 were able to get open source alternatives to the flash player run-time to work on their iOS device (gnash was one I'm aware of from some occasional Linux tinkering, also possibly FAKE vids).
You can run Flex applications on mobile devices, but you cannot simply run any Flex project.
In Flash Builder ( Flex Ide) or in Flash Professional you can create mobile projects. These projects generate native applications for iOS and Android.
Last time I tried, the result and the available components where less than what I expected. So, if you can, I'll much recommend you go for something like Appcelerator.com or similar, which turns HTML5/Js code into native apps. I tried them, worked a lot better than Flex.
Short answer: No
Long answer: You can use Adobe's tools to compile your Flash/Flex app for use as a native iOS app. So you won't be able to embed the app in a web page like you normally could with Flex, but you can build it as a native app. Note you have to have Flash Builder 4.5 to do this.
It won't run on iPhone as a .swf file, but it will run on Android based devices that have adobe flash installed. It will also run on the BB playbook, which also has flash.
Flex is a framework.( Anyway it is very beutiful one which even sometime looks like complete different language ).
As soon as you are building AIR application it can run on various platforms like : Windows, iOS, Android, upcomming TV's, PlayBook, even .. into the future ( maybe/hopefuly ) on Windows Phone, plus Linux ( which AIR future is not very clear anyway ( but hopefuly Adobe will reconsider ) ).
So - application created with Flash Builder 4.5+ would probably run everywhere as soon as it is AIR application.
The compilation methoods is really simple, and you almost simultaneously compiling for everything you wanna to.
And one of the most important things here - your applications will run, work, look and feel the same way you were designed on one device. Flex is the thing which is responsible for everything to looks beutiful on each platform it is running.
For instance i am compiling currently for Android, and without even test i can clearly say that it will looks and feel the same way under iOS and Windows, and it will.
This may appear at first a bit of a general question, but its actually quite specific.
Is it feasible to use (or worth buying) a multi-touch monitor for developing and testing mobile Flex/Air applications? For instance one could use the Android emulator and package their Air 2.5 app to run in the emulator, and then use the multi-touch LCD to test it out. Rather than continually downloading the app to the mobile device.
Has anyone tried this?
Brian
I don't think that would work. The problem here is the hardware isn't connected to the software the same way as on a device (which goes through firmware). In this case, it's going through the OS (which I'm not even sure support multitouch) and then the emulator(which I'm not positive will even take in multitouch input from the OS). The emulator might not even have multitouch code in it.
I would stick with using the device. I don't see why that's a problem. If you streamline the compile/deploy/debug process, it's even easier than using the emulator.
I have an S60 app which I am writing in Qt and which has a large number (several thousand) small audio files attached to it, each containing a clip of a spoken word. My app doesn't demand high fidelity reproduction of the sounds, but even at the lowest bit rate and in mono MP3 they average 6k each. That means my app may have a footprint of up to 10Mb. The nature of the app is such that only a few audio clips will be needed at any one time - maybe as many as 50, but more like 1-10.
So my question has two parts:
1) is 10Mb for a mobile app too large?
2) what is a reasonable alternative to shipping all audio files at install time?
Thanks
Have you considered rolling all clips into a single file and then seek in the stream? I'm not sure how much the per-file overhead of MP3 is but it might help.
That said, every S60 mobile phone out there should have 1GB or more, so 10MB doesn't sound like "too much". But you should deliver the app as a JAR file which people can download from your website with a PC and then install by cable. Downloading large amounts of data by the phone itself is pretty expensive in many parts of the world (Switzerland, for example).
In terms of persistent storage, 10Mb isn't a lot for modern mobile devices, so - once downloaded - storing your application data on the device shouldn't be a problem.
The other type of footprint you may want to consider, however, is memory usage. Ideally, you'd have clips buffered in RAM before starting playback, to minimise latency. Given that most Symbian devices impose a per-process default heap size limit of 1Mb, you can't hold all clips in memory, so your app would need to manage the loading and clearing of a cache.
It isn't generally possible to buffer multiple compressed clips at a time on Symbian however, since buffering a clip typically requires usage of a scarce resource (namely an audio co-processor). Opening a new clip while another is already open will typically cause the first to be closed, meaning that you can only buffer one in memory at a time.
If you do need to reduce latency, your app will therefore need to take care of loading and decompressing where necessary, to give PCM which you can then feed to the audio stack.
10MB is definitely on the large side. Most apps are < 1MB, but I think that I've seen some large ones (6-10-15 MB), like dictionaries.
Most S60 phones have in-phone storage space of around 100MB, but they also have memory cards and these are usually 128MB+, and 4GB is not uncommon for higher-end phones. You need to check the specs for your target phones!
Having such a large install pack will make installing over the air prohibitive. Try to merge the files so that you only have a few large files instead of many small ones, or the install will take too long.
An alternative would be to ship the most used sounds and download the rest as needed. S60 has security checks and you will need to give the app special permissions when you sign it.
Have you thought about separating the thousands of audio files into batches of, say, 20?
You can include a few batches into the application installation file and let the user download one (or more) batch at a time from your application GUI, as and when needed...
Store the sound files in a SQLite database, and access them only upon demand. Sounds like you are writing a speaking dictionary. Keep the app itself as small as possible. This will make the app load very fast by comparison. As the database market has matured, it seems a developer only needs to know about two database engines anymore: SQLite, for maximum-performance desktop and handheld applications, and MySQL for huge multi-user databases. Do not load all those sounds on startup unless it is critical. My favorite speaking dictionary application is still the creaking Microsoft Bookshelf '96; no kidding.
10MB for a mobile app is not too large provided, you convince the user that the content he / she is going to pull over the air is worth the data charges the user will incur.
Symbian as a platform can work well with this app as the actual audio files will be delivered from within the SIS file but the binary will not contain them and hence will not cause memory problems...
The best option would be to offer the media files for download via your website so that the user can download and sync them via PC- Suite / Mass Storage transfer. Allow the user to download the files into e:\Others or some publicly available folder and offer to read the media from there...
My 2cents...