Nokia 2.3 Stock Wallpapers Are Here For Download
Julia Dodoo
I'm not sure if it's the same on older systems, but on ICS it appears to save directly to /data/data/com.android.settings/files/wallpaper. I set mine from the browser, pulled that file, then changed it to a .png extension and voil - it was the image I had set.
I was annoyed by the exact same problem, so I have programmed an app that automatically saves your wallpapers and your live wallpapers too. It makes it easy to revert to a previous wallpaper. It is called Wallpaper Saver, by Appdictive, and it's free in the Play Store. (It does not require root access.)
The location of the stock wallpapers is in an apk file that you should find on your device at /system/framework/framework-res.apk. Pull that file to your computer and then browse its internals. A search for a file with wallpaper in its name should prove fruitful.
Copy the images with high size (maybe more than 80 KB since they got a quality) and paste them into a folder that is not in a root directory. (Just copy it to your "Downloads" folder or to your SD card)
I couldn't resist linking across to this Symbian Developers post - I guess that, technically, the contents of the archives might be copyrighted to Nokia, but I doubt it'll mind at this stage for these operating systems and given that the resources are just images at the end of the day. What we have here are ZIP archives of the default 'out of the box' wallpapers for various Symbian generations, plus those for the Meego-powered N9 as a bonus.
Having sideloaded any wallpaper files you fancy, on a Symbian device you can change wallpapers by simply pressing and holding on any blank spot on a homescreen. After selecting an image from all the JPGs on your phone, there will be a couple of seconds delay while the graphic gets optimsed and resized to nHD etc. Be patient.
This page contains answers to frequently asked questions about GrapheneOS. It's not an overview of the project or a list of interesting topics about GrapheneOS. Many of the answers would be nearly the same or identical for the latest release of the Android Open Source Project. The goal is to provide high quality answers to some of the most common questions about the project, so the developers and other community members can link to these and save lots of time while also providing higher quality answers.
The following devices are end-of-life, no longer receive firmware or most driver security updates and receive extended support from GrapheneOS as part of the main releases with all GrapheneOS changes including all of the latest Android Open Source Project changes:
The following devices are end-of-life, no longer receive firmware or driver security updates and receive extended support from GrapheneOS via a legacy branch based on Android 13 with only the Android Open Source Project security backports, certain other security patches and other minimal changes to keep them working:
The release tags for these devices have official builds and updates available. These devices meet the stringent privacy and security standards and have substantial upstream and downstream hardening specific to the devices.
Many other devices are supported by GrapheneOS at a source level, and it can be built for them without modifications to the existing GrapheneOS source tree. Device support repositories for the Android Open Source Project can simply be dropped into the source tree, with at most minor modifications within them to support GrapheneOS. In most cases, substantial work beyond that will be needed to bring the support up to the same standards. For most devices, the hardware and firmware will prevent providing a reasonably secure device, regardless of the work put into device support.
GrapheneOS does not support being used as a Generic System Image, which only exists for development/testing purposes and isn't usable for GrapheneOS since we require kernel changes and the userspace part of the OS cannot run on top of a kernel without the required functionality. The generic targets simply run on top of the underlying device support code (firmware, kernel, device trees, vendor code) rather than shipping it and keeping it updated. It would be possible to ship generic system images with separate updates for the device support code. However, it would be drastically more complicated to maintain and support due to combinations of different versions and it would cause complications for the hardening done by GrapheneOS. The motivation doesn't exist for GrapheneOS, since full updates with deltas to minimize bandwidth can be shipped for every device and GrapheneOS is the only party involved in providing the updates. For the same reason, it has little use for the ability to provide out-of-band updates to system image components including all the apps and many other components.
Some of the GrapheneOS sub-projects support other operating systems on a broader range of devices. Device support for Auditor and AttestationServer is documented in the overview of those projects. The hardened_malloc project supports nearly any Linux-based environment due to official support for musl, glibc and Bionic along with easily added support for other environments. It can easily run on non-Linux-based operating systems too, and supporting some like HardenedBSD is planned but depends on contributors from those communities.
We strongly recommend only purchasing one of the following devices for GrapheneOS due to better security and a long minimum support guarantee from launch for full security updates and other improvements:
8th generation Pixels provide a minimum guarantee of 7 years of support from launch instead of the previous 5 year minimum guarantee. 8th generation Pixels also bring support for the incredibly powerful hardware memory tagging security feature as part of moving to new ARMv9 CPU cores. GrapheneOS uses hardware memory tagging by default to protect the base OS and known compatible user installed apps against exploitation, with the option to use it for all apps and opt-out on a case-by-case basis for the few incompatible with it.
The Pixel 7 and Pixel 7 Pro are all around improvements over the Pixel 6 and Pixel 6 Pro with a significantly better GPU and cellular radio along with an incremental CPU upgrade. The 7th generation Pixels are far more similar to the previous generation than any prior Pixels.
The Pixel Tablet is a tablet variant of the 7th generation devices and the Pixel Fold is a hybrid phone/tablet. These share the same SoC and are nearly the same as the other 7th generation devices under the hood.
Devices are carefully chosen based on their merits rather than the project aiming to have broad device support. Broad device support is counter to the aims of the project, and the project will eventually be engaging in hardware and firmware level improvements rather than only offering suggestions and bug reports upstream for those areas. Much of the work on the project involves changes that are specific to different devices, and officially supported devices are the ones targeted by most of this ongoing work.
Hardware, firmware and software specific to devices like drivers play a huge role in the overall security of a device. The goal of the project is not to slightly improve some aspects of insecure devices and supporting a broad set of devices would be directly counter to the values of the project. A lot of the low-level work also ends up being fairly tied to the hardware.
In order to support a device, the appropriate resources also need to be available and dedicated towards it. Releases for each supported device need to be robust and stable, with all standard functionality working properly and testing for each of the releases.
Broader device support can only happen after the community (companies, organizations and individuals) steps up to make substantial, ongoing contributions to making the existing device support sustainable. Once the existing device support is more sustainable, early research and development work for other devices can begin. Once a device is deemed to be a worthwhile target, the project needs maintainers to develop and maintain support for it including addressing device-specific issues that are uncovered, which will include issues uncovered in the device support code by GrapheneOS hardening features.
It's not really a matter of time but rather a need for community support for the project increasing. As an open source project, the way to get something to happen in GrapheneOS is to contribute to it, and this is particularly true for device support since it's very self-contained and can be delegated to separate teams for each device. If you want to see more devices supported sooner, you should get to work on identifying good devices with full support for alternative operating systems with verified boot, etc. and then start working on integrating and testing support.
It should also be clear that the expectation is for people to buy a device to run GrapheneOS, rather than GrapheneOS supporting their existing devices. This will only become more true if GrapheneOS is successful enough to accomplish the goal of having devices produced based on an SoC reference design with minor improvements for privacy and security. Broad device support is the opposite of what the project wants to achieve in the long term.
GrapheneOS aims to provide reasonably private and secure devices. It cannot do that once device support code like firmware, kernel and vendor code is no longer actively maintained. Even if the community was prepared to take over maintenance of the open source code and to replace the rest, firmware would present a major issue, and the community has never been active or interested enough in device support to consider attempting this. Unlike many other platforms, GrapheneOS has a much higher minimum standard than simply having devices fully functional, as they also need to provide the expected level of security. It would start to become realistic to provide substantially longer device support once GrapheneOS controls the hardware and firmware via custom hardware manufactured for it. Until then, the lifetime of devices will remain based on manufacturer support. It's also important to keep in mind that phone vendors claiming to provide longer support often aren't actually doing it and some never even ship firmware updates when the hardware is still supported by the vendors...
b37509886e