sir, i would to downgrade from aosp p to nougat, should i do a clean flash? i want to keep my data if it possible.
i've installed oreo before and upgraded to pie, but i feel oreo more smooth and responsive, and now i want to try nougat.
has anyone tried which is best performance between these?
* Your warranty is now void.
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
Google Applications (optional) : OpenGapps : http://opengapps.org/ (Use packages for ARM, Android 7.x, Micro or Pico) Information : Flash the GApps before the first boot. If not, a clean flash is recommended.
AOSP clean install :
- (Optional) Flash the boot.img kernel from the ROM zip with Fastboot or Flashtool
- (Optional) Wipe the data & cache (Backup to make sure not to lose data)
- Flash the AOSP ROM zip from the Recovery
- (Optional) Flash the GApps to have the Google Applications
- (Optional) Every additional zip you want to flash
AOSP update / upgrade :
- (Information) Don't wipe anything unless you want to
- Flash the latest AOSP ROM zip from the Recovery
- (Optional) Flash the GApps if you want to, otherwise preserved.
- (Optional) Every additional zip you want to flash
- Report issues only if you use the ROM kernel - If an additional mod is installed, make sure it's unrelated, and mention it - Make sure the issue wasn't discussed earlier in the threads - Share a log of the error with CatLog for example
- Boot : Ok
- GApps : OpenGApps Micro Ok
- Partitions (Data, Cache) : Ext4 supported
- Dual Recovery : Ok (see below)
- WiFi : Ok (real SONY MAC address)
- Bluetooth : Ok (real SONY MAC address)
- WiFi Hotspot : Ok (2.4GHz and 5GHz)
- RIL - Phone - Data : Ok
- GPS : Ok
- Camera : Ok
- Camcorder : Ok
- Lights : Ok, regular AOSP lights support
- MicroSD : Ok, only Ext4 support missing from AOSP
- Accelerometer : Ok
- Compass : Ok
- Gyroscope : Ok
- AOSP sensors : Ok
- FM Radio : Ok
- Vibrator : Ok
- Microphone : Ok
- Audio & external audio : Ok
- Bluetooth audio : Ok
- NFC : Ok
- Kernel : Ok
- Graphics : Ok
- 3D Rendering : Ok
- Clock : Ok (RTC real hardware clock, in TWRP recovery too)
- Powered-off alarm : Ok
- Offline Charging : Ok
- Encryption : Status unknown
- SEPolicies : Fully enforced
IMPORTANT FEATURES TO KNOW
Boot sequence : Once the LEDs light up :
- Press Volume - to open CyanogenRecovery,
- Press Volume + to open the FOTA recovery (TWRP usually) if available
Powered-off alarm : When you have set an alarm
- If you power down the device, it will wake automatically 5 minutes before
- If you let the device charge offline, it will automatically reboot 5 minutes before
Gestures : Events like hand-wave and pocket removal can be enabled in the Settings
Force reboot : You can reset the device by holding Power and Volume+ 5 seconds
As quite a few already know since months by looking at my public projects on GitHub,
I have been working on the yet-to-be named and -to-be-redesigned AOSP Master since March / April.
Unlike what users expect, the Master development branch of Android AOSP is related to hardware and sources cleanups, while the features and UI changes are kept internal by Google until the official release we just had.
Working since all these weeks on Master (and O Preview 1/2/3/4) was meant to prepare the field for almost everything Huashan 8960t would potentially need.
For instance, O requires multiple changes to the kernel for what is called hwbinder and vndbinder support, used by the userspace for the hardware services and all Android O hidl changes (Google these if you are interested, some of the notions are accessible to even non-developer readers). All these changes either match our code or needed backporting to 3.4(.113) 8960 kernels. I kept all these public and they are now on Gerrit (Sony 8960t).
Basically, between April and July, my AOSP Master was fully working on the Xperia SP and the Xperia T, with tests on the Xperia TX and V too.
One of the biggest time waste of this project was a very strong visual glitch of the display composition, which ended up coming from the libhwui changes involving graphics EGL capabilities. This will affect probably most devices of this generations, most likely using Flo Adreno binaries from M.
I invite interested devs to read my details in my EGL property commit in Huashan sources.
To finish on Master, Bluetooth stopped working properly despite my initial temporary workaround to increase timeouts (the new AOSP Bluetooth HAL is massively different) and WiFi broke last month too, and I haven't taken / did not have time to fix it yet. Everything else was fine and used as daily.
Another major and personal motivation was to start the sepolicies fully clean. Detached from QCOM ones this time, I've progressively rebuilt the sepolicy rules as strictly as possible, with specific labelling and in order to match common policies as much as possible, in order to be close to Google Marlin device sepolicies standards. The device was running enforced over the last month and only minor changes to the commits will maybe be done now.
Now... You skipped the first part and came here.
As others noticed by spying on my GitHub again, we started unifying our personal works on AOSP last week to prepare the next iteration of LineageOS. This helped us working very quickly on our basis upon release of O.
Obviously nothing or barely nothing feature related is done yet, hardware support is the priority. Please do not request ETAs or features randomly on the forum or else, further information will be shared when there is actually information to be shared.
Finally the last part you'll skip to because of the pictures.... I've been rebasing my AOSP Master changes to the Oreo release 8.0.0 (r3 for Pixel), and progressively fixed new code / hardware support changes done by the release.
This night (4am...) was spent attempting to complete the boot on Huashan.
Along an issue of 1 change I did for master sepolicies that broke the initialization (anticipation back-fired), the multiple new hardware HALs needed to be properly selected and compiled to match the requirements and complete the boot without display EGL crashes or audio failures.
The Oreo UI therefore fully booted. More work will be needed to bring back all features inline with my Master builds and to fix remaining things to do.
Please do not request for ETAs there too. It will be done once possible on evenings.
Two years after my initial implementations of the Xperia SP (Huashan) LEDs hardware controllers
(AS3665 and AS3677, unique to this device because of the LEDs bar), I present to you the project I have been wishing to complete since then.
My open-source LibLights for Huashan's LEDs handles all normal lights (notifications and display backlight),
and flashing lights (blink) with the advanced sequencer program from the AS3665.
Unlike most devices, this sequencer is a programmable input for calculations,
registers comparisons and outputs to each LED for current / brightness renderings.
The final step that never worked up until now, knowing I had that sequencer written and detailed since 2 years,
was the music lights effects done on the LEDs bar as Sony once did on Stock 4.3. As music lights effects are done through hardware and not software, meaning the audio directly controls
the LED controller through a specific wire input, the music effects do not add performance lags or permanent update events.
The missing part were the audio routes : connecting the real audio output to the AS3665 input.
Two weeks ago I went back to Stock 4.3 and progressively got into it through newly built kernel, repacked original Stock image without signature,
and step by step went into the audio routes to identify the required audio mixer configurations needed for my changes to work.
Implemented for AOSP-based and LineageOS-based ROMs, my Music Lights Effects for Huashan are not bound to any ROM changes.
That's the biggest point I worked on here when the technical side was ready, as I did not wish to add specific code to the framework related to only one device,
and hence make it also fully compatible with my Android AOSP releases without porting our Lights improvements from LineageOS.
Lights Effects are implemented in what we call DeviceSettings, just like done since more than a year for Ambient Display specific gestures.
I provide an option to enable / disable the effects, a choice on the audio gain to adapt the AS3665 input to your wishes,
an optional dependency on the device being awake (to allow the music effects even locked) and a final one to always use effects while awake.
Preview and presentation video :
There are four layers to my implementation :
LightsEffectsService (in DeviceSettings) listens media player events and triggers lights_effects through the "sys.lights_effects_value" property
init rules trigger lights_effects events on property "sys.lights_effects_gain" or sys.lights_effects_value" changes
Binary lights_effects is the new executable extension of my liblights and handles the audio configuration, audio routes and kernel music mode.
Kernel lights_effects is a new driver input that controls the AS3665, configures the music mode and properly blocks normal actions // keep them updated.